[Shorewall-users] Asterisk/SIP stops working...

[Ian Jones]

Hello. I have installed shorewall as a nat router for my Asterisk PBX on
Debian 8.8 from the Debian package.

shorewall version
4.6.4.3

(I have replaced my public IP address with xx):

ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth-intern: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP group default qlen 1000
link/ether 4c:cc:6a:24:8f:be brd ff:ff:ff:ff:ff:ff
inet 192.168.71.30/24 brd 192.168.71.255 scope global eth-intern
valid_lft forever preferred_lft forever
inet6 fe80::4ecc:6aff:fe24:8fbe/64 scope link
valid_lft forever preferred_lft forever
3: eth-ext1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group
default qlen 1000
link/ether 00:26:55:d4:a5:f4 brd ff:ff:ff:ff:ff:ff
4: eth-ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc prio state
UP group default qlen 1000
link/ether 00:26:55:d4:a5:f5 brd ff:ff:ff:ff:ff:ff
inet xx.xx.xx.xx/29 brd xx.xx.xx.xx scope global eth-ext0
valid_lft forever preferred_lft forever
inet6 ::xxx:xxx:xxx:xxx/64 scope global mngtmpaddr dynamic
valid_lft 3598sec preferred_lft 3598sec
inet6 xxx::xxx:xxx:xxx:xxx/64 scope link
valid_lft forever preferred_lft forever

ip route show
default via xx.xx.xx.xx dev eth-ext0
10.0.0.0/8 via 192.168.71.6 dev eth-intern
xx.xx.xx.xx/29 dev eth-ext0 proto kernel scope link src xx.xx.xx.xx
192.168.71.0/24 dev eth-intern proto kernel scope link src 192.168.71.30

Shorewall is running on 192.168.71.30, and Asterisk on 192.168.71.8. So,
in rules I have:

# sip
SIP(DNAT) net loc:192.168.71.8:5060 udp 5060
SIP(DNAT) net loc:192.168.71.8:5060 tcp 5060
# rtp
DNAT net loc:192.168.71.8:10000-10020 udp 10000:10020
# stun
DNAT net loc:192.168.71.8:3478 udp 3478
# iax2
DNAT net loc:192.168.71.8:4569 udp 4569

This all works fine - for a few hours! Then all the external Asterisk
peers become unreachable and remain so. I can also reproduce the problem
by restarting Asterisk, or by reloading sip.conf. I can remedy the
problem by stopping the external interface for a couple of minutes, then
restarting it. The Asterisk peers become reachable again and all is
well, for a few hours.

There is no problem with IAX, the IAX peers remain reachable.

I also have a Cisco DSL router, and when I route all the Asterisk
traffic through that, it works fine and everything is very stable with
the same Asterisk configuration, so it seems to be a problem with the
shorewall router. I have tried turning off the sip helper by setting
AUTOHELPERS=No and DONT_LOAD=nf_nat_sip,nf_conntrack_sip, but that
didn't help.

Any help appreciated!

Regards,

Ian

[Tom Eastep]

