Two VLANs, One Subnet

Michael Torrie torriem at chem.byu.edu
Sat Mar 10 11:28:00 MST 2007


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.
> */
> 




More information about the PLUG mailing list