Re: NAT and locally bound sockets

[Michael Shuey <shuey@fmepnet.org>]

On Thu, May 30, 2002 at 03:32:47PM +0200, Harald Welte wrote:
> Interestingly I don't remember this bug.  I (and nobody else) has added
> something to the TODO list about this either. Maybe it somehow got lost :(

I can't fault that; heck, I just took a month to reply to this email.

I looked up the previous comment about this issue:

http://lists.samba.org/pipermail/netfilter-devel/2002-January/003041.html

> Are you aware thet netfilter/iptables NAT is [in IETF terms] 'symmetric nat',
> which means that we can use the same port on the NAT gw multiple times, as
> long as the tuple (consisting out of srcip,dstip,srcport,dstport,l4proto) is
> unique.

Yes, I am aware that netfilter provides symmetric nat.  Unfortunately, its
port selection can provide a tuple that is _not_ unique.

> Could you please try to describe the scenario of this alleged bug? 

I ran into this when I had 100 hosts behind a single NAT box, all trying to
reach the same NFS file server at the same time the NAT box itself was
mounting the NFS server.  At the time I was using the default SNAT options
(not specifying a port range for the translations) so any traffic originating
at a port below 1024 would be mapped to natbox:<something under 1024>.  That
was working as expected.

In this scenario, think about the tuple for a moment.  Since all clients and
the natbox are mounting the same NFS server, selecting the same port by
default, using UDP across the board, the connection tuples are (after SNAT)
going to be very similar - they only differ in srcport.  Normally that would
be just fine; however, with a high level of traffic the NAT system would
occaisionally select a srcport that was already in use by the NFS client local
to natbox.  That's not fine - it causes quite a few NFS timeouts, retransmits,
etc. on natbox.

This is hard to observe (unless you have lots of NAT clients or a very
restricted range of possible srcports for translations), but lsof on the
natbox and a packet sniffer showed that this was, in fact, occurring.  I
ended up setting up an IP alias on the natbox just to route all translated
traffic through.  When I did that everything worked normally again - no NFS
problems at all on natbox (which is to be expected, since the translated
connections' tuples are now different from the local NFS client).

To fix this the NAT code needs to check to see what, if any, ports are
locally bound (and not use them, of course!)  The original poster for this
bug had a bit of code that tried to address this, but it was limited to UDP.
A proper fix would have to involve TCP as well (as a similar problem most
likely exists there, it just crops up much less frequently).

-- 
Mike Shuey