Post by Ian Jones
Hello. I have installed shorewall as a nat router for my Asterisk
PBX on Debian 8.8 from the Debian package.
shorewall version 4.6.4.3
ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever
preferred_lft forever inet6 ::1/128 scope host valid_lft forever
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP group default qlen 1000 link/ether 4c:cc:6a:24:8f:be brd
ff:ff:ff:ff:ff:ff inet 192.168.71.30/24 brd 192.168.71.255 scope
global eth-intern valid_lft forever preferred_lft forever inet6
fe80::4ecc:6aff:fe24:8fbe/64 scope link valid_lft forever
preferred_lft forever 3: eth-ext1: <BROADCAST,MULTICAST> mtu 1500
qdisc noop state DOWN group default qlen 1000 link/ether
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc prio state UP
group default qlen 1000 link/ether 00:26:55:d4:a5:f5 brd
ff:ff:ff:ff:ff:ff inet xx.xx.xx.xx/29 brd xx.xx.xx.xx scope global
eth-ext0 valid_lft forever preferred_lft forever inet6
::xxx:xxx:xxx:xxx/64 scope global mngtmpaddr dynamic valid_lft
3598sec preferred_lft 3598sec inet6 xxx::xxx:xxx:xxx:xxx/64 scope
link valid_lft forever preferred_lft forever
ip route show default via xx.xx.xx.xx dev eth-ext0 10.0.0.0/8 via
192.168.71.6 dev eth-intern xx.xx.xx.xx/29 dev eth-ext0 proto
kernel scope link src xx.xx.xx.xx 192.168.71.0/24 dev eth-intern
proto kernel scope link src 192.168.71.30
Shorewall is running on 192.168.71.30, and Asterisk on
# sip SIP(DNAT) net loc:192.168.71.8:5060 udp
5060 SIP(DNAT) net loc:192.168.71.8:5060 tcp
5060 # rtp DNAT net loc:192.168.71.8:10000-10020
udp 10000:10020 # stun DNAT net
loc:192.168.71.8:3478 udp 3478 # iax2 DNAT net
loc:192.168.71.8:4569 udp 4569
This all works fine - for a few hours! Then all the external
Asterisk peers become unreachable and remain so. I can also
reproduce the problem by restarting Asterisk, or by reloading
sip.conf. I can remedy the problem by stopping the external
interface for a couple of minutes, then restarting it. The Asterisk
peers become reachable again and all is well, for a few hours.
There is no problem with IAX, the IAX peers remain reachable.
I also have a Cisco DSL router, and when I route all the Asterisk
traffic through that, it works fine and everything is very stable
with the same Asterisk configuration, so it seems to be a problem
with the shorewall router. I have tried turning off the sip helper
by setting AUTOHELPERS=No and
DONT_LOAD=nf_nat_sip,nf_conntrack_sip, but that didn't help.
Any help appreciated!

Any sort of Shorewall configuration issue would show up more or less
immediately, not after several hours.

Have you looked at the eth-eth0 stats when this problem occurs (ip -s
link ls dev eth-eth0)? Also, check your log for messages indicating
that the conntrack table is full.

If those tips don't help, capture a 'shorewall dump' the next time
this occurs and forward it to me; I'll see if I can see anything that
would help pin this down.

- -Tom
- --
Tom Eastep \ Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \ understand
\_______________________________________________

[Ian Jones]

Tom,

thanks for your help. See below.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Ian Jones
Hello. I have installed shorewall as a nat router for my Asterisk
PBX on Debian 8.8 from the Debian package.
shorewall version 4.6.4.3
ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue
state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd
00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever
preferred_lft forever inet6 ::1/128 scope host valid_lft forever
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state
UP group default qlen 1000 link/ether 4c:cc:6a:24:8f:be brd
ff:ff:ff:ff:ff:ff inet 192.168.71.30/24 brd 192.168.71.255 scope
global eth-intern valid_lft forever preferred_lft forever inet6
fe80::4ecc:6aff:fe24:8fbe/64 scope link valid_lft forever
preferred_lft forever 3: eth-ext1: <BROADCAST,MULTICAST> mtu 1500
qdisc noop state DOWN group default qlen 1000 link/ether
<BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc prio state UP
group default qlen 1000 link/ether 00:26:55:d4:a5:f5 brd
ff:ff:ff:ff:ff:ff inet xx.xx.xx.xx/29 brd xx.xx.xx.xx scope global
eth-ext0 valid_lft forever preferred_lft forever inet6
::xxx:xxx:xxx:xxx/64 scope global mngtmpaddr dynamic valid_lft
3598sec preferred_lft 3598sec inet6 xxx::xxx:xxx:xxx:xxx/64 scope
link valid_lft forever preferred_lft forever
ip route show default via xx.xx.xx.xx dev eth-ext0 10.0.0.0/8 via
192.168.71.6 dev eth-intern xx.xx.xx.xx/29 dev eth-ext0 proto
kernel scope link src xx.xx.xx.xx 192.168.71.0/24 dev eth-intern
proto kernel scope link src 192.168.71.30
Shorewall is running on 192.168.71.30, and Asterisk on
# sip SIP(DNAT) net loc:192.168.71.8:5060 udp
5060 SIP(DNAT) net loc:192.168.71.8:5060 tcp
5060 # rtp DNAT net loc:192.168.71.8:10000-10020
udp 10000:10020 # stun DNAT net
loc:192.168.71.8:3478 udp 3478 # iax2 DNAT net
loc:192.168.71.8:4569 udp 4569
This all works fine - for a few hours! Then all the external
Asterisk peers become unreachable and remain so. I can also
reproduce the problem by restarting Asterisk, or by reloading
sip.conf. I can remedy the problem by stopping the external
interface for a couple of minutes, then restarting it. The Asterisk
peers become reachable again and all is well, for a few hours.
There is no problem with IAX, the IAX peers remain reachable.
I also have a Cisco DSL router, and when I route all the Asterisk
traffic through that, it works fine and everything is very stable
with the same Asterisk configuration, so it seems to be a problem
with the shorewall router. I have tried turning off the sip helper
by setting AUTOHELPERS=No and
DONT_LOAD=nf_nat_sip,nf_conntrack_sip, but that didn't help.
Any help appreciated!

