From: Henrik Nordstrom <hno@marasystems.com>
To: Philip Craig <philipc@snapgear.com>, netfilter-devel@lists.samba.org
Subject: Re: [PATCH] NAT for unreplied connections
Date: Wed, 5 Jun 2002 08:26:31 +0200 [thread overview]
Message-ID: <200206050826.31479@henrik.marasystems.com> (raw)
In-Reply-To: <3CFD67F7.5000801@snapgear.com>
On Wednesday 05 June 2002 03:23, Philip Craig wrote:
> A solution might be to add a MASQUERADE rule for the slip
> interface, and bring the slip down once I know the ppp is up. So
> in general I need to ensure that there is always MASQUERADE rule
> for the current route that an outgoing packet will take, and to
> bring the old interface down if there is a route change. This is
> still kind of a workaround for the problem, but if it works then I
> think that's good enough.
It should be sufficient to just have some MASQUERADE rule anywhere I
think. MASQUERADE does not seem to care what rules you have installed
when reacting on interface changes.. It will simply react on any
interface being brought down or ip address deleteions.
What you need to make sure to make it work is that the SLIP interface
is brought down or at least that there is an ip address deleted from
the interface SLIP interface... i.e. the following should do in the
ppp-up script even if you like to keep the slip interface around:
ip addr add 1.1.1.1/32 dev slip0
ip addr del 1.1.1.1/32 dev slip0
> I'd thought at first that this wouldn't be too much of a problem
> for TCP... it would just look to the server like two separate
> connections were being initiated, and the first one would never be
> established. I agree that it's not very good behavior though.
The problem is that your approach may cause this kind of problem at
any time if there is more than one computer involved (including the
NAT gateway itself), not only when there is interface changes.
Computer A is in contact server X on port 80, using port 1234 as
source port.
Computer B tries to contact server X on port 80, also using port
1234 as source port.
Server X is slow in responding, causing retransmissions
B sends SYN, NAT assigns it port 5678 as 1234 is occupied.
B retransmits, NAT reassigns B to port 4325 as 1234 is still
occupied and there has been other changes in current port usage
between the two SYN packets from B..
And this is only one case. There is more.
Regards
Henrik
prev parent reply other threads:[~2002-06-05 6:26 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-04 8:43 [PATCH] NAT for unreplied connections Philip Craig
2002-06-04 13:01 ` Henrik Nordstrom
2002-06-05 1:23 ` Philip Craig
2002-06-05 6:26 ` Henrik Nordstrom [this message]
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=200206050826.31479@henrik.marasystems.com \
--to=hno@marasystems.com \
--cc=netfilter-devel@lists.samba.org \
--cc=philipc@snapgear.com \
/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.