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. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