Any sort of Shorewall configuration issue would show up more or less
immediately, not after several hours.

It's easy to reproduce - I just have to restart Asterisk.

Have you looked at the eth-eth0 stats when this problem occurs (ip -s
link ls dev eth-eth0)? Also, check your log for messages indicating
that the conntrack table is full.

ip -s link ls dev eth-ext0
4: eth-ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc prio state
UP mode DEFAULT group default qlen 1000
link/ether 00:26:55:d4:a5:f5 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
57773389 108860 0 0 0 7873
TX: bytes packets errors dropped carrier collsns
28459124 92927 0 0 0 0

There's nothing in 'shorewall show log' other than dropped packets (none
from the external peers).

If those tips don't help, capture a 'shorewall dump' the next time
this occurs and forward it to me; I'll see if I can see anything that
would help pin this down.

Many thanks - I'm sending the dump to you separately.

Regards
Ian

- -Tom
- --
Tom Eastep \ Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \ understand
\_______________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJZRuR5AAoJEJbms/JCOk0QJRAQAJuexkMgEanYKeu7tOdt9mJ2
Pd4t63Y4S+n1MPhbKMaMxl5kh7ZTIQzYdZ+t3jrMv1+KOq8dSByJxdrpCCfmI3tn
TYE2O0pGAaQshbuEp4XnesMfu6a/dg1/NXG37uE1jbbI0X+7EgKqTiyzhrQVD0TZ
0MycUQzlOVmX8mNXwRUj+6xkIQb4Y2NjhAtaMWq0vUYOPr0ZHoKr9Sal9w5C1MnU
K4POhXCOCqkjEIIoT88BihqBtf0Ax/yZrRBFGkcQdIFq7/MgTXdqqz3ee2PgPDph
GkZ6MuY9C5V4CwavLCxeAJIHpVmhQZl0qhjqC0zQI3DmwZIgy1Vreglv4DVXnZ3g
yIdd792ZjQ5Os5OoQxIEe5f4us3dMF6E2Ma7YGSaIEYtQMGY/EpQSUe0WC1NaygB
v3te6bQzr5/kxa9mx1B4eGi0LUbcp0wY4UDhG4wvFVOrLET67HOdpA85baBuSk0R
n3H2QYrkAJAl04Q7/gHjQlgAhPBLY13Qg9ZSgemnCkLzLplTTbQcbXP50cbKO75/
BHh43kyGroRfNlwvOM1wKIxAoJibG7V6N48RMQW2QI+Yv0f2jF1rMQDzlxOq8Ycn
DlyvsotRB+WcRliFyWCf0ocOTt6CXiC326iL+wuRGmz8Fg/ghy5WAjbOpltApqdb
nB4MgZdWzRNUGZ63t94C
=vDou
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Tom Eastep]

