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

[Ron Frazier]

I am not a networking guru, but here are some thoughts.  See comments in 
line.

On 02/04/2011 03:49 PM, Michael B. Trausch wrote:
> 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.
>
>    
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.

> 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.  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.  However, broadcast and ICMP packets may not make it across 
the NAT boundry.
> 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-)
>> 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).
>
>    
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.  According to the Wikipedia article on 
Stateful Firewall:

quote on -->

The stateful firewall depends on the three-way handshake 
<http://en.wikipedia.org/wiki/Three_way_handshake#Connection_establishment> 
of the TCP protocol when the protocol being used is TCP; when the 
protocol is UDP, the stateful firewall does not depend on anything 
related to TCP. When a client initiates a new connection, it sends a 
packet with the SYN bit set in the packet 
<http://en.wikipedia.org/wiki/Packet_%28information_technology%29> 
header 
<http://en.wikipedia.org/wiki/Header_%28information_technology%29>. All 
packets with the SYN bit set are considered by the firewall as NEW 
connections. If the service which the client has requested is available 
on the server, the service will reply to the SYN packet with a packet in 
which both the SYN and the ACK bit are set. The client will then respond 
with a packet in which only the ACK bit is set, and the connection will 
enter the ESTABLISHED state. Such a firewall will pass all outgoing 
packets through but will only allow incoming packets if they are part of 
an ESTABLISHED connection, ensuring that hackers 
<http://en.wikipedia.org/wiki/Black_hat> cannot start unsolicited 
connections with the protected machine.

<--  end quote

So, to establish a TCP/IP connection, you have to have the SYN, SYN/ACK, 
ACK handshake between the relevant computers.  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.  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.  This should stop 
the overwhelming majority of erroneous or fraudulent TCP/IP packets.

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

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

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.

Sincerely,

Ron

-- 

(PS - If you email me and don't get a quick response, you might want to
call on the phone.  I get about 300 emails per day from alternate energy
mailing lists and such.  I don't always see new messages very quickly.)

Ron Frazier

770-205-9422 (O)   Leave a message.
linuxdude AT c3energy.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.ale.org/pipermail/ale/attachments/20110204/b677223f/attachment-0001.html