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

[Michael B. Trausch]

On Fri, 2011-02-04 at 17:31 -0500, Ron Frazier wrote:
> I am not a networking guru, but here are some thoughts.  See comments
> in line.
>   
> I was never really advocating double NAT, even though I have 3 NAT
> routers in my network.  What I was advocating is a simple PC -->
> router --> modem sequence for a home office.  The router is really the
> only NAT device in the chain, as the modem will give you a publicly
> accessible IP.

The Internet access medium is technically the Ethernet (or USB) coming
out of your modem.  Even if the ISP bought you a direct Ethernet drop
from the street or local node or what-have-you, you wouldn't consider
the hardware on their end as part of your "drop", so in all fairness the
modem does not count, either.  Only the interface that the modem exposes
to your network counts.

For example, in the case of a cable modem, it has its own (private) IP
on the ISP's network.  Once it is up and running and has downloaded its
configuration, you are able to run traffic over it; you send and receive
Ethernet frames over it.  The modem acts like an Ethernet bridge, with
the added twist of translating the signal from layer 1 Ethernet into
DOCSIS layer 1 signaling, whatever that is.  The layer 2 Ethernet
frames, however, remain intact, AIUI.

A NAT is a NAT.  Sadly, it seems that most people truly do think that it
is synonymous with "router".  A true router performs a different,
simpler job: it does nothing more than route packets.  A NAT, however,
is pretty invasive (and involves a lot more work).  Allow me to go into
detail on how a NAT works.

Suppose you have the Ethernet coming from the ISP, and suppose that
Ethernet is plugged into the upstream/uplink/WAN port on a consumer
grade NAT appliance.  Suppose also that you have a single computer, and
that computer is attached to port 1 of the consumer grade NAT appliance.
Let's say that the following are all true, then:

 * Your NAT appliance obtains the IP 203.0.113.171 from the ISP (e.g.,
   the WAN side of the appliance).

 * Your NAT appliance uses 10.99.99.1 as its IP address on the LAN
   side.

 * Your home network is configured to use 10.99.99.0/24 as its network.

 * Your computer obtains, via DHCP from the NAT appliance, the IP
   address 10.99.99.100.

Now, you want to connect to Google so that you can do an Internet
search.  Assuming a normal, non-NAT'd connection, this is what would
happen.

 * Your browser must turn www.google.com into IP addresses.
   - Your browser checks its DNS cache (if it maintains one) to see
     if it knows what the IP address(es) are for www.google.com.  If
     found, it will return the IP address(es) found in the cache.
   - Your browser asks the operating system to turn www.google.com
     into one or more IP addresses.
   - Your operating system looks in its DNS cache (if it maintains
     one) to see if it can answer; if so, it returns the IP addresses
     (if they are not stale).
   - Your operating system will look to its DNS resolver configuration,
     and ask one of the nameservers to do this.  When it receives the
     answer, it will return it.

 * Your browser must connect to www.google.com.
   - Your browser asks the operating system to connect to one of the
     IP addresses for www.google.com on port 80.
   - The operating system prepares a packet and sends it out to the
     destination IP address, which is the address for www.google.com.
     (Note that routing is completely transparent and provides an
     essentially direct connection between one system and another.)
   - The reply comes back. A TCP handshake takes place.
   - When established, the HTTP request can be issued, and the reply
     will be sent.

 * Your browser will close the connection to www.google.com.

Now, the part where the browser connects to www.google.com requires only
a single connection.  If there is no NAT, there are no points at which
the connection is severed.  Let's now focus on the connection to
www.google.com through a NAT:

  1. Your computer sends a connection request packet to
     IP_www.google.com on port 80.

  2. Your computer's default gateway is your NAT appliance, so it
     sends the packet to the NAT appliance to be routed.

  3. The NAT appliance receives the packet, and puts it in memory.

  4. The NAT appliance looks at the packet's source IP and port
     numbers.  It then looks in its table to see if it has a record
     for them.  If not, it adds one.

  5. The NAT appliance looks at the packet's destination IP and port
     numbers, and fills in the table entry looked up above with that
     information.

  6. The NAT allocates an (ip, port) pair for the packet to use as
     a return path, and records those numbers in the table above.  If
     the NAT has only one external IP address, it will always use the
     same IP, but a different port, in this step.

  7. The NAT now rewrites the packet: source IP/port become the newly
     allocated (ip, port) pairing from step 6.

  8. The NAT sends the packet down to the Ethernet interface and out
     to its default gateway, to commence with normal routing.

