[NTLUG:Discuss] Re: NAT question

Bryan J. Smith b.j.smith at ieee.org
Fri Sep 17 00:21:26 CDT 2004


On Fri, 2004-09-17 at 00:28, Terry wrote:
> I've seen mention of the fact that it's not good to have more than one
> NAT device on a network.  Is that so?  And if so, why?

Depends on what you are using NAT for.

It's really not a NAT-specific issue, but the larger issue of layer 2
(e.g., Ethernet) v. layer 3 (e.g., IP) address resolution.

If two nodes are on the same layer 2 network, they talk directly.  This
means an ARP resolution occurs, which translates the layer 3 address
(e.g., IP) to a layer 2 address (e.g., MAC).  Once an ARP entry is made,
then the nodes no longer do any IP resolution until the ARP cache entry
expires.

As long as their is only 1 ARP entry per 1 IP, then it is efficient.

The problem is when people subnet privately.  If they subnet privately,
then they should establish internal routes using a routing protocol. 
The routing protocol ensures all nodes have up-to-date routing tables,
which tell them which router to talk to.  Only the ARP entry for the
router is needed, and the node forgets about it.  The node _knows_ that
the other computer is not on the same layer 2 network.

In the old days before 1-to-many NAT (also and more accurately known as
NAT+PAT, port address translation), many lazy people just used routers
and "default routes (gateways)" instead of establishing proper internal
routing tables and distribution via routing protocols.  The problem with
that is that anytime a packet comes from another subnet, and the nodes
don't have a routing table that knows about the other subnet, then an
ARP entry is made.  Pretty soon, a huge ARP table exists with different
IPs, all pointing to the same hardware address.

Nowdays, using 1-to-many NAT internally, the ARP caches may not be the
issue anymore, but the inefficiency with the NAT device itself is very
high.  The devices outside the NAT think a local device on the same
layer 2 network is talking directly to it, namely the 1-to-many NAT
device, and not the actual nodes behind it, on a different subnet.  You
can have issues of every type from congestion control to phantom
sessions (even with stateful packet inspection).  It is still far more
efficient to setup internal routing proper -- instead of overloading a
NAT device with unnecessary translation.

Understand that 1-to-many NAT is _not_ firewalling -- especially since
the PAT portion is "not so random" as people think (meaning if you
understand how the NAT+PAT device works, you can gain access through
it).  You can and should still use packet inspection (real IP
firewalling) for internal firewalling when necessary (as always to
protect more critical systems).  You can do it in-line (transparent at
layer 2), or between the subnets (at layer 3).  But you _should_ still
be distributing internal routes with routing protocols (as well as keep
your packet inspection separate from the router -- unless you have a
modular switching fabric/system), so all nodes have routing tables. 

1-to-many NAT devices are _not_ routers in the traditional sense -- most
do not support distribution of routing protocols.  They are great for
private-to-public 1-to-many translation at slower speeds, but horrendous
for full line-speed, internal layer 2/3 traffic.

You can typically get away with multiple NAT devices on a small setup. 
But they can introduce unforseen issues on larger networks, just like
extra switches can.  There are so many inherent protocols and
negotiations of Ethernet, IP, etc... that most people don't know about
because they are largely transparent.  But they are there, and they can
turn into "storms" if you blindly attach devices without considering
them.

> Is it just that each NAT device or system just adds more overhead or
> slows the network down, and it slows the network down twice as much if
> you have two?  Or three times as much if you have 3, etc.   Or... ?

It's not about "slowing down."  It's about proper layer 2/3 resolution
internally.  When two systems talk, if they are considered on the same
layer 2 (e.g., Ethernet) network, they will talk directly to each
other.  This occurs with an ARP resolution.  If they are not considered
on the same layer 2 network, but on a different layer 3 (e.g., another
IP subnet), then only the router has an ARP entry.  The routing table of
the node says a node is not on the local subnet, so it has no ARP entry.

1-to-many NAT is an extremely poor substitute for internal routing
protocols -- and the issues scale linearly with the size of the network.

In a nutshell, routing tables and summary routes are how you maintain a
network of multiple subnets -- and not by using 1-to-many NAT devices. 
Packet inspection (firewalling) is separate from this consideration.

> One more question.  Should a firewall be rebooted regularly?  Say once
> a month or once a week or... not at all? Or what?

The decision to reboot a firewall is no different than any other
system.  If you believe the platform+software has memory leaks, then
weekly rebooting is probably recommended.

Otherwise, updating is far more of a consideration.

-- Bryan J. Smith, CCDP (not that it means anything)

P.S.  Do not confuse 1-to-many NAT (NAT+PAT) with 1-to-1 NAT (no PAT). 
1-to-1 NAT _is_ very useful for internal, private networks.  With 1-to-1
NAT, you _still_ use routing entries, as nodes see each other directly
-- even if the addresses are translated.  As such, summary routes and
routing tables are used all the same.  Remote, NAT'ed systems still
appear as a remote IP on a remote subset, which is just not the actual
IP on the remote subnet.  I typically have used 1-to-1 NAT when I've
needed to tie private systems from different companies together.  1-to-1
NAT is used at the boundary, so the other company only sees select
subnets/systems, in a subnet design of their choosing (and vice-versa). 
Packet inspection is completely separate (as it should be).


-- 
Bryan J. Smith                                  b.j.smith at ieee.org 
------------------------------------------------------------------  
"Communities don't have rights. Only individuals in the community
 have rights. ... That idea of community rights is firmly rooted
 in the 'Communist Manifesto.'" -- Michael Badnarik





More information about the Discuss mailing list