While there has been some good discussion in this thread, it has sometimes
suffered by differing usage of terms.
I distinguish 3 types of NAT (Cisco, for one, supports all of these):
1. Static NAT
Each internal address is mapped in a fixed configuration to its own
external address. This appears to be what mouss is referring to. However
it is only rarely used - usually just for servers. Any inbound packet
destined for external address Xn is mapped to internal address In and
forwarded, regardless of the ports and source address. This could be
implemented in a completely stateless NAT box.
2. Dynamic NAT
Internal machines are unreachable until they attempt an external
"connection". When they do, they are temporarily assigned an external
address. As long as they keep sending to the outside, within some timeout
specification, they own that address. Inbound packets destined to it will
go to the internal machine; while this also could be stateless, but I
suspect most NAT boxes require that "connections" be initiated by the
inside machine before allowing the inbound traffic. This is not very
commonly used either.
3. PAT (port address translation)
Internal machines are unreachable until they attempt an external
"connection". When they do, they are temporarily assigned a port on an
external address (for tcp and udp). Only inbound packets with a source
specification matching the destination of the original outbound traffic
will be mapped and forwarded to the internal machine. This must be
stateful. This method is by far the most commonly used. It does pretty
thoroughly block inbound connections. This is what most of the folks,
other than mouss, seem to be talking about in this thread.
(I use the term "connection" in quotes, because while we really only have
connections for tcp, the NAT box will typically simulate connections for
other protocols such as udp and icmp echo.)
And there are certainly other types of NAT in use which are some
combination of those listed above. A typical example is where all inbound
traffic to port 25 is statically mapped to a single internal address. This
acts like static NAT for that particular port (while all the other traffic
may be using PAT).
It would be helpful if those discussing NAT make clear what type of
translation they are intending. It usually makes a substantial difference.
Tony Rall
mouss <[EMAIL PROTECTED]>@Lists.GNAC.NET on 2001-02-26 06:54:23
Sent by: [EMAIL PROTECTED]
To: Ben Nagy <[EMAIL PROTECTED]>, "Firewalls Mailing List
\(E-mail\)" <[EMAIL PROTECTED]>
cc:
Subject: RE: To NAT or not to NAT?
At 09:33 26/02/01 +1030, Ben Nagy wrote:
>Any NAT implementation that is not brain dead should block any packets
that
>are not addressed to a valid NAT translation (IP addr AND port, unless
it's
>a static or 'weird' translation).
I have to disagree here. I use NAT to translate addresses and a packet
filter to filter
packets. I don't want my NAT to take filtering decisions, cos' I have a
better thing to
do it: a packet filter. That's the "do your job well, but don't do anything
else"
principle. When everyone keeps his cows, everyone gets milk:)
There is absolutely no reason that NAT should block any packet. I might as
well
like the packet to get passed, either to allow it or to pass it an IDS.
>You should also be able to configure NAT to _not_ translate stuff, based
on
>ACLs of some kind,
All the NATs I've seen have rule of the form:
if dest is xxxx, then convert to yyyy
I've not yet seen rule of the form:
if source is aaaa and dest is bbbb, then convert dest to yyyyy
NAT maps objects (addresses) while ACLs are oriented toward a
"condition => decision" way. The latter may include NAT but not the
converse.
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
