Ricky Beam wrote:
On Sat, 07 Feb 2009 14:31:57 -0500, Stephen Sprunk <step...@sprunk.org>
wrote:
Non-NAT firewalls do have some appeal, because they don't need to mangle
the packets, just passively observe them and open pinholes when
appropriate.
This is exactly the same with NAT and non-NAT -- making any anti-NAT
arguments null.
Actually, it's worlds different.
In the case of a stateful firewalling ("non-NAT"), the "helper" has to
understand the protocol to know what traffic to allow.
This is not completely true. Technologies such as uPNP can quickly open
up a pinhole for traffic which needs to be initiated from the far end,
but no address rewriting is necessary by the software (embedded in the
protocol) or the firewall. For non-UDP/TCP packets, ports have no
meaning, which is the biggest failing of NAT (since we are talking about
overloading on one IP here, and not 1 to 1 translations). Firewall rules
for packets that are not UDP/TCP usually allow the return traffic based
on source and destination IP and IP protocol number. NAT, on the other
hand can't do it. We have to make udp/tcp tunnels to carry the traffic
through NAT instead.
Subtle difference, but in the end, the same thing... if your gateway
doesn't know what you are doing, odds are it will interfere with it. In
all cases, end-to-end transparency doesn't exist. (as has been the case
for well over a decade.)
End-to-end addressing does exist, though. There are cases that are
straight forward that NAT breaks without adding extra tunneling layers,
or without either NAT or the software having to rewrite an embedded IP
address in a packet to the public address. Sure, stateful firewalls can
still block traffic and break certain scenarios without the assistance
of uPNP(or application layer analysis). They will be simpler, and break
less (we'd hope simpler means less). It's one thing to communicate with
your firewall to dynamically open up ports for your address. It's
another to start rewriting packets, analyzing specific protocols so that
you can alter them.
Feel free to disagree with me on all except non-TCP/UDP breakage. I've
had too many support calls on that one, and NAT-T isn't always
available, and even when available, it's not necessarily configurable.
Jack
