Re: Full NAT forward and source routing - possible without packet marking?

[Robert White <rwhite@pobox.com>]

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.

So I understand that there are some odd corner cases that you just
cannot fix, such as lying to a black-box appliance, but it's a technique
that you _can_ do, but that you have virtually no _good_ reason to ever do.


IF you must you want to restrict the hell out of the SNAT so that it
only applies to packets that are making that hairpin turn, rather than
masquerading/snat all the traffic.

So really, if you are in control of the router and the DNS, or you
intercept the DNS requests with a REDIRECT rule at the router, you can
inject the correct local address anyway and you don't need to hairpin.

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?

Because if you have a public service (say a web browser) you don't
_want_ it on your local segment. One of the goals (that people often
forget) of a firewall is to protect yourself, so if the server is in the
free local segment then a compromise of the server is effectively a
compromise of the router.

If the server(s) are on a dogleg then compromising the server can only
give the attacker access to the other servers on the dogleg (if you did
your rules right). A server that the public can touch by any means
should be isolated from the rest of your private network.

For instance, a public-facing web server should never be allowed to make
outgoing connections to the rest of your infrastructure. The dogleg
rules should, for example, block every form of egress from that server
to your real properties or the internet in general.

By example, the typical web server exploit causes the web server to make
an ssh or telnet connection, or an outbound web request so that the
escalated privilege can be used for some purpose. It might also involve
putting a web snoop of some sort into the server to watch the incidental
traffic for passwords and such.

So an actually secure setup would, for example, prevent the web server
box from initiating questionable traffic, and would isolate your local
SMB type traffic from the wire entirely.

So if you have to haripin for some reason, then you should dogleg
instead. Period. It's a half-arsed solution to an inherently bad design.

A commodity home router doesn't usually offer the necessary hardware to
dogleg, but commodity home routers are not designed for Real Services
Safety™. Anything you can put a network card in can be built to never
need to hairpin anything.

So hairpin routing is a bad idea that is popular for bad reasons.

The rendezvous server example is fixed by a dogleg, but it's also fixed
by having both addresses listed for the server and just NAKing (via
REJECT) the public address if its received on the private interface,
causing the secondary address to be used. Of course, because of your
smart routing the local address should have been chosen for its lower
metric to start with, but that's another topic.

HOWEVER

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

Notice how the last rule range matches the source, but exactly matches
the hairpin target both by exact address and specific ports. Normal
non-hairpin traffic simply doesn't get SNAT at all.

And still, and again, the connection tracking does all the necessary
heavy lifting work with no particularly complex nonsense.

It's ugly and insecure, IMHO of course, to leave that server on your
general use network like that for the reasons already stated. Spending
forty bucks on an extra network card would be _much_ safer and more
efficient.