Post by Ian Jones
Tom,
thanks for your help. See below.

Post by Ian Jones
There's nothing in 'shorewall show log' other than dropped
packets (none from the external peers).

Look at your system log -- conntrack overflows aren't shown by
'shorewall show log'

- -Tom

- --
Tom Eastep \ Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \ understand
\_______________________________________________

[Ian Jones]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Ian Jones
Tom,
thanks for your help. See below.

Post by Ian Jones
There's nothing in 'shorewall show log' other than dropped
packets (none from the external peers).

Look at your system log -- conntrack overflows aren't shown by
'shorewall show log'
- -Tom

The only references in any of the log files to conntrack are of the sort:
Jun 17 10:18:32 jonas kernel: [65350.516966] nf_conntrack version 0.5.0
(16384 buckets, 65536 max)
Jun 17 10:18:57 jonas kernel: [65375.214169] nf_conntrack: automatic
helper assignment is deprecated and it will be removed soon. Use the
iptables CT target to attach helpers instead.

Nothing about overflows.

Regards
Ian

[Ian Jones]

Hello,

I am posting a dump file.

Regards

Ian

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Post by Ian Jones
Tom,
thanks for your help. See below.

Post by Ian Jones
There's nothing in 'shorewall show log' other than dropped
packets (none from the external peers).

Look at your system log -- conntrack overflows aren't shown by
'shorewall show log'
- -Tom
- --
Tom Eastep \ Q: What do you get when you cross a mobster with
Shoreline, \ an international standard?
Washington, USA \ A: Someone who makes you an offer you can't
http://shorewall.org \ understand
\_______________________________________________
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: GPGTools - http://gpgtools.org
iQIcBAEBCAAGBQJZRzUzAAoJEJbms/JCOk0QkVkQAKfu1xCYsCCHseb+viebY4aZ
XQf1QBrUeMZ40XEKQcolFJvXoXocPqApEAwkmCeF0Z8UeiPzEdT/L3GBHiL/FwwO
o621jzJiQxxED8lO7+Zw3QBwfJxqWwkgoCE7sCV43jtgxC0d89PZJvRawxOa94v5
XZ3StUZL2bFSllu0In5abU0bYdMkGb/ULBxae98s+vLHi1q2m4zmd+fa2wE0YOlz
iMhN1fDNsElM6+AohjY3xKvHG3Sf7XEXgN1cEQeqG+/kgbv8q/KLxy1ChpOubMOc
12vHkIa0DEmZKfvf0usfbmGEBuySm5S0D2Cbxx4OlGA4i4/+5ddSmoPPlfFLQpcn
rAUATukPKMKldG5syrkkQnLUg0ZeY2spQ/0MgUHq4KaY2Io+M31X0YrvzvbaE3pq
nIGwghkv9iTQsP9l6WvLIAm4zgFvA2Cybg8F3wYWyreA26S53oT/FonaGlptzppZ
22d+AtnkcZ/Vk+Tdma0p9+YoiyFKgrhJNQstLQBdAs9SeQB454IgIylVbXO+BGIA
PWOzYBCN0g7fmbLXmIzFMzW0B4oWIz+om4X1osvgTO+6TehTFvjvTc5m2NJ6B0/H
EPiKTZ6iFPzwCq9oL/gB0VkPKwJwfV77thFcYREOZUiu+D4Behbm625wSCg+zuyc
08yp+mo3/XQvvWQhLDe+
=ViOl
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Ryan Joiner]

Hello,
I am posting a dump file.
Regards
Ian