The steps are logically inverted when the reply packet comes along.  The
whole thing here is that the system on the inside of the network doesn't
really see what's going on here.  It sees packets where it is the
destination and the packets are coming from www.google.com, right?  But
they're really not.

NAT stands for Network Address Translation.  That involves a significant
amount of rewriting and forging to pull off correctly.  Every packet
must be re-written!  (If they are cryptographically signed in any way,
they will also fail validation simply as a result of passing through a
NAT, if the NAT signs the source and destination IP headers.)

The consequences of all of this, though, mean that it is much harder for
normal applications to do their thing without having to perhaps rely on
some intermediary third party for a little bit of a helping hand (at the
cost of wasted/redundant bandwidth consumption as well as increased
latency and perhaps even implications on throughput).  For example, if
two people are behind two separate NAT devices, they will be unable to
directly SIP between the two of them without a lot of difficulty, if at
all.  They can, however, have a bidirectional stream of communication
between them if they use a third party that is willing to talk to the
both of them, which is not behind a NAT device.  This is because each
individual SIP user connects to the third party server.  Of course, this
results a far less than optimal result.  Latency is higher because there
are more hops along the way.  Additional latency comes from the
third-party intermediary server, which does not provide routing
services, but application layer services.

This is the problem that end-to-end connectivity solves.  And while the
Internet currently lacks that end-to-end connectivity because of NAT, it
will soon be restored, thankfully, which will vastly improve the
performance of the Internet as a whole, and certain types of
applications such as near-real-time audio and video streaming.
Furthermore, it makes it a lot easier to do things without having to
jump through ten thousand hoops just to get it done.  That reminds me, I
need to write a utility (that I would not have to write if NAT didn't
exist) so that I can actually support my family's computers.  They're
out of state, and there are a fair number of computers, and I am
_absolutely_ not paying for services like LogMeIn.  Not to mention, I
don't _trust_ such places.

> > 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.
> I sort of know what you're saying, but, I've used Crossloop, which is
> like LogMeIn, through the NAT's with no problem.  The program has to
> negotiate a connection with a central outside server first.  Then the
> two PC's are bound together to talk directly to each other, as I
> understand it.

The way that such applications work is pretty simple:

 * The application's special client starts up on the desktop computer
   behind a NAT, and it establishes a connection to a third party
   server.

 * If the application is smart, it sends keepalive packets periodically
   so that any NAT along the way won't unexpectedly sever the TCP
   connection (e.g.: "connection reset by peer" type errors).  Such a
   requirement only applies if there is a NAT in the way (or, without
   a NAT, some type of stateful firewalling is used).

 * The application will usually report the IP address of the Ethernet
   interface it is using to the server.  The server will compare that
   with the IP address of the connection's origin, and will assume that
   NAT is in use if the two are different.

Now, you're out and about and you would like to view your desktop.
Well, that's awesome.  But now *you* need to talk to a third party
server, as well.

