Best Practices for Enterprise networks

Michel Py michel at arneill-py.sacramento.ca.us
Mon Aug 30 00:42:14 UTC 2004


>> Tracy Smith wrote:
>> Specifically, to NAT or not to NAT?

This is not much of an issue anymore. If you receive IP addresses from
your ISP, not natting would be foolish. Even if you do own your own
public IP space, the NAT issues are fundamentally no different than the
firewall ones and since not having a firewall is not an option, most
enterprises will indeed NAT some of their subnets in their firewalls,
whether or not they have or could easily obtain public space.

> At what point should NAT-ting be performed ... 
> exclusively at the Egress point

If there is only one egress point, indeed (typically at the firewall
that's between the outside router and the inside router).

If there are multiple egress points it's more interesting. There are
multiple designs.
 
> about firewalling - centralized/decentralized?

Greatly varies depending the design and requirements of a given
enterprise.


> Iljitsch van Beijnum wrote:
> Fortunately, I've never been in the position
> to make such decisions,

That's when you understand the real meaning of FUD: when you @55 and/or
your job are on the line ;-)
 
> but I can tell you one thing: if you have multiple connections
> to the internet, you had better make sure that your NATs and
> firewalls are equipped to handle the case where you send a
> packet out through connection A and the reply comes back
> through connection B.

Indeed.


> Paul Ferguson wrote:
> Asymmetric paths are a fact of life in the Internet.

Not for enterprise operators except the largest ones. Asymmetric traffic
does happen in the core, where there are no firewalls or NATs; as far as
the edge is concerned though I know several companies that multihome to
two or more ISPs but only in one location, largely because they don't
want to deal with NAT/firewall issues. Although it can work, it requires
extra engineering and most of the time a fat pipe to replicate state
information between the sites.

Michel.




More information about the NANOG mailing list