--------------------------------------
Ian,
Looking at your original email, I don’t do SIP(DNAT), I just do DNAT. (I’m not sure what that does. Good call on disabling the helpers, I use Shorewall on CentOS and have always needed to disable the helpers.

What flavor of asterisk do you use? Is it straight asterisk with CLI, or is it FreePBX, Elastix or something else?

Just curious as you have to put your public IP in the SIP settings properly for asterisk.

Also, is nat enabled for the extensions? What devices are you using? I use yealink and have sometimes had to be sure they are saying “hi” to keep alive, although, probably not the issue if you are fine with the Cisco. There might be helpers on the cisco though that mask the need to fix up the asterisk nat settings.

Ryan

[Ian Jones]

Post by Ian Jones
Hello,
I am posting a dump file.
Regards
Ian
--------------------------------------
Ian,
Looking at your original email, I don’t do SIP(DNAT), I just do DNAT. (I’m not sure what that does. Good call on disabling the helpers, I use Shorewall on CentOS and have always needed to disable the helpers.
What flavor of asterisk do you use? Is it straight asterisk with CLI, or is it FreePBX, Elastix or something else?

Straight Asterisk.

Post by Ian Jones
Just curious as you have to put your public IP in the SIP settings properly for asterisk.

If you are referring to externaddr and localnet, yes they are both
correctly set.

Post by Ian Jones
Also, is nat enabled for the extensions? What devices are you using? I use yealink and have sometimes had to be sure they are saying “hi” to keep alive, although, probably not the issue if you are fine with the Cisco. There might be helpers on the cisco though that mask the need to fix up the asterisk nat settings.

Some devices are phones and have nat=force_rport,comedia, others are sip
providers and have a mixture, some with nat=no. All external peers show
the same behaviour.

Regards
Ian

Post by Ian Jones
Ryan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Ian Jones]

I am becoming more convinced that this is a nat issue, since I have
installed Asterisk on the firewall itself, and it seems to run normally
with no issues when restarting. The feedback from the Asterisk peer
support site was that: Asterisk is sending OPTIONs, but the peer is not
replying, or the request or replies are getting lost, in the network.
Possibly an automatic NAT or firewall rule has timed out. There is no
evidence of anything wrong with Asterisk.

Is there anyway to specify the UDP connection timeout?

Regards

Ian

Post by Ian Jones
Hello. I have installed shorewall as a nat router for my Asterisk PBX
on Debian 8.8 from the Debian package.
shorewall version
4.6.4.3
ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
group default
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth-intern: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
pfifo_fast state UP group default qlen 1000
link/ether 4c:cc:6a:24:8f:be brd ff:ff:ff:ff:ff:ff
inet 192.168.71.30/24 brd 192.168.71.255 scope global eth-intern
valid_lft forever preferred_lft forever
inet6 fe80::4ecc:6aff:fe24:8fbe/64 scope link
valid_lft forever preferred_lft forever
3: eth-ext1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
group default qlen 1000
link/ether 00:26:55:d4:a5:f4 brd ff:ff:ff:ff:ff:ff
4: eth-ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc prio
state UP group default qlen 1000
link/ether 00:26:55:d4:a5:f5 brd ff:ff:ff:ff:ff:ff
inet xx.xx.xx.xx/29 brd xx.xx.xx.xx scope global eth-ext0
valid_lft forever preferred_lft forever
inet6 ::xxx:xxx:xxx:xxx/64 scope global mngtmpaddr dynamic
valid_lft 3598sec preferred_lft 3598sec
inet6 xxx::xxx:xxx:xxx:xxx/64 scope link
valid_lft forever preferred_lft forever
ip route show
default via xx.xx.xx.xx dev eth-ext0
10.0.0.0/8 via 192.168.71.6 dev eth-intern
xx.xx.xx.xx/29 dev eth-ext0 proto kernel scope link src xx.xx.xx.xx
192.168.71.0/24 dev eth-intern proto kernel scope link src
192.168.71.30
Shorewall is running on 192.168.71.30, and Asterisk on 192.168.71.8.
# sip
SIP(DNAT) net loc:192.168.71.8:5060 udp 5060
SIP(DNAT) net loc:192.168.71.8:5060 tcp 5060
# rtp
DNAT net loc:192.168.71.8:10000-10020 udp 10000:10020
# stun
DNAT net loc:192.168.71.8:3478 udp 3478
# iax2
DNAT net loc:192.168.71.8:4569 udp 4569
This all works fine - for a few hours! Then all the external Asterisk
peers become unreachable and remain so. I can also reproduce the
problem by restarting Asterisk, or by reloading sip.conf. I can remedy
the problem by stopping the external interface for a couple of
minutes, then restarting it. The Asterisk peers become reachable again
and all is well, for a few hours.
There is no problem with IAX, the IAX peers remain reachable.
I also have a Cisco DSL router, and when I route all the Asterisk
traffic through that, it works fine and everything is very stable with
the same Asterisk configuration, so it seems to be a problem with the
shorewall router. I have tried turning off the sip helper by setting
AUTOHELPERS=No and DONT_LOAD=nf_nat_sip,nf_conntrack_sip, but that
didn't help.
Any help appreciated!
Regards,
Ian
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

[Ryan Joiner]

Post by Ian Jones
I am becoming more convinced that this is a nat issue, since I have
installed Asterisk on the firewall itself, and it seems to run
normally with no issues when restarting. The feedback from the
Asterisk peer support site was that: Asterisk is sending OPTIONs, but
the peer is not replying, or the request or replies are getting lost,
in the network. Possibly an automatic NAT or firewall rule has timed
out. There is no evidence of anything wrong with Asterisk.
Is there anyway to specify the UDP connection timeout?
Regards
Ian

Ian,
I should have looked at your dump first. I see the helpers are still
loaded despite you telling them to not load. That could be because
something other than shorewall loaded them.

I know on CentOS it is rmmod "module", so rmmod nf_conntrack_sip. I'm
not so sure for Debian. Maybe it is:

modprobe -r nf_conntrack_sip
modprobe -r nf_nat_sip

Then see if the remote extensions magically reconnect.

Ryan - JLink Communications

[Tom Eastep]

Post by Ryan Joiner

Post by Ian Jones
I am becoming more convinced that this is a nat issue, since I have
installed Asterisk on the firewall itself, and it seems to run
normally with no issues when restarting. The feedback from the
Asterisk peer support site was that: Asterisk is sending OPTIONs, but
the peer is not replying, or the request or replies are getting lost,
in the network. Possibly an automatic NAT or firewall rule has timed
out. There is no evidence of anything wrong with Asterisk.
Is there anyway to specify the UDP connection timeout?
Regards
Ian

Ian,
I should have looked at your dump first. I see the helpers are still
loaded despite you telling them to not load. That could be because
something other than shorewall loaded them.
I know on CentOS it is rmmod "module", so rmmod nf_conntrack_sip. I'm
modprobe -r nf_conntrack_sip
modprobe -r nf_nat_sip
Then see if the remote extensions magically reconnect.

Here are the problem requests:

udp 17 3596 src=192.168.71.8 dst=109.176.95.130 sport=5060
dport=5060 [UNREPLIED] src=109.176.95.130 dst=xx.xx.xx.xx sport=5060
dport=5060 mark=0 use=2

(that is a Masqueraded request from the local server to 109.176.95.130)

udp 17 2522 src=94.23.212.19 dst=xx.xx.xx.xx sport=5229 dport=5060
[UNREPLIED] src=192.168.71.8 dst=94.23.212.19 sport=5060 dport=5229
mark=0 use=2

(that is a DNATed request from 94.23.212.19 that is redirected to the
local server)

udp 17 1228 src=195.154.185.103 dst=xx.xx.xx.xx sport=5105
dport=5060 [UNREPLIED] src=192.168.71.8 dst=195.154.185.103 sport=5060
dport=5105 mark=0 use=2

(another DNATed request)

All that I can say is that these entries are consistent with the ruleset.

-Tom

[Ian Jones]

Post by Tom Eastep

Post by Ryan Joiner

Post by Ian Jones
I am becoming more convinced that this is a nat issue, since I have
installed Asterisk on the firewall itself, and it seems to run
normally with no issues when restarting. The feedback from the
Asterisk peer support site was that: Asterisk is sending OPTIONs, but
the peer is not replying, or the request or replies are getting lost,
in the network. Possibly an automatic NAT or firewall rule has timed
out. There is no evidence of anything wrong with Asterisk.
Is there anyway to specify the UDP connection timeout?
Regards
Ian

Ian,
I should have looked at your dump first. I see the helpers are still
loaded despite you telling them to not load. That could be because
something other than shorewall loaded them.
I know on CentOS it is rmmod "module", so rmmod nf_conntrack_sip. I'm
modprobe -r nf_conntrack_sip
modprobe -r nf_nat_sip
Then see if the remote extensions magically reconnect.

udp 17 3596 src=192.168.71.8 dst=109.176.95.130 sport=5060
dport=5060 [UNREPLIED] src=109.176.95.130 dst=xx.xx.xx.xx sport=5060
dport=5060 mark=0 use=2
(that is a Masqueraded request from the local server to 109.176.95.130)
udp 17 2522 src=94.23.212.19 dst=xx.xx.xx.xx sport=5229 dport=5060
[UNREPLIED] src=192.168.71.8 dst=94.23.212.19 sport=5060 dport=5229
mark=0 use=2
(that is a DNATed request from 94.23.212.19 that is redirected to the
local server)
udp 17 1228 src=195.154.185.103 dst=xx.xx.xx.xx sport=5105
dport=5060 [UNREPLIED] src=192.168.71.8 dst=195.154.185.103 sport=5060
dport=5105 mark=0 use=2
(another DNATed request)
All that I can say is that these entries are consistent with the ruleset.
-Tom
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Curiouser and curiouser... There is no way to change the timeout values
then?

Regards
Ian

[Ian Jones]

Post by Ryan Joiner

Post by Ian Jones
I am becoming more convinced that this is a nat issue, since I have
installed Asterisk on the firewall itself, and it seems to run
normally with no issues when restarting. The feedback from the
Asterisk peer support site was that: Asterisk is sending OPTIONs, but
the peer is not replying, or the request or replies are getting lost,
in the network. Possibly an automatic NAT or firewall rule has timed
out. There is no evidence of anything wrong with Asterisk.
Is there anyway to specify the UDP connection timeout?
Regards
Ian

Ian,
I should have looked at your dump first. I see the helpers are still
loaded despite you telling them to not load. That could be because
something other than shorewall loaded them.
I know on CentOS it is rmmod "module", so rmmod nf_conntrack_sip. I'm
modprobe -r nf_conntrack_sip
modprobe -r nf_nat_sip
Then see if the remote extensions magically reconnect.
Ryan - JLink Communications
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Ryan,

thanks for the suggestions. I have tried with and without the sip
helpers, by setting DONT_LOAD=nf_nat_sip,nf_conntrack_sip and by
removing the modules. It doesn't seem to make any difference, but I will
check again.

Regards
Ian

[Tom Eastep]

Post by Ian Jones

Post by Ryan Joiner

Post by Ian Jones
I am becoming more convinced that this is a nat issue, since I have
installed Asterisk on the firewall itself, and it seems to run
normally with no issues when restarting. The feedback from the
Asterisk peer support site was that: Asterisk is sending OPTIONs, but
the peer is not replying, or the request or replies are getting lost,
in the network. Possibly an automatic NAT or firewall rule has timed
out. There is no evidence of anything wrong with Asterisk.
Is there anyway to specify the UDP connection timeout?
Regards
Ian

Ian,
I should have looked at your dump first. I see the helpers are still
loaded despite you telling them to not load. That could be because
something other than shorewall loaded them.
I know on CentOS it is rmmod "module", so rmmod nf_conntrack_sip. I'm
modprobe -r nf_conntrack_sip
modprobe -r nf_nat_sip
Then see if the remote extensions magically reconnect.
Ryan - JLink Communications
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Ryan,
thanks for the suggestions. I have tried with and without the sip
helpers, by setting DONT_LOAD=nf_nat_sip,nf_conntrack_sip and by
removing the modules. It doesn't seem to make any difference, but I will
check again.

Setting DONT_LOAD is not enough. You must also

a) set HELPERS in shorewall.conf to specify the helpers that you want.
b) set AUTOHELPERS=No
c) Either use macros for all traffic that you want to use helpers for,
or add the appropriate entries to /etc/shorewall/conntrack.

