SIP request packets are dropped with NAT passthrough enabled on RT-N66W (380.61)

[vStache]

I have a RT-N66W running Asterix 11 pbx on 380.61 version of Merlin ASUSWRT.

I am not able to get Zoiper softphone on my iPhone to complete SIP registration or place calls unless the phone is connected to the LAN and the LAN address of the router is used as the host address for Asterisk.

The moment I use the external IP of the router, registration times out irrespective of where the phone is: connected to LAN or connected to the internet some other way.

As I investigated it, I found a number of anomalies:

1) Asterix can receive SIP requests from hosts it is registered with (callcentric, for example) even if SIP NAT passthrough is disabled.

2) Similarly, a PPTP connection can be made to the router even it NAT passrhrough is disabled for PPTP.

3) On the other hand, if SIP registration has to be initiated by another SIP client to the Asterix PBX, the only way for it to work is from the LAN side of the router using the LAN IP address of the Asterisk host (router).

Changing NAT passthrough or NAT helper has no effect. I tried putting the router in DMZ, forwarding port 5060 to the router LAN address and nothing helps.

I enabled firewall logging for dropped packets and watched the log. The packets to 5060 port are being dropped by the firewall no matter what settings I use for NAT helper or port forwarding. Only change with port forwarding or putting the router in DMZ is that the dropped packets show the LAN IP address as the destination address field of the dropped packets. Otherwise, external IP address shows.

Additionally, SIP request packets seem to disappear when the SIP client is connected to the LAN but uses the external IP address as the IP address. The packets are not shown as dropped by the firewall and they don't seem to reach the PBX. The samething happens if firewall is disabled. The SIP packets are not dropped but don't reach the PBX.

If the SIP client uses the LAN address of the router, the registration request reaches the PBX.

I am stumped and would welcome any suggestions to resolve this issue.

 

[TeHashX]

I had the same issue until I selected Merlin as Nat Loopback under Firewall settings on router ui.
https://www.hqt.ro/asterisk-voip-server-running-on-asuswrt-routers/

 

[vStache]

I already have Merlin as NAT loop back selected. I tried both Asus and Merlin. Problem is the same. The request packets do not reach the PBX.

This, as I understand, only applies when the client is connected to the LAN but use the WAN address to connect to a device on the LAN.

I am looking at your linked page, will try what is suggested and post the results. Thanks for the response.

 

[vStache]

I added the firewall rules suggested on the site and executed the script. The packets are still dropped. Please see the log entries below:

Sep 1 11:10:43 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.2.20 DST=173.29.79.83 <1>LEN=555 TOS=0x00 PREC=0x00 TTL=48 ID=59060 PROTO=UDP <1>SPT=24196 DPT=5060 LEN=535
Sep 1 11:10:43 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.2.20 DST=173.29.79.83 <1>LEN=555 TOS=0x00 PREC=0x00 TTL=48 ID=20921 PROTO=UDP <1>SPT=24196 DPT=5060 LEN=535
Sep 1 11:10:44 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.2.20 DST=173.29.79.83 <1>LEN=555 TOS=0x00 PREC=0x00 TTL=48 ID=19844 PROTO=UDP <1>SPT=24196 DPT=5060 LEN=535
Sep 1 11:10:46 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.2.20 DST=173.29.79.83 <1>LEN=555 TOS=0x00 PREC=0x00 TTL=48 ID=62732 PROTO=UDP <1>SPT=24196 DPT=5060 LEN=535
Sep 1 11:10:51 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.2.20 DST=173.29.79.83 <1>LEN=555 TOS=0x00 PREC=0x00 TTL=48 ID=6836 PROTO=UDP <1>SPT=24196 DPT=5060 LEN=535
Sep 1 11:10:54 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.2.20 DST=173.29.79.83 <1>LEN=555 TOS=0x00 PREC=0x00 TTL=48 ID=943 PROTO=UDP <1>SPT=24196 DPT=5060 LEN=535
Sep 1 11:10:59 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.2.20 DST=173.29.79.83 <1>LEN=555 TOS=0x00 PREC=0x00 TTL=48 ID=24725 PROTO=UDP <1>SPT=24196 DPT=5060 LEN=535

 

[vStache]

