"Listenless" TCP over NAT?

"Listenless" TCP over NAT?

[xerces8]

Hi!

Recently someone mentioned on this (or maybe other...) list a seldom used
technique of establishing a TCP connection without one host listening on a port,
but but acting as "clients" and connecting to the peers port.

My question: Can this be used to establish a TCP connection between two hosts that
are both behind a (P)NAT router ?

(the idea being: NAT router lets outgoing connections thru, and in this case both
NAT router would  see an "outgoing" connection)

If yes, this would simplify the life of many users :-)

Regards,
David

Re: "Listenless" TCP over NAT?

[Ben Hutchings]

xerces8 wrote:
> Hi!
> 
> Recently someone mentioned on this (or maybe other...) list a seldom used
> technique of establishing a TCP connection without one host listening on a port,
> but but acting as "clients" and connecting to the peers port.
> 
> My question: Can this be used to establish a TCP connection between two hosts that
> are both behind a (P)NAT router ?
> 
> (the idea being: NAT router lets outgoing connections thru, and in this case both
> NAT router would  see an "outgoing" connection)
> 
> If yes, this would simplify the life of many users :-)

It's a bit more complicated than that.  See
<http://en.wikipedia.org/wiki/TCP_hole_punching>.

Ben.

-- 
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.

Re: "Listenless" TCP over NAT?

[Evgeniy Polyakov]

On Fri, Sep 05, 2008 at 01:45:13PM +0200, xerces8 (xerces8@butn.net) wrote:
> Recently someone mentioned on this (or maybe other...) list a seldom used
> technique of establishing a TCP connection without one host listening on a port,
> but but acting as "clients" and connecting to the peers port.

This is supported by userspace network stack, which was presented here,
but I'm not sure that exactly unetstack was recommended to you.

http://tservice.net.ru/~s0mbre/old/?section=projects&item=unetstack

> My question: Can this be used to establish a TCP connection between two hosts that
> are both behind a (P)NAT router ?
> 
> (the idea being: NAT router lets outgoing connections thru, and in this case both
> NAT router would  see an "outgoing" connection)

Depending on how NAT is implemented. Usually NAT software will only
allow syn/ack packets before connection is established, and thus if one
peer sends syn packet, and second one sends ack packet (without seeng
ack first) it will work, but if second peer's NAT will send a reset
packet before ack from the peer, first NAT can drop connection (as long
as peer itself).

> If yes, this would simplify the life of many users :-)

It is not directly supported by unetstack, but you can simply extend its
state machine to switch to different state without explicit packet
receiving.

-- 
	Evgeniy Polyakov

Re: "Listenless" TCP over NAT?

[Rémi Denis-Courmont]

On Fri, 05 Sep 2008 13:45:13 +0200, "xerces8" <xerces8@butn.net> wrote:
> Recently someone mentioned on this (or maybe other...) list a seldom used
> technique of establishing a TCP connection without one host listening on
a
> port, but but acting as "clients" and connecting to the peers port.
>
> My question: Can this be used to establish a TCP connection between two
> hosts that are both behind a (P)NAT router ?

Linux TCP/IP does allow this at the end nodes.

However, whether it works on the NAT model. Many NAPT and firewalling boxes
will reset the TCP session if you try to do TCP simultaneous open. Besides,
you need to be able to predict your source port number, which again is not
always possible depending on the NAPT implementation.


As far as I can tell, this is simply way too failure prone in real life.
Using some form of UDP encapsulation, such as ICE, Teredo, IPsec-in-UDP,
etc works A LOT better, although not always either.

--
Rémi Denis-Courmont

Re: "Listenless" TCP over NAT?

[xerces8]

Rémi Denis-Courmont wrote:

> Linux TCP/IP does allow this at the end nodes.
> 
> However, whether it works on the NAT model. Many NAPT and firewalling boxes
> will reset the TCP session if you try to do TCP simultaneous open. Besides,
> you need to be able to predict your source port number, which again is not
> always possible depending on the NAPT implementation.
> 
> 
> As far as I can tell, this is simply way too failure prone in real life.
> Using some form of UDP encapsulation, such as ICE, Teredo, IPsec-in-UDP,
> etc works A LOT better, although not always either.

Yes, but that requires either additional drivers or privileges, while
TCP simultaneous open works without all that.

Thanks for giving me the name of this thing ;-)
I will do some experimenting at home (there goes the weekend...)

Regards,
David