From: Pablo Neira Ayuso <pablo@netfilter.org>
To: Oliver <oliver@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa>
Cc: xiaosuo@gmail.xom, netfilter-devel@vger.kernel.org
Subject: Re: [PATCH] netfilter: Kill unreplied conntracks by ICMP errors
Date: Tue, 17 Dec 2013 14:01:17 +0100 [thread overview]
Message-ID: <20131217130117.GA8852@localhost> (raw)
In-Reply-To: <2247276.HWz9edslhi@gentoovm>
On Sun, Dec 15, 2013 at 07:57:02AM +0100, Oliver wrote:
> On Thursday 12 December 2013 10:19:34 Changli Gao wrote:
> > Think about the following scenario:
> >
> > +--------+ +-------+ +----------+
> >
> > | Server +------+ NAT 1 +------| Client 1 |
> >
> > +---+----+ +-------+ +----------+
> >
> > | +-------+ +----------+
> >
> > +-----------+ NAT 2 +------| Client 2 |
> > +-------+ +----------+
> >
> > The following UDP punching steps are used to to establish a direct session
> > between Client 1 and Client 2 with the help from Server.
> >
> > 1. Client 1 sends a UDP packet to Server, and Server learned the public IP
> > and port of Client 1.
> > 2. Client 2 sends a UDP packet to Server, and Server learned the public IP
> > and port of Client 2.
> > 3. Server tells Client 1 the public IP and port of Client 2.
> > 4. Server tells Client 2 the public IP and port of Client 1.
> > 5. Client 1 sends UDP packets to the public IP and port of Client 2.
> > 6. Client 2 sends UDP packets to the public IP and port of Client 1.
> >
> > If both NAT 1 and NAT 2 are Cone NAT, Client 1 and Client 2 can communicate
> > with each other directly.
> >
> > Linux tries its best to be a Port Restricted NAT. But there is a race
> > condition between 5 and 6.
> >
> > Suppose the packet from Client 1 to the public IP and port of Client 2
> > reaches NAT 2 before the packet from Client 2 to the public IP and port of
> > Client 1, and it belongs to a new session to NAT 2 itself since there isn't
> > any corresponding conntrack in NAT 2, and it is likely that port isn't
> > opened at NAT 2, so at last, a Port Unreachable ICMP packet will be
> > delivered to Client 1.
>
> I don't think that's universally the case; whether or not a port unreachable
> happens is going to depend on the configured behaviour; it may very well just
> silently drop the packet.
Indeed. You can configure those two NATs to make them more
hole-punching friendly by dropping UDP packets to local closed ports,
so that conntrack entry won't be created.
next prev parent reply other threads:[~2013-12-17 13:01 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-12 15:19 [PATCH] netfilter: Kill unreplied conntracks by ICMP errors Changli Gao
2013-12-15 6:57 ` Oliver
2013-12-17 13:01 ` Pablo Neira Ayuso [this message]
2013-12-17 14:52 ` Changli Gao
2013-12-17 16:58 ` Pablo Neira Ayuso
2013-12-19 4:29 ` Changli Gao
2013-12-19 19:51 ` Pablo Neira Ayuso
2013-12-17 14:46 ` Changli Gao
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=20131217130117.GA8852@localhost \
--to=pablo@netfilter.org \
--cc=netfilter-devel@vger.kernel.org \
--cc=oliver@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa \
--cc=xiaosuo@gmail.xom \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).