On Fri, 2007-03-09 at 23:57 -0700, Corey Edwards wrote: > On Thu, 2007-03-08 at 23:32 -0700, Michael Torrie wrote: > > On Thu, 2007-03-08 at 22:06 -0700, Hans Fugal wrote: > > > Absolutely not. NAT is out of the question. NAT always causes more > > > problems than it solves, even in enterprise. In enterprise, you have > > > full-time sysadmins to go around chasing NAT issues and keeping a > > > semblance of normalcy. I know, I used to be one. I will set my network > > > up and just let it run. I will not be a slave to NAT. > > > > I disagree. Static one-to-one NAT (think of it as a layer 3 bridge) is > > clean and effective. You do just set it up once and let it run. No > > one's a slave to anything. Once you introduce dynamic NATing, then, > > yes, you will likely have problems. I have never had to chase down NAT > > problems. It just works. What problems have you observed? > > Yes, NAT is definitely better than PAT but I'm still not sold. I'd be > interested in your opinion of why that's any better than using normal IP > addresses with a good set of firewall policies. The only decent one I > can think of is saving IP addresses, but I like to ignore that one in > the vain hope that someday IP addresses will be as doled out in large > quantities.
Tis a vain hope, yes. :) But this issue has nothing to do with saving IP addresses. Typically it's about establishing a DMZ. I get the impression (likely wrongly) you're thinking about NAT in terms of masquerading, when you say "save IP addresses." NAT is logical if you look at what's going on here (in simplified fashion). We have the internet, the router, the private hosts, and the hosts on private side that want to be "on the internet." I think Hans mentioned he'd created a vlan for them, for our purposes is a virtual switch across certain ports. In any case, in order for traffic to get from the internet to the hosts, it has to flow through the router. If you apply NAT during the prerouting phase, the you can take advantage of the routers existing routing rules, which are based on its vlans. Nothing special like proxyarp needs to be used to get the packets to the servers. Additionally firewall rules are then easily applied across the "FORWARD" chain, locking down the vlan. Another advantage is that it is very easy to apply firewalling rules to the DMZ governing traffic flowing from the the DMZ into your private vlan). Also DMZ hosts need not worry about routing themselves. The default route can always be just the router's private address. With Hans' setup, the DMZ hosts default route should be the router's public address, but then they have to have an additional route to reach the private hosts. This is setup automatically by the OS, but it still increases the routing complexities. It's simpler to secure too because in Hans case, since the servers have both a private and public address, you'd have to apply rules to both it's public and private addresses (two sets of default rules, in other words). Basically what caused me to suggest NAT was when Hans mentioned that he wanted his servers to have both private and public addresses. NAT allows this to be achieved in effect, without having to muck about with proxy arps and multi-vlan things. All of this can be achieved, as Hans has shown, without NAT. But in my opinion, it's simpler, less error prone, and easier to secure with NAT. As Hans has said, he's had a few initial routing problems, and still has weird issues like MAC "leaks". Anytime you deal with DMZs in commercial products, such as Cisco's firewalls or any other commercial firewall product, you'll find that translation rule sets are considered the best way to do it. Every firewall we've ever employed (just 3 so far :) with DMZ functionality implemented it this way. Of course that's not evidence of it being better. Michael > > Corey > > > > /* > PLUG: http://plug.org, #utah on irc.freenode.net > Unsubscribe: http://plug.org/mailman/options/plug > Don't fear the penguin. > */ > /* PLUG: http://plug.org, #utah on irc.freenode.net Unsubscribe: http://plug.org/mailman/options/plug Don't fear the penguin. */