And yes -- I need to update the FAQ with this information.

-Tom

[Ryan Joiner]

Post by Ian Jones

Post by Ryan Joiner

Post by Ian Jones
I am becoming more convinced that this is a nat issue, since I have
installed Asterisk on the firewall itself, and it seems to run
normally with no issues when restarting. The feedback from the
Asterisk peer support site was that: Asterisk is sending OPTIONs,
but the peer is not replying, or the request or replies are getting
lost, in the network. Possibly an automatic NAT or firewall rule has
timed out. There is no evidence of anything wrong with Asterisk.
Is there anyway to specify the UDP connection timeout?
Regards
Ian

Ian,
I should have looked at your dump first. I see the helpers are still
loaded despite you telling them to not load. That could be because
something other than shorewall loaded them.
I know on CentOS it is rmmod "module", so rmmod nf_conntrack_sip. I'm
modprobe -r nf_conntrack_sip
modprobe -r nf_nat_sip
Then see if the remote extensions magically reconnect.
Ryan - JLink Communications
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Shorewall-users mailing list
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Ryan,
thanks for the suggestions. I have tried with and without the sip
helpers, by setting DONT_LOAD=nf_nat_sip,nf_conntrack_sip and by
removing the modules. It doesn't seem to make any difference, but I
will check again.
Regards
Ian