Setting up port forwarding for the port 5060 fixed the problem with connecting from the LAN using external IP address. But it still does not work from the WAN.

 

[john9527]

@vStache For a test, change the '-A INPUT' to '-I INPUT' in the script

 

[Maturz]

I'm on the same version and RT-AC66U having kinda similar trouble, my problem manifests with the phone ringing but it's not possible to answer calling out works though. The way I can solve it is to change the static IP I have assigned my SIP phone to something else and then forward the ports (I need to open many more ports for my phone/service provider) to that IP instead then I just restart the sip phone and it works. I have done this twice now, IP shouldn't matter first mine was .3 then .33 now back again. I read something on another forum about this being a bug with the firmware not forwarding UPD packets correctly.

 

[vStache]

Tried -I option. That did not help. Log is as follows:

ep 1 13:53:35 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=11321 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533
Sep 1 13:53:36 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=52159 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533
Sep 1 13:53:37 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=17290 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533
Sep 1 13:53:39 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=8488 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533
Sep 1 13:53:43 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=11918 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533
Sep 1 13:53:44 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=36328 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533
Sep 1 13:53:45 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=33428 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533
Sep 1 13:53:46 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=29722 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533
Sep 1 13:53:47 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=45318 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533
Sep 1 13:53:48 kernel: DROP <4>DROP IN=eth0 OUT= MAC=08:62:66:3b:dd:18:a4:4c:11:8a:a5:d9:08:00 <1>SRC=172.56.10.190 DST=192.168.2.10 <1>LEN=553 TOS=0x00 PREC=0x00 TTL=52 ID=2452 PROTO=UDP <1>SPT=37590 DPT=5060 LEN=533

 

[john9527]

What's the IP address of your router?

 

[vStache]

External IP: 173.29.79.83. LAN IP: 192.168.2.10

The dropped packets show destination address as internal IP if the port 5060 is forwarded. Otherwise, they show external IP.

 

[john9527]

Let's make sure the rules are actually set.....via telnet/ssh please post the output of

iptables-save

 

[vStache]

Let's make sure the rules are actually set.....via telnet/ssh please post the output of

iptables-save

I checked and you are right. The rules disappear after reboot. Not sure how to make them persistent. The rules are in firewall-start in the folder /jffs/scripts.

Additionally, even if I use -I the rules registered show -A.

I reran the script after reboot and made sure the rules are present and found that the packets are not dropped. But the registration is still not going through. This is the same as disabling the firewall, I suppose. Even then the packets are not dropped but they are not getting to their destination.

Another side effect of the rules not being persistent is that they are lost every time I change any firewall settings from the GUI.

The output of iptables-save is attached when the rules are present.

Another strange thing is that the packets are neither in dropped nor in accepted list once the rules are added. I checked the log after switching the firewall to log accepted packets.

 

[john9527]

OK....that iptables-save looks correct....the added rules are at the top of the INPUT chain (-I). They will always show as -A in the iptables-save output.

As far as the script not working on reboot, the most common cause is that the file was saved in DOS/WIN format instead of Linux. Run

dos2unix /jffs/scripts/firewall-start

on the router.

Now, with those in place, let's revisit the NAT loopback setting. Due to some technical limitations on the MIPS routers, if you are using any of the Parental Controls function or QOS, it may invalidate the loopback function. Try setting it back to ASUS method.

 

[vStache]

OK....that iptables-save looks correct....the added rules are at the top of the INPUT chain (-I). They will always show as -A in the iptables-save output.

As far as the script not working on reboot, the most common cause is that the file was saved in DOS/WIN format instead of Linux. Run

dos2unix /jffs/scripts/firewall-start

on the router.

Now, with those in place, let's revisit the NAT loopback setting. Due to some technical limitations on the MIPS routers, if you are using any of the Parental Controls function or QOS, it may invalidate the loopback function. Try setting it back to ASUS method.

Running dos2unix does not change anything. That is not surprising because I created firewall-start directly on the router using vi. I still have to run "sh firewall-start" every time.

I am not using QOS or parental controls. I changed NAT loopback setting to Asus and that did not change anything: registration from LAN still works but does not work from WAN.

I am not sure what the NAT Passthrough setting for SIP is doing. It does not seem to have any effect on any SIP related behavior.

 

[vStache]

No more ideas!