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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