Ian,

Understood. As long as the nf_conntrack_sip and nf_nat_sip show up in
the shorewall dump, that means they are loaded and you will have issues.

[Zrin Ziborski]

Post by Ian Jones
Shorewall is running on 192.168.71.30, and Asterisk on 192.168.71.8.
# sip
SIP(DNAT) net loc:192.168.71.8:5060 udp 5060
SIP(DNAT) net loc:192.168.71.8:5060 tcp 5060
# rtp
DNAT net loc:192.168.71.8:10000-10020 udp 10000:10020
# stun
DNAT net loc:192.168.71.8:3478 udp 3478
# iax2
DNAT net loc:192.168.71.8:4569 udp 4569
This all works fine - for a few hours! Then all the external Asterisk
peers become unreachable and remain so. I can also reproduce the
problem by restarting Asterisk, or by reloading sip.conf. I can remedy
the problem by stopping the external interface for a couple of
minutes, then restarting it. The Asterisk peers become reachable again
and all is well, for a few hours.
There is no problem with IAX, the IAX peers remain reachable.
I also have a Cisco DSL router, and when I route all the Asterisk
traffic through that, it works fine and everything is very stable with
the same Asterisk configuration, so it seems to be a problem with the
shorewall router. I have tried turning off the sip helper by setting
AUTOHELPERS=No and DONT_LOAD=nf_nat_sip,nf_conntrack_sip, but that
didn't help.

Hello Ian,

I'd suggest to make packet traces, e.g. with tcpdump and to check which
packets and when do not get replied.
Check if the packets originating from the PBX are actually seen on the
router and actually do leave the router.
Check if any reply packets actually do reach the router.

I have just
DNAT net pbx:$PBXIP udp 5060
DNAT net pbx:$PBXIP udp 10000:10999

or
ACCEPT net:$SIPPROVIDER pbx
DNAT- net $PBXIP udp 5060
DNAT net pbx:$PBXIP udp 10000:10999


You're writing that upon the start it works for few hours, but if you
just restart Asterisk (Even after just a minute or two? Without any
change on the router?), you can reproduce the problem. Is that correct?

I've been investigating a similar problem and it turned out that the
problem was the internet providers modem, which would start blocking UDP
traffic (but not TCP!) fo no apparent reason, perhaps after a distinct
amount of traffic passed through it. You can imagine...

Good luck,
Zrin