So, you go to the Web site, which hosts a Java, Flash, or Silverlight
applet (I don't think anyone is using WebSockets yet).  Or you use a
client application on your computer.  Either way.  Log in, and you can
see that your computer is there.  Yippie.  Click on it to open it up.

Now what happens is:

 * The application on the "client" side connects to the third party
   server.

 * Keepalives, yada yada.

 * IP address report, etc.

 * Computer you are wanting to connect to

So, now the third party server has a job to do.  It has to connect you
to your computer so that you can view and/or control its desktop, right?
Well, in order to do that, it takes your request and it matches it up
with the software running on your computer.  It sends a packet to your
desktop that you want to display, and if it replies, the third party
server will act as a relay between you and your computer.

Some third party servers (and client software) can negotiate in order to
create a direct connection between the two computers.  However, in order
to do this:

 * The right types of NAT need to be used on both sides.  Nested NATs
   can be a breaking point there if the type of the inner NAT differs
   from that of the outer NAT.  Every type of NAT behaves differently.

 * Certain software programs that don't use intermediary third party
   services rely on the ability to somehow control the NAT (mostly a
   thing for consumer/home type stuff), such as via uPnP.  Not a bad
   idea, except that it'll only work on the innermost NAT in a
   multiple-NAT setup.

 * Complex, bidirectional, multiple-channel protocols + NAT (such as
   SIP calling, but there are other examples) have massive issues with
   NATs because it's impossible to setup and teardown multiple channels
   between multiple hosts without pretty strange trickery or having
   that trusted third party relay.

>   Also, you should be able to access a centralized backup just like I
> do with my printer, by the IP address.  The NAT routers don't care. 

I'm not sure what the NAT routers are supposed to be caring about in
this case.  There are plenty of situations where the network owner might
care, though:

 * If the inner NAT is on the same IP subnetwork as the outer NAT,
   the systems on the outer NAT are inaccessible to the inner NAT,
   because they'll never be reached.

 * If a system on the outer NAT needs to talk to a system on the
   inner NAT, you first have to have the system on the inner side
   communicate with the one on the outer side, just like the
   Internet.  This makes pull backups impossible unless you do it
   at the deepest NAT level or use an inverted connection.

 * Transferring files between multiple levels of NAT for a home
   network is only easily possible in one direction; virtually
   impossible in the other.

Sounds awfully inconvenient, and it certainly can be.  And in fact, it
virtually always is.  Shared printers, file sharing systems, etc., all
need to be on the outermost NAT without special arrangements.

>  However, broadcast and ICMP packets may not make it across the NAT
> boundry.

ICMP packets most certainly ought to make it past the NAT (at least
going out).  Replies might be a bit screwed up, though, sure.

As far as broadcast goes, broadcasts do not leave the subnet anyway.

Perhaps you're thinking that NAT is somehow useful for subnetworking and
isolation?  If so, you're sorely mistaken.  It has side effects that can
cause additional isolation (after all, it's just voodoo done on IP
packets to make private systems without global IP addresses able to talk
to systems that do have global IP addresses).  That's what subnets are
for.

> > 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?
> >   
> Ahh ... now we know why you have a personal bias and grudge against
> NAT routers!  8-)

I believe that you are reading into something that doesn't exist.

I do not have a grudge against any inanimate object.  Honestly, what
kind of sense would that make?

I am, however, an advocate for doing things correctly---including
designing even simple networks, and including giving advice to others.
There are a million and one reasons why NAT is awful.  I'm not going to
spend the time to go into any more of them: you can find it all over the
Internet.  You can do experiments on your own network with and without
NAT.  You can benchmark and read source code just as well as anyone else
in the world can, and I think after this I'm done talking to anyone
about NAT.

> It is not the NAT function, per se, which provides the one way
> function.  It is the firewall function of the router's firmware.  And
> the key word is unsolicited data.

Uhm, no.  Well, sort of, but only by definition of being a NETWORK
ADDRESS TRANSLATOR.

You see, when a system on the inside of a NAT attempts to establish a
TCP connection, the NAT monitors the state of the connection (and
rewrites packets) because that is its job.  That includes the connection
open handshake as well as the connection close song and dance.

But the funny thing is that different network stacks (and different
applications, for that matter) can have different expectations.  Some
applications might establish a TCP connection that stays open as a
"virtual circuit" and it might only transfer data 3 or 4 times a _day_.
Such a connection would not work through a NAT, unless the NAT has a
very long timeout for TCP connections.

> According to the Wikipedia article on Stateful Firewall:

I am more than well aware of what a stateful firewall is, thank you.

Half the overhead of a NAT is precisely about stateful firewalling,
which, by the way, is not necessary on each and every one of the 65,535
available ports unless you have a NAT.  And it gets worse: the more
connections you have running through a NAT, the more packets you have
running through it, the more the CPU is going to spin.  While that _can_
happen at exceptionally high load for a normal router (the type that
runs the Internet, an actual, honest-to-goodness, IP router with no
added bells and whistles), it happens far more quickly with NAT.  And
even quicker still with relay servers (which honestly should never have
been necessary in the first place).

> So, to establish a TCP/IP connection, you have to have the SYN,
> SYN/ACK, ACK handshake between the relevant computers.

That is how you establish a *TCP* connection, yes.  That has, by the
way, absolutely nothing to do with IP.  Forget the fact that people say
"TCP/IP".  It's about way more than that; TCP runs on top of IP, just as
UDP runs on top of IP, whether IPv4 or IPv6.  And SCTP and others.  It
makes as much sense to say "TCP/IP" as it does to say that "GNU/Linux"
is the only way to run Linux, period (I seriously want to punch anyone
that makes the claim that Android is "GNU/Linux"---seriously---because
it is simply not true).

Yes, I am nit-picky about technical detail.  Absolutely.

