From: Henrik Nordstrom <hno@marasystems.com>
To: shuey@purdue.edu, Michael Shuey <shuey@fmepnet.org>,
Harald Welte <laforge@gnumonks.org>,
netfilter-devel@lists.samba.org
Subject: Re: NAT and locally bound sockets
Date: Mon, 1 Jul 2002 18:59:39 +0200 [thread overview]
Message-ID: <200207011859.39589.hno@marasystems.com> (raw)
In-Reply-To: <20020701163232.GB7090@lucky>
Michael Shuey wrote:
> 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 handled fine in all tests I have done provided your SNAT rule applies
to both forwarded and locally originating packets.
If however your UDP nat entries times out from conntrack, which they can
easily do for a idle NFS mount, then all bets is off.. The default udp
timeout is only 180 seconds which is not by far sufficient for multi-client
NAT of NFS. A typical case where conntrack by default cannot easily know a
suitable timeout without additional information.
Regards
Henrik
next prev parent reply other threads:[~2002-07-01 16:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20020529164926.GA9003@gort.ecn.purdue.edu>
[not found] ` <20020530153247.I7658@sunbeam.de.gnumonks.org>
2002-07-01 16:32 ` NAT and locally bound sockets Michael Shuey
2002-07-01 16:59 ` Henrik Nordstrom [this message]
2002-07-01 18:46 ` Michael Shuey
2002-07-02 7:52 ` Henrik Nordstrom
2002-07-02 14:21 ` Harald Welte
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200207011859.39589.hno@marasystems.com \
--to=hno@marasystems.com \
--cc=laforge@gnumonks.org \
--cc=netfilter-devel@lists.samba.org \
--cc=shuey@fmepnet.org \
--cc=shuey@purdue.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.