[ale] HELP, need to setup wireless access point!

[Michael B. Trausch]

On Fri, 2011-02-04 at 14:21 -0500, Ron Frazier wrote:
> I didn't intend any offense, so I hope none was taken.  The method I 
> proposed seemed like the quickest way to get Paul up and running in
> what appeared to be a home office situation.

None taken.

A bit annoyed, perhaps, but certainly not offended.  I have thicker skin
than that.  ;-)

There is no situation that I can think of where a double NAT is
appropriate.  It breaks many expectations in the design of a single
network, both at the human and at the application layers.  (Let's say
that the "human layer" is the missing 8th layer of the OSI model.)  Or
perhaps to state it better: I would consider it a design of last resort,
except for the fact that I cannot fathom a situation so awful as to
require one.

Using the built-in bridging of any device and extending the logical
Ethernet segment is always preferable to a double NAT, when it is
possible.  When it is not possible (e.g., if the logical Ethernet
segment would become too large to perform adequately or at all) then a
routed subnetwork would be the next best option.

Particularly if you do anything on your network like centralized network
backup or expect things like LogMeIn to work, double NAT is a huge
no-no.  Two tables holding state, possibly (most likely) with different
keepalive requirements and expiration timers, multiple notions of what
state is, state that could become completely invalidated if half the
network goes down but the other half survives... the possibilities for
failure are many and often confusing.

The first time I actually saw a double-NAT setup was probably my most
confusing.  And I came off looking like an idiot the first time I saw
it.  At first, I could not explain the problems on the network that I
was in charge of fixing.  They didn't make any sense.  It had never
occurred to me to actually check into whether or not there was a NAT
running on this network; it was a single physical network, in one
building, in a single administrative domain.  It took me hours to figure
out that the behavior was likely because of a NAT, and it only took me
hours to figure out because the thought never even entered my mind in
the first place.  I mean, who would put a NAT on the inside of a network
that is fully controlled by a single entity?

> A router with a WAN port acts as a one way valve.  Unsolicited data 
> cannot come back through the valve from the WAN to the LAN.

Common misconception, and completely incorrect.  NAT cannot prevent this
from happening at all.  What you're speaking of would be called a diode
in electronics, and insofar as I am aware, there is nothing at OSI layer
2 or above that acts as such a one-way valve or diode would.  At the
physical layer, that's easy: but then replies are completely impossible.

There are several types of NAT, but none of them can ensure the security
of devices on the inside of the network.  Connectionless protocols like
UDP are the most visible example.  Because there is no state associated
with a datagram, a NAT (and indeed, most firewalls [which are actually
security devices]) has to guess.  Sometimes, that means holding open the
WAN side of the mapping for several minutes and allowing anything on the
outside to send things back through that mapping.  Sometimes it means
that only one host on the WAN can send things back (though that, too,
breaks things if more than one is necessary, if the table only holds one
entry for a given (ip, port) pairing).

Just because it can be made to work does not mean that it's a good idea.
It's brutal and kludgey, and there is literally no reason for it.
Instead, configure routers that are separating subnetworks into proper
subnetworks: it's a simpler design and nothing will break as a result of
it, because routers are dead-stupid-dumb devices.  They move packets,
that's it.  They don't need to rewrite them or put them in tables or any
of that crap.

	--- Mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://mail.ale.org/pipermail/ale/attachments/20110204/09e0aa60/attachment.bin