>   Once this is done, the firewall should reject any queries coming
> from any other IP address.  The firewall may be vulnerable to a man in
> the middle attack using IP source address spoofing, but this would be
> rare.  Unless I'm mistaken, the firewall will also reject connections
> from the same remote source address if the port numbers are different
> from what was negotiated in the three way handshake.

For TCP, yes.

Not necessarily for UDP, because UDP is used for different things and it
is completely connectionless.

> This is the one way valve function I was talking about.  The firewall
> simply refuses to pass through unauthorized packets which are not part
> of the existing connection.

A _firewall_ requires explicit configuration to do that, and when
programmed by a person running a network and attempting to protect said
network, it's going to be a lot more strict than NAT is.  NAT's base
"firewall" is extremely permissive.  It _has_ to be.  One of the goals
of NAT was to try to break as few applications as possible.  They didn't
succeed very much there, IMHO, until much later when various NAT systems
got built-in ALGs.  Even then, those ALGs only hides some of the pain.
None of those are perfect, either.

> This should stop the overwhelming majority of erroneous or fraudulent
> TCP/IP packets.

Most types of fraudulent IP packets will be caught by the network stack,
all without the help of a firewall.  Yes, you can spoof the source IP
and port of a packet.  Yes, you can spoof the contents of packets.  But
we already knew that.  The Internet is a bloody hostile place.  That's
why we have IPsec, to prevent those things from happening.  Two
cooperating networks using IPsec will be able to securely talk to each
other (so long as there is no NAT in the middle).  That's also why we
use things like encryption, nonce values, and other forms of security
built around the applications themselves.  Though now that we're moving
to IPv6 and that has built-in security mechanisms, it's quite likely
that IPsec will become more useful than firewalling, since it's far more
secure.  You can 

I'd be much more concerned about someone getting into the services that
I have to have exposed to the Internet (and access-controlled) than I
would ever be about having to worry about hiding an entire network.  And
for that matter, the most likely type of incident to occur is some form
of break-in at layer 7, in a public service.  That's one (among many)
reasons why real security is required.

> Now, in terms of UDP, the Wikipedia article says this:
> 
> quote on -->
> Many stateful firewalls are able to track the state of flows in
> connectionless protocols, like UDP. Such sessions usually get the
> ESTABLISHED state immediately after the first packet is seen by the
> firewall. Sessions in connectionless protocols can only end by
> time-out.
> <-- end quote

This is only partially correct.  Connectionless protocols are, well,
connectionless.  There may be only a single packet required to get
something finished, or it might be used for something else altogether.
It's not possible to tell without also knowing about the details of the
packet.

For example, DNS uses UDP.  Your system will send out a query to a DNS
server using a UDP datagram.  The DNS server will reply to that datagram
using another UDP datagram, addressed to the same (ip, port) pair as the
origin.  In the case of DNS, that's all there is to it.  Anywhere from
one to five minutes later, depending on the stateful firewall's
implementation and any configuration, no more inbound UDP packets will
be allowed.

However, this can be the source of multiple problems.  UDP would be
ideal for many things if it weren't for the forced stateful "firewall"
that NAT provides.  UDP makes for an excellent protocol for ad-hoc
communications when you do not require the semantics of a full-fledged
TCP connection.  It also operates on the concept of packets, unlike TCP
which operates on the concept of bytestreams.  SCTP builds on both, but
I cannot imagine SCTP being useful at all behind a NAT of any sort,
since many of the features that it provides require true end-to-end
communication in order to work (and most stateful firewalls aren't going
to know the first thing about it anyway).

