I recently lost my Buffalo WHR-HP-G54 router which has served me faithfully for years running Tomato firmware.  I had difficulty finding any new router on the market, which had the NAT loopback feature as well as the ability to filter incoming IP addresses for a service port.

I found a Rosewill RNX-N300RT router from NewEgg to replace it, which accepts DD-WRT as firmware.  Tomato was not going to be an option for the new router, as it had fallen out of maintenance.  FWIW: It also has a long-standing bug in the syslog configuration where the firmware would just arbitrarily lose the address of the server to send the syslog packets to.

So after getting the firmware successfully loaded and configured, I discovered a nasty snag with DD-WRT: starting at a particular build number, NAT loopback support was dropped.  This was more than a little disheartening at first.  The description of the problem is here, and the ticket for the problem is here.

Essentially, if you have a service (say http) running on a server in your network, you have a dynamic dns entry for your WAN address, and use that dynamic dns entry to address the service from within your network, the router will not route the WAN address back into your own network.  I tried a list of solutions which people had posted, but none seemed to work properly for me.

What worked for me was A) adding a one-line script entry to the firewall, and B) adding some entries in the Port Forwarding for ports that were not open to all external addresses.  The script comes from an entry in the previous posts:

iptables -t nat -A POSTROUTING -j MASQUERADE

This is stored with the Save Firewall button under Admin / Scripts.  This line enables the router to allow the packet to re-enter the LAN.

In my port forwarding table, I have some services which do not filter the incoming IP address: e.g. 17 (Quote of the day), 443 (https).  For all these services, addressing the service with mylocation.dnsalias.net within my home network worked fine without anything beyond the firewall script.

It was the access points that were filtered by IP (RDP, etc) that would not work internally.  The MASQUERADE entry was properly forwarding the packets from the WAN address back into the LAN network, but then the Port Forwarding rules were being applied.  And without an unfiltered entry for the local network, or a filter matching the LAN subnet, the packet was suppressed.

So for the filtered ports only, I had to add additional port forwarding entries with the LAN’s subnet (192.168.17.0/24) as the external address so the router would honor the local LAN for access.

Once this forwarding was in place, everything worked fine using the dns address from within the LAN.