Re: Hairpin NAT - possible without packet marking?

[zrm <zrm@trustiosity.com>]

The hairpin issue is unrelated to the original one so I'll change the 
subject line to separate it.

On 07/01/2017 07:50 PM, Robert White wrote:
 > On 07/01/2017 10:17 PM, zrm wrote:
 >> On 07/01/2017 04:26 PM, Robert White wrote:
 >>> So, for instance, once you DNAT the incoming packet you _don't_ want to
 >>> SNAT it.
 >>
 >> What about hairpin NAT?
 >
 > As stated, you really want to do local services by adjusting the DNS
 > unless it's impossible.
 >
 > Sure, you can do hairpin NAT, but it's usually just a bad design since
 > it doubles the network traffic on the one interface.
 >

In my case I have a Port Control Protocol daemon so I'm stuck with it. 
The client software will often fail for internal peers without hairpin 
and is written by numerous independent third parties.

 > If you want to put the service at a common public IP address and leave
 > it that way, putting your server on a dogleg/spur is already a much
 > better idea anyway.
 >
 > Why?
 >
 > (...reasons...)
 >

Unfortunately that doesn't get me out of it. My daemon has no control 
over the physical topology of the user's network, and the internal hosts 
increasingly _are_ the public-facing hosts. People want to map ports for 
games, VoIP, IPFS, etc.

If you had to put anything that wanted to map any port into the DMZ then 
most everything would be in the DMZ. :)

I feel like isolating public services has always been backwards anyway. 
An internal network with hard shell with soft middle means that one 
compromised internal device becomes a big fire.

And the modern trend has been for devices to offer public services even 
without mapped ports, by making outgoing connections to a server that 
forwards back incoming messages. Everything from Facebook and YouTube to 
VPNs and Tor is doing this now. It's no different fundamentally from 
mapping a port except that now everything appears to the router as 
outgoing TLS or ssh rather than separate ports for different services 
that could previously have been used to decide whether to pass traffic 
or not. So you have to assume everything has public services.

The only answer now is for the endpoint devices to secure themselves 
even against other internal hosts, because only they know what the 
traffic really is. (One could argue it should have been that way the 
whole time.)

The place for externally-imposed network isolation is the naive legacy 
systems that don't do that properly so they have to be protected from 
potentially compromised internal hosts that have no business with them.

 > If you do hairpin, you still don't need to mark any packets or anything.
 > You just use the SNAT/MASQUERADE rule with highly restricted matches
 > just for the hairpin server.
 >
 > An example culled from the internet:
 >
 > -A PREROUTING -d 89.179.245.232/32 -p tcp -m multiport --dports
 > 22,25,80,443 -j DNAT --to-destination 192.168.2.10
 > -A POSTROUTING -s 192.168.2.0/24 -o ppp0 -j MASQUERADE
 > -A POSTROUTING -s 192.168.2.0/24 -d 192.168.2.10/32 -p tcp -m multiport
 > --dports 22,25,80,443 -j MASQUERADE

That requires knowing which address ranges are internal or not, which I 
don't.

What I have currently is something like this:

-A PREROUTING -p udp -d 2.2.2.2 --dport 3456 ! --in-interface external0 
-j MARK --or-mark ${HAIRPIN_MARK}
-A PREROUTING -p udp -d 2.2.2.2 --dport 3456 -j DNAT --to-destination 
10.2.2.2:3456
-A POSTROUTING -m mark --mark ${HAIRPIN_MARK}/${HAIRPIN_MARK} -j SNAT 
--to-source 2.2.2.2

This seems to do the job, but I would prefer not to use marking in a 
daemon like this because it's too easy for the administrator to not 
expect it and then use the same mark for something else.

What would be perfect is to have a rule in POSTROUTING with "! 
-in-interface external0" but --in-interface is not allowed in POSTROUTING.

So the question remains is whether it's possible to get the same effect 
without marking.