RT-N66U port forward rule stopped working after upgrade to 380.68_4

[Deleted member 55165]

I have an Asus RT-N66U that was running Asuswrt-Merlin 380.67 and had a working port forward rule configured this way, but after upgrading to 380.68_4, it has ceased to work:

Port range: 35000
Local IP: 192.168.1.136 (manually assigned IP to wired NVR)
Local port: 35000
Protocol: TCP

I have DDNS configured and access an IP camera NVR over this port, and it was working without a problem for over a year.

Things I've tried that have not fixed it:

• Disable/enable/recreate the port forward rule
• Downgrade to Asuswrt-Merlin 380.67
  
• Reset to factory defaults on 380.67 and 380.68_4
• Re-flash back to latest stock ASUS firmware
• Power-cycle the modem, router, and NVR
• Verified I can log into NVR on LAN and logins are not being blocked
• Enabled DMZ for 192.168.1.136

I'm on Comcast and port 35000 is not in their list of blocked ports. I can access the NVR correctly while on the LAN via the public DDNS URL, so I know there is a functioning service running there. I enabled web access over WAN for the router web interface, and can access it remotely without a problem, and see in /tmp/nat_rules_eth0_eth0 that 8080 is forwarded to 80 so that rule is working. nmap shows 8080 as 'open' but when I look at 35000, it shows as 'filtered'. Here is the output of /tmp/nat_rules_eth0_eth0:

admin@RT-N66U-DC68:/tmp# cat nat_rules_eth0_eth0
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:VSERVER - [0:0]
:LOCALSRV - [0:0]
:VUPNP - [0:0]
:PUPNP - [0:0]
:DNSFILTER - [0:0]
:PCREDIRECT - [0:0]
-A PREROUTING -d [WAN PUBLIC IP REMOVED] -j VSERVER
-A VSERVER -p tcp -m tcp --dport 8080 -j DNAT --to-destination 192.168.1.1:80
-A VSERVER  -p tcp -m tcp --dport 35000 -j DNAT --to-destination 192.168.1.136:35000
-A VSERVER -j VUPNP
-A POSTROUTING -o eth0 -j PUPNP
-A POSTROUTING  -o eth0 ! -s [WAN PUBLIC IP REMOVED] -j MASQUERADE
-A POSTROUTING  -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE
COMMIT

I'm at my wits end over something that seems so simple, so please let me know if I am missing anything here. I'm about at the point where I'm ready to replace this hardware with something else! Any help would be much appreciated, thanks.

 

[mstombs]

Not yet on this firmware, but try toggling the WAN IP local nat loopback setting. IIRC it has options for Asus or Merlin methods. Must be working if you can access via the the DDNS url via LAN, but worth trying both.

 

[Deleted member 55165]

Ok, NAT Loopback is currently set to Asus, but I believe I also tried the 'Merlin' and 'Disable' options with no difference. If NAT Loopback changes require a reboot, I will need to wait until early morning to test them out so that I don't have client disconnects.

 

[RMerlin]

If you are having the same issue with all these firmware releases then the problem is unlikely to be related to your router. I'd check your target device first, and ensure that your modem is still in bridged mode.

 

[Deleted member 55165]

If you are having the same issue with all these firmware releases then the problem is unlikely to be related to your router. I'd check your target device first, and ensure that your modem is still in bridged mode.

The modem is an older Motorola SB6120 and nothing has changed AFAIK. The issue only started after the firmware update.

If I create a dummy port forward rule for the web interface, for any random port to 192.168.1.1:80, it works and the port is open when I check with nmap. The fact that I can access the NVR directly when on the LAN via its IP, and via DDNS (mydomain.com:35000), should show there is no issue with it, right? I'm not sure what changed and not sure how I can further debug it.

 

[Veky]

Can you change the port 35000 on the NVR to some well known port and then give it a shot?

 

[RMerlin]

The fact that I can access the NVR directly when on the LAN via its IP, and via DDNS (mydomain.com:35000), should show there is no issue with it, right? I'm not sure what changed and not sure how I can further debug it.

Check that the NVR does not have a firewall that prevents connections from IPs outside of your LAN.

 

[Deleted member 55165]

When I went to look at the port setup on the NVR, I noticed that the DHCP network setup was incorrect. The gateway was set to 192.168.1.2, which is a TP-Link router running dd-wrt, that is wired to the RT-N66U, running in AP mode to extend the signal upstairs. The NVR was configured for DHCP and was defaulting to this setting for some reason. Once I switched it to a static IP and set the gateway to 192.168.1.1, all was working again. Is there any configuration I should add to Asuswrt when using a second wired router in AP mode to prevent this in the future? Thanks for all the help.

 

[RMerlin]

Make sure you only have one DHCP server running on your LAN, otherwise it will be a race as to which DHCP server answers requests first.

The DHCP server should be disabled on that AP - you should never run more than one DHCP server on a network. Chances are your NVR asked for a new DHCP lease while you were rebooting the RT-N66U, so it got a lease from the TP-Link.