Furthermore, stateful firewalls can only be stateful about protocols
that they know about.  There are protocols other than TCP, UDP, and SCTP
that run directly on top of IP.  AH, which is a security mechanism, runs
directly on top of IP, and itself encapsulates an IP payload (which
might itself carry a part of a TCP stream, or a UDP datagram, or
something else altogether.  If your stateful firewall doesn't know about
that, it cannot do anything at all and just has to give up.

This is one reason why most consumer grade NAT appliances are so broken.
They are unable to deal with protocols that they weren't designed for,
such as protocol 41 (IPv6 encapsulation and tunneling).  That's because
they know nothing about the protocol itself, not its semantics or
requirements, whether it is something like TCP or UDP with a concept of
port numbers, or whatever.

> Now, I don't know as much about UDP.  I gather from this, that, if you
> send a UDP packet to microcoft.com, that the firewall will observe an
> established connection to there, and will allow a return packet from
> there, and only there, within a certain time limit.

Some NAT implementations will only make note of the mapping back to the
inside network.  Some NAT implementations will note the destination
host, but not the port.  And some other NAT implementations will note
the destination and the port.  What is allowed to come back depends.

This is, in fact, precisely why it is possible to connect some SIP calls
directly and others only with the help of a trusted third party relay.
If the UDP handling on the NAT is very permissive, such that anyone can
send a datagram in once a single one has gone out, then you can do
things like transfer SIP calls and have only the overhead of call setup;
nothing else would go through the third party server.

But some NAT systems do not allow that, and so sending out a UDP
datagram to the relay server won't allow the second party to communicate
with you directly at all, and the third party relay will have to stay
"in the loop".  As I've mentioned before, this has a negative impact on
efficiently of the application.

> I can see how this could be abused, since it has a timer waiting for
> the reply and leaving the door open.  However, barring a man in the
> middle, I think the reply would still have to come from Microsoft to
> get in the open door.  I think port numbers still come into play here,
> but I'm not totally sure how.  Then, if the packet were malformed,
> presumably the application layer would have to reject it.  But it
> WOULD have gotten through the firewall.  Nevertheless, you still have
> a one way valve effect rejecting almost all of the unwanted traffic
> coming from the Internet. 

"Unwanted traffic" is defined differently for every single useful
network in existence.  The thing is that most people don't notice
because of the great lengths that application software will sometimes go
through to try to hide all of the problems under the hood.  And then all
they complain about is the speed.  "I have a 10 Mbps connection to the
Internet, why is it that I can't do something simple like video chat
without problems?"  Well, it'd be far more likely to work if your
packets could be more flexible in the routes that they take, and not
have to be forced through some third party that you presumably trust.

For that matter, consider a common case for people like myself.  I don't
mind helping others.  And for most problems, I need not be physically
present to help, just to have access to their screen.  But even if the
person on the other end is running Ubuntu, I have to have them jump
through hoops just to get it so that I can make the initial connection
to the VNC server running on their system.  If NAT were not an issue,
then I would not have this problem at all.

Firewalls exist to prevent things from happening that should never, ever
happen.  A firewall should never screw with ephemeral ports, for
example, since those are available for use for outbound connections.  It
might be a good idea to have stateful tracking applied to ephemeral port
ranges, but it's not strictly speaking necessary---ephemeral ports are
used for a very short while only, and selected usually at random.  But,
stateful tracking on the ephemeral ports couldn't hurt any.

Well-known ports should probably be blocked by default, with a few
exceptions for things like SSH.  The "registered port" range is a
toss-up.  However, I'd probably expect to see most of it also blocked
with a whitelisting policy, and there are probably a few things there
(VNC included) that should be allowed by default.


> Even granting the validity of the points you've raised, which I do, I
> don't see the NECESSITY (not possibility) of using anything other than
> a simple daisy chain approach in a home office network.  Also, most
> home routers don't provide the level of configuration necessary for
> more complex network setups.

A simple daisy chain is fine.

Just don't introduce NAT every step of the way.  There's no point.
There is less than no point: it can and will break things in subtle ways
that will take time to figure out.

Simple daisy chains are why we have things like switches.  Though
routers aren't really all that complex, either.

I'll put it this way:  Network security is more about securing the
individual components of a network than it is about security at the
network's edge.  Relying on the security of the network's edge to get
you through the day is just asking for failure.  Lots of cases of data
theft, database breakins, and the like happen from NAT'd nets.  When
people rely on the network edge to keep them safe, they will get burned,
because they often think that means that they can be lax on the
interior.  Nothing could be farther from the truth.  And NAT in
particular buys you nothing.

Proper, real, effective security comes only from know-how and proper
setup.  If you have a network and you don't know how to keep it secure,
that's why we have people who get paid for that sort of thing.  If you
have a computer and you don't know how to use it, there are people you
can pay for that, too.  But don't say that something adds to the
security of something without truly understanding what it is that you're
saying.  Do the research.  More than just Wikipedia.  I haven't really
scrutinized the articles over there on the vast majority of networking
topics.  Most of the ones I have seen are "good enough", in that they
provide an adequate introduction and links to authoritative references.
But really, if you want to learn how this stuff works, I'd suggest
diving into the Linux kernel, or the FreeBSD kernel, or any operating
system kernel that has a full IP stack.  There is lots of
information---and subtle details---to be found there!

	--- 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/20110205/6b7e4117/attachment-0001.bin