<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
I am not a networking guru, but here are some thoughts. See comments
in line.<br>
<br>
On 02/04/2011 03:49 PM, Michael B. Trausch wrote:
<blockquote cite="mid:1296852586.8916.94.camel@aloe" type="cite">
<pre wrap="">On Fri, 2011-02-04 at 14:21 -0500, Ron Frazier wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
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.<br>
<br>
<blockquote cite="mid:1296852586.8916.94.camel@aloe" type="cite">
<pre wrap="">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.
</pre>
</blockquote>
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.<br>
<blockquote cite="mid:1296852586.8916.94.camel@aloe" type="cite">
<pre wrap="">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?
</pre>
</blockquote>
Ahh ... now we know why you have a personal bias and grudge against NAT
routers! 8-)<br>
<blockquote cite="mid:1296852586.8916.94.camel@aloe" type="cite">
<pre wrap=""></pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
</blockquote>
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:<br>
<br>
quote on --><br>
<br>
The stateful firewall depends on the <a
href="http://en.wikipedia.org/wiki/Three_way_handshake#Connection_establishment"
title="Three way handshake" class="mw-redirect">three-way handshake</a>
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 <a
href="http://en.wikipedia.org/wiki/Packet_%28information_technology%29"
title="Packet (information technology)">packet</a> <a
href="http://en.wikipedia.org/wiki/Header_%28information_technology%29"
title="Header (information technology)" class="mw-redirect">header</a>.
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 <a
href="http://en.wikipedia.org/wiki/Black_hat" title="Black hat">hackers</a>
cannot start unsolicited connections with the protected machine.<br>
<br>
<-- end quote<br>
<br>
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.<br>
<br>
Now, in terms of UDP, the Wikipedia article says this:<br>
<br>
quote on --><br>
<br>
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.<br>
<br>
<-- end quote<br>
<br>
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. <br>
<blockquote cite="mid:1296852586.8916.94.camel@aloe" type="cite">
<pre wrap="">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
</pre>
<br>
</blockquote>
<br>
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.<br>
<br>
Sincerely,<br>
<br>
Ron<br>
<pre class="moz-signature" cols="72">--
(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
</pre>
</body>
</html>