UDP, TCP, and NAT (was...)

[Thomas Charron]

On 7/13/07, Ben Scott <dragonhawk at gmail.com> wrote:
> On 7/13/07, Thomas Charron <twaffle at gmail.com> wrote:
> >   I know that's the case, however, PAT can often cause UDP based
> > protocols to break, as opposed to TCP protocols, where doing PAT is
> > much easier.
>   The thing you seem to be missing is that it's not so much a UDP vs
> TCP distinction, but an application protocol thing.

  ...  Yes.  And UDP is by design and specification connectionless
datagrams.  One way.

>   It is true that UDP is inherently connectionless and one-way, while
> TCP is inherently connection-oriented and two-way.  At the same time,
> almost any application protocol is bi-directional by nature (how often
> do you really only want to talk one way?).  So there's pretty much
> always going to be a two-way conversion.

  ...  UDP is by DEFINITION connectionless, and TCP is by DEFINITION
connection oriented!  And generally utilizing streamed UDP data *IS* a
one way conversation.  Any secondary streams, such as a command and
control stream are *different* in their protocol.  If you need to have
a two way conversation, it *generally* is a better idea to use TCP,
unless you do not care about data which may be lost, such as with
audio and/or video streams.

>   Now, if you're a programmer or protocol designer, are you going to
> go to the trouble of rolling your own mechanism for negotiating the
> port numbers for the return traffic (or using portmapper or some other
> thing), and making multiple sockets, or are you just going to use the
> port number and socket which are already there?

  Depends, honestly.  But your point is perfectly valid.  I'm not
saying it's wrong, I'm saying that the automatic UDP port forwarding
of NAT boxes isn't standardized anywhere, they just started 'doing
it'.  Some may argue that it's a really bad idea in general.

>   Most use the later approach, and thus we end up with many
> application protocols (TCP and UDP) which work just fine over a simple
> address/port translation which assumes incoming and outgoing are
> symetrical.

  Except of course, when the initial UDP packet is coming from the
outside.  Which is why 'obtuse' ways of discovering and forcing a NAT
router to allow traversal of UDP data via STUN and/or ICE.  If it was
so 'easy', these methods would never be required, but they are, and
their sole purpose is to 'trick' NAT boxes to let traffic it doesn't
WANT to let thru, thru.

>   There are exceptions in all cases.  Most of them arise not because
> of the use of UDP, but because the application protocol expects to
> send additional packets to *different* port numbers on the way back
> in.

  See above.  There are others.

>   (This is all in "active mode" FTP.  In passive mode, the roles are
> reversed, but you still have the same problem and solution if the
> server is behind a NAT boundary.)

  I snipped the text as it was informative, but irrelevant.  FTP works
backwards, but mostly because it was a throwback to days before NAT
WASN'T short for 'Natalie'.  ;-P

>   BitTorrent works similarly.  Swarm members register the pieces they
> have with the tracker by making an outgoing TCP connection.  Swarm
> members *also* make TCP connections to peers which have pieces they
> need.  With a dumb NAT, those will fail.  (There is a mechanism to
> have peers request reverse connections through the tracker, but it can
> get overloaded, and it's worthless if both peers are behind dumb NAT.)
>   I understand VoIP works similarly, but happens to use UDP rather than TCP.
>   Linux's NetFilter state module calls packets which are part of the
> same TCP connection or UDP session "ESTABLISHED", and packets for
> things like the FTP data channel "RELATED".  That's why the firewall
> rules need to allow both ESTABLISHED and RELATED for FTP to work.  You
> also need to load a "conntrack" (connection tracking) module specific
> to each application protocol.  There's one for FTP, for example.

  Ok, I understand your argument now.  You are right, and ALL of these
applications which utilize TCP don't traverse NATs very well without
tricks.  However, the list of applications which utilize UDP and
cannot traverse a NAT is much greater then those which have issues
with TCP.

> > But your right, I suppose I presented it as 'This sux0rs!' as opposed to
> > 'It will rarely, however, not work depending on the protocol'.
>   Sure.  But the same can be said for TCP applications.  See above.

  Point taken.  See paragraph earlier, I see what you where saying
now.  But here is the core point from MY side.  It is generally much
easier to deal with multiple incoming connections via TCP.  And if
your having a two way conversation, it is much easier, and in my
opinion better, to use TCP.  Applications which use UDP and have to go
thru the hoops of STUN/ICE negotiation prob shouldnt be using UDP. UDP
is meant for datagrams.  Little snippets of data.  It original intent
wasn't for connection oriented communications.

> > You are correct, Linux NetFilter *does* operate in the case of DNS
> > as you say.  But others do not, and will actually maintain state
> > information based on the serial number of the DNS request contained
> > inside the UDP packet.
>   That sounds more like a firewall thing than a NAT thing, although I
> readily admit the line between the two is rather blurry in many cases.
>  In any event, though, the point was that you don't *need* to do that
> kind of thing for UDP to work through a NAT boundary -- but you may
> well need it for specific application protocols, on either TCP or UDP.

  Now I have to do some tests to see why pfSense wasn't assing my UDP
based OpenVPN connections correctly.  Because something funny, at east
in my case, was going on when I attempted multiple VPN connections
over UDP thru it.

-- 
-- Thomas