iptables: allow port forwarding destined to the WAN interface but from within the local network

Question

I know this question exist in a dozen forms already but most were about commercial wifi routers etc.

I have an Ubuntu 20.04LTS box with a bunch of interfaces set up as a firewall/NAT box, one of the interfaces is a WAN interface.

I have a bunch of port forwards on the WAN interface (enp4s0f0) to different internal hosts, rules like these (btw all rules below are on the "nat" chain):

-A PREROUTING -i enp4s0f0 -p tcp -m tcp --dport 8181 -j DNAT --to-destination 10.0.0.50:22

(forwards incoming WAN connections at port 8181 to the host 10.0.0.50, ssh port)

But if I'm on an internal host I also want to be able to reach this port forward without going explicitly to the other internal host, for example I have a DNS that already points to the WAN IP. "Out of the box" this doesn't work (I guess because of the explicit interface specification of the WAN if), so I've tried adding stuff to iptables but neither of the two extra rules I added seem to work:

1. -A PREROUTING -d -p tcp --dport 8181 -j DNAT --to-destination 10.0.0.50:22

2. -A PREROUTING -i enp3s0f0 -p tcp --dport 8181 -j DNAT --to-destination 10.0.0.50:22

(enp3s0f0 is the LAN interface on the internal network)

I guess I'm missing some simple magic here.

Would be cool to have a "catch all" rule that would make all packets originating from the internal LAN destined for the WAN interface to end up there before the WAN=>LAN port forwarding rules take place, then I wouldn't have to worry to setup new matching extra rules whenever I add a WAN port forward.

UPDATE: maybe my original port forwarding rule should be changed, the one that now explicitly specifies the WAN eth interface name. I got this setup from numerous tutorials and it works fine for external clients.

Answer 1

The usual answer to this question is "You need NAT loopback / NAT hairpinning".

As mentioned in a few answers, the actual problem with loopback NAT is that the source IP address of such "loopback port-forwarded" connections – the client's LAN address – is seen as a local address for the destination server (being in the same LAN), which causes replies to the client to be sent directly and not via the router.

So what the "hairpinning" workaround does is NAT the source address as well. It's not just a modification to your DNAT rule – it's a completely separate SNAT rule that needs to apply to the same packets. (Though, yes, you do need to relax the -i match from your DNAT rules as well.)

-A POSTROUTING -o enp3s0f0 -s 10.0.0.0/24 -j MASQUERADE
[or]
-A POSTROUTING -o enp3s0f0 -m conntrack --ctstate DNAT -j MASQUERADE

(If I remember correctly, iptables does not allow -i matching in POSTROUTING, although that would be useful here.)

The SNAT workaround would be unnecessary if your clients and servers were in different LAN subnets (e.g. different VLANs or just different Ethernet interfaces on the external router), as then traffic between them would always go through the router no matter what.

---

In more detail:

1. Client sends a request "client→WANip". The request goes towards the router's MAC.
2. Router DNATs it to become "client→server" and forwards it towards the server.
3. Server receives the "client→server" request, then sends a "server→client" reply back. This goes directly to the client's MAC, bypassing the router, so the DNAT is not undone.
4. Client receives a reply "server→client", which doesn't match any known connection – the client was expecting to receive "WANip→client" instead – so the client discards the received reply.

With the SNAT workaround:

1. Client sends a request "client→WANip". The request goes towards the router's MAC.
2. Router DNATs it to become "client→server", then additionally SNATs it to look like "router→server", then forwards it towards the server.
3. Server receives the "router→server" request and sends a "server→router" reply back. This goes to the router's MAC.
4. Router receives the "server→router" reply, un-SNATs it to become "server→client", and un-DNATs it to become "WANip→client", then forwards it to the client.
5. Client receives a reply "WANip→client" which matches the original request.