[Techtalk] Good firewall configuration tool for debian

[Travis Casey]

On Friday 09 April 2004 13:38, Devdas Bhagat wrote:
> On 09/04/04 10:18 -0700, Carla Schroder wrote:
> > On Thursday 08 April 2004 5:55 pm, Kathryn Andersen wrote:

> > > If/When I move to ADSL... I notice in the listings of ADSL modems,
> > > one could get a plain modem, or one could get a router which has all
> > > sorts of built in stuff including NAT and a firewall.  Is it better
> > > to just set up all that stuff on one's own box, or to use a router?
> > >  All I know about NAT is that some people think it's evil...
> >
> > NAT is lovely, not evil. You have only one exposed public IP address,
> > the
>
> NAT is evil. It breaks the peer to peer nature of the Internet.

This is techtalk, so let's get technical.  NAT and PAT are two different 
things, though often confused.

NAT translates network *addresses*, but leaves *ports* alone.  In order to 
do this properly, each internal address needs to be assigned a unique 
external address (at least for the duration that it's being used).

PAT, in contrast, changes (or at least, can change) the *ports* that 
connections appear to be coming from, in order to allow one external 
address to be used for multiple internal addresses.

We can sub-distinguish between two kinds of NAT:

static NAT:  internal address A is mapped to external address B.

dynamic NAT:  internal address A is mapped to one of a set of possible
  external addresses, B_1 - B_N.


Static NAT only breaks applications where (a) the protocol requires one or 
both sides to know their own addresses and send them and (b) the 
application designers did not supply a way to tell the application that you 
want to "advertise" a different address than the one the application 
automatically learns.  (In my experience, Microsoft seems to like to do 
this...)

(IMHO, such protocols are broken; why require clients to supply their own 
addresses, when the address of the "other end" of the connection is easily 
learned through standard calls?)

Dynamic NAT prevents running an accessible service, unless you use certain 
workarounds.  (E.g., the trick that "GoToMyPC" uses of having the "server" 
actually periodically contact a master server somewhere on the Internet to 
ask "has anyone requested to make contact with me?")  It also suffers the 
same problem as static NAT with certain protocols and applications.

Note that dynamic NAT can work just fine with protocols where a server is 
contacted, then makes one more more connections to the client -- the client 
listens on the ports necessary, and connections to those ports on the 
exposed address can be forwarded on to the same port on the client.  I'm 
presuming that this is all or part of what you mean by the "peer-to-peer 
nature of the Internet".

Static NAT can be used for a server, since A and B are permanently mapped to 
each other; any incoming connection to B is simply forwarded to the same 
port on A.

Since static NAT uses a 1-to-1 mapping of addresses, it doesn't save one any 
addresses.  Dynamic NAT uses a pool, the size of which can be varied 
depending on how many of your users you expect to be simultaneously using 
the Internet.

For example, where I work, we use a combination of static and dynamic NAT.  
We're a state agency, spread all over our state.  Some portions of our 
internal network use RFC1918 addresses... but in some cases, we want 
devices on those to run Internet-accessible services.  In those cases, we 
use static NAT.

We have some 4000+ employees, pretty much all of whom have one or more 
computers with network connections.  However, it's unlikely that all 4000 
of them will want to connect to the Internet at the same time... so we use 
a dynamic NAT scheme with a pool of about 1000 addresses.  Running 
Internet-accessible services on those machines is not an issue, since our 
security policy forbids it anyways.

Now, PAT, on the other hand, takes one external address and shares it 
amongst multiple internal addresses.  It does this by translating the port 
used for a connection.  This, however, prevents incoming connections 
entirely.  This breaks many protocols, and so is less desirable than NAT.

PAT can be partially fixed by making an "intelligent" device which knows 
something about protocols and can "listen in" on traffic going back and 
forth to learn what ports a system on the other end is going to contact 
back on.  This, however, requires updates to let the system know about new 
protocols.

(Note that it is possible to work around this by using a non-transparent 
proxy, where there can be a proxy protocol which internal devices can use 
to tell the proxy "I need to give the other guy an address and port to 
contact me on.  What should I use?"  This, however, would require altering 
either applications or OS networking code to understand such a protocol.)

PAT is the most limited of the three.  Some devices which do true NAT allow 
PAT as a fallback -- on our network, if by some chance the NAT pool becomes 
exhausted, PAT is used as a fallback.  Someone who's unlucky enough to be 
assigned PAT instead of NAT won't be able to do certain things, of course, 
but being able to do *some* things is better than being able to do 
*nothing*, we reason.

> > so you see, there are many options, and NAT is not evil.  :)
>
> Until your ISP decides that consumer grade DSL customers should not run
> services and to enforce that by giving you a RFC 1918 IP.

There is a difference between "X is evil" and "X can be used for evil 
purposes."  NAT is not evil in and of itself; it's simply a tool.  

--
       |\      _,,,---,,_     Travis S. Casey  <efindel at earthlink.net>
 ZZzz  /,`.-'`'    -.  ;-;;,_   No one agrees with me.  Not even me.
      |,4-  ) )-,_..;\ (  `'-' 
     '---''(_/--'  `-'\_)