Why didn't I need a hairpin NAT with my DD-WRT setup?

Question

My old DD-WRT router was dying, so I grabbed a UniFi EdgeRouter, which is, stylistically, much more like a "real router". I have various public IPs that I have 1-to-1 NAT setup for, i.e. the internal system has an IP of 192.168.123.134 , and any external requests to 173.13.139.236 get translated to the internal IP and back.

With the new router, I had to additionally setup hairpin NAT rules, so that internal systems could reach 173.13.139.236 , by having their requests translated to the internal IP but with a source IP on the router (i.e. masqueraded NAT).

(The specific issue, as I understand it, is that if you just NAT a packet that is from an internal address so that its destination is also to an internal address, then the reply just goes back directly to the requester, but the requester sent its packet to the router, so when it sees the reply come back from not-the-router, it drops the packet as invalid.)

With my DD-WRT router, I didn't have to do the hairpin NAT rule, and I don't understand why.

Specifically, the entire config for that IP on my DD-WRT system, as far as I know!, was:

iptables -t nat -I PREROUTING -d 173.13.139.236 -j DNAT --to 192.168.123.134
iptables -t nat -I POSTROUTING -s 192.168.123.134 -j SNAT --to 173.13.139.236
iptables -I FORWARD -d 192.168.123.134 -j ACCEPT

This did, in fact, work. Indeed, it worked for years. Why?

It's totally possible that there's some other config in the DD-WRT setup that handles this, but if there is, I have no idea where it would be; I reviewed the entire config when I changed routers, and I saw nothing else related to those IPs.

Answer 1

I think the DD-WRT interface used the term "Internet NAT Redirection" for the correction of hairpin NAT issues which was active by default and because it probably "just work as expected" you simply were not aware of its existence.

Rather than on specific IP-addresses (and port numbers) that was probably effected in/with iptables with a generic and not very obvious looking rule for traffic to the WAN interface (not necessarily listed by it's IP-address) originating from your LAN networks/interfaces or with a similar effect, for traffic NOT originating from the WAN.

Think along the lines of

insmod ipt_mark 
insmod xt_mark 
iptables -t mangle -A PREROUTING -i ! `get_wanface` -d `nvram get wan_ipaddr` -j MARK --set-mark 0xd001 
iptables -t mangle -A PREROUTING -j CONNMARK --save-mark 
iptables -t nat -A POSTROUTING -m mark --mark 0xd001 -j MASQUERADE

Source: https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=545301

Answer 2

Following from some of the threads laid by HBruijn's answer, and some iptables dumping from the router itself, I think I found it. I couldn't have gotten there without HBruijn's answer, but it wasn't at the level of detail I wanted, so I thought I'd share.

https://svn.dd-wrt.com/ticket/1868 is a bug report on an issue where loopback was broken, and it gives the example simple command of:

iptables -t nat -I POSTROUTING -o br0 -s 192.168.1.0/24 -d 192.168.1.0/24 -j MASQUERADE

A number of places mentioned a particular option, such as https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=82919&postdays=0&postorder=dsc&start=0 :

In your webgui under Security > Firewall

You are making sure to have "Filter WAN NAT Redirection " unchecked?

Which led me to https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=643132 , which shows the specific changes that that option causes, which I was able to confirm on my own router directly.

With "Filter WAN NAT Redirection" unchecked:

root@Basement Router:~# iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 2438 packets, 173K bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       0    --  *      *       0.0.0.0/0            173.13.139.237      to:192.168.123.133
    0     0 DNAT       0    --  *      *       0.0.0.0/0            173.13.139.236      to:192.168.123.134
    0     0 DNAT       0    --  *      *       0.0.0.0/0            173.13.139.235      to:192.168.123.132
    0     0 DNAT       icmp --  *      *       0.0.0.0/0            173.13.139.233      to:192.168.123.254
    0     0 TRIGGER    0    --  *      *       0.0.0.0/0            173.13.139.233      TRIGGER type:dnat match:0 relate:0

Chain POSTROUTING (policy ACCEPT 3 packets, 174 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 SNAT       0    --  *      *       192.168.123.133      0.0.0.0/0           to:173.13.139.237
    0     0 SNAT       0    --  *      *       192.168.123.134      0.0.0.0/0           to:173.13.139.236
    0     0 SNAT       0    --  *      *       192.168.123.132      0.0.0.0/0           to:173.13.139.235
 2444  140K SNAT       0    --  *      vlan1   0.0.0.0/0            0.0.0.0/0           to:173.13.139.233
    0     0 RETURN     0    --  *      br0     0.0.0.0/0            0.0.0.0/0           PKTTYPE = broadcast
    1   339 MASQUERADE  0    --  *      br0     192.168.123.0/24     192.168.123.0/24

Chain OUTPUT (policy ACCEPT 847 packets, 55575 bytes)
 pkts bytes target     prot opt in     out     source               destination

With "Filter WAN NAT Redirection" checked:

root@Basement Router:~# iptables -L -v -n -t nat
Chain PREROUTING (policy ACCEPT 957 packets, 64933 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DNAT       0    --  *      *       0.0.0.0/0            173.13.139.237      to:192.168.123.133
    0     0 DNAT       0    --  *      *       0.0.0.0/0            173.13.139.236      to:192.168.123.134
    0     0 DNAT       0    --  *      *       0.0.0.0/0            173.13.139.235      to:192.168.123.132
    0     0 DNAT       icmp --  *      *       0.0.0.0/0            173.13.139.233      to:192.168.123.254
    0     0 TRIGGER    0    --  *      *       0.0.0.0/0            173.13.139.233      TRIGGER type:dnat match:0 relate:0

Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 SNAT       0    --  *      *       192.168.123.133      0.0.0.0/0           to:173.13.139.237
    0     0 SNAT       0    --  *      *       192.168.123.134      0.0.0.0/0           to:173.13.139.236
    0     0 SNAT       0    --  *      *       192.168.123.132      0.0.0.0/0           to:173.13.139.235
 1025 57947 SNAT       0    --  *      vlan1   0.0.0.0/0            0.0.0.0/0           to:173.13.139.233
    0     0 DROP       0    --  *      br0     192.168.123.0/24     192.168.123.0/24

Chain OUTPUT (policy ACCEPT 348 packets, 22743 bytes)
 pkts bytes target     prot opt in     out     source               destination

The difference is with it unchecked it has:

Chain POSTROUTING (policy ACCEPT 3 packets, 174 bytes)
 pkts bytes target     prot opt in     out     source               destination
    1   339 MASQUERADE  0    --  *      br0     192.168.123.0/24     192.168.123.0/24

, and with it checked, that becomes a DROP rule.

So if I understand what's going on here correctly, with "Filter WAN NAT Redirection" unchecked (which it seems would do nothing), what actually happens, as y'all said, is the default behaviour of the router masquerading every connection on the local network that comes in from any non-WAN port.

So a connection from a random DHCP address, in my case say 192.168.123.10, to one of my static IPs, say 173.13.139.236, would go:

192.168.123.10 -> 173.13.139.236
After PREROUTING: 192.168.123.10 -> 192.168.123.134
After POSTROUTING: 192.168.123.254 [that's the router] on some high port -> 192.168.123.134

And then the return packet:

192.168.123.134 -> 192.168.123.254/high-port
After ... whatever un-does MASQUERADE: 192.168.123.134 -> 192.168.123.10
After PREROUTING: 173.13.139.236 -> 192.168.123.10