Subject: Re: [Ietf-behave] Properly detecting netfilter NATs

From: Rémi Denis-Courmont <[email-masked]>
Date: Mon, 18 Sep 2006 13:35:16 -0500 (CDT) (envelope-from [email-masked])

Le samedi 16 septembre 2006 11:50, Rémi Denis-Courmont a écrit :
> > Unless there's a better way to detect netfilter NATs or work around
> > them in the client, I can put together a patch.

> AFAICT, symmetric-to-symmetric NAT traversal is plain impossible
> without triangle routing.

If I may clarify: I mean there, I believe, no way to get, say two users 
behind two distinct OpenBSD packet filter (which I read was purposedly 
symmetric - not checked on my own).

Can I know which precise 2.4 kernel version you were using? I'm pretty 
sure I started development of miredo with a 2.4-kernel-based NAT myself 
a few years back, so I suspect a change in the course of the 2.4 tree. 
I can't think of anyway to two miredo instances behind two NATs such as 
yours to communicate to each others. Unless timing is extremely 
fortunate, whenever one side tries to send a packet to the other it is 
bound to cause a "mis-binding", whereby the NAT would create a binding 
toward itself as I described in 
http://list.sipfoundry.org/archive/ietf-behave/msg00950.html .

So yeah, you seem to have uncovered a bothersome if not serious 
regression with the removal of the cone NAT probes.

If anyone has more input, it's welcome, but I am pretty much convinced 
NATs of such kind are hopeless with regards to peer-to-peer (let alone 
TURN, that is).

-- 
Rémi Denis-Courmont
http://www.remlab.net/
Attachment:
pgpE1H0u9djeD.pgp

---

From: Nathan Lutchansky <[email-masked]>
Date: Mon, 18 Sep 2006 19:35:50 -0500 (CDT) (envelope-from [email-masked])

On Mon, Sep 18, 2006 at 09:34:50PM +0300, R?mi Denis-Courmont wrote:
> Le samedi 16 septembre 2006 11:50, R?mi Denis-Courmont a ?crit :
> Can I know which precise 2.4 kernel version you were using?

It's a 2.4.29 kernel from OpenWRT.

> I'm pretty 

After more experimentation I found that dropping UDP packets on unused
NAT ports as described in your older message actually did sometimes work
at first, but it would always revert to the symmetric mode after a few
minutes.  So I can imagine light/test usage may not have revealed this
limitation to the workaround.

> you seem to have uncovered a bothersome if not serious 

Right, and considering that most of the NATs I've used myself in hotels,
wireless hotspots, conference centers, etc, tend to be Linux, BSD, IOS,
or some "secure" corporate-type NAT, I worry that Teredo doesn't have
much of a future unless some other higher-overhead operating mode can be
added to permit third-party relaying between two Teredo nodes behind
symmetric NATs.  -Nathan
Attachment:
pgpnI9Ec5Qd09.pgp