On 06/30/07 01:03 pm, Sam Lewis thus wrote :

Lewis,
According to the presentation you linked "NAT is evil"  Why is that?  Why would designers hate it?
Thanks,
Sam

I guess that statement refers to the various issues with NAT and traversal of point-to-point services (NAT-T, such as for VPN tunnels). NAT can be a bear to deal with in this regard, mainly due to implementations where RFC3235 has been ignored or taken too lightly (see http://www.isi.edu/in-notes/rfc3235.txt). NAPT (the most workable form of NAT) is not used nearly enough in small gateway devices (or even in some of the larger boxes), leading to port translation issues (i.e., the far end cannot remap an incoming port when the necessary port is already in use by something else - and other such fun).

Sometimes, it's a matter of just trial and error to find the right mix of what works on each end (NAT, PAT, NAPT, MASQ). In the new Astaro v7 gateway devices (and  Astaro Security Linux), I'm now able to avoid much of this by using generic proxies which are inherently more  secure than NAT by allowing the gateway to handle the transaction between outside and inside instead of merely transposing the addresses and/or ports and letting the traffic pass.

I spent much time last week getting two IPSec VPNs to work with a couple older Zyxel 600-series DSL boxes, which insisted upon infusing their NATed inside interface addresses in the ID string of the IPSec packets. I finally worked around the problem by specifying that private IP as the VPN ID on the far end, thus "fooling" OpenVPN into believing that it was getting a legitimate ID (using a private address as a VPN ID is akin to using a skeleton key which fits a hundred doors; how many private networks are 192.168.1.1?).

NAT is just a mixed  bag. It's  great for some things and really tough for others. When you need to share a single public IP between five or ten machines, it's he only game in town and makes a lot of sense. OTOH, when you need to also allow access to four servers behind the NAT, then it becomes a sticky situation, better served with multiple public IPs.

Does that make a bit more sense, now, Sam? :-)