STUN/TURN NAT Traversal

[tuxSlayer]

Hello ALL,

AFAIK, Transmission supports UPnP & NATPMP port mapping. It works quite good for me if I am behind one NAT/firewall.
But in cases I have one NAT (say, wifi router) at home and one at ISP side it doesn't work. Transmission reports forwarded port # to the network and network can't use it, since its NAT'ed by ISP.

Why Transmission can't use STUN (at least) technique to make its way thru all-ever NATs and obtain its really ip:port?

We even don't need separate STUN server - other Transmission clients can fullfil this role.

Any comments?

[blacke4dawn]

The big problem here would be then to find another Transmission client that isn't behind a NAT to act as a "STUN server", and them having chosen to enable that feature. Honestly, setting up a real STUN server for this would be easier.

Personally more I'm concerned with your ISP NATing you. Can't really think of why they would do it unless they got more subscribers than IP-addresses.

[jch]

That's my cue, isn't it?

Personally more I'm concerned with your ISP NATing you.

This kind of ISP-side NAT is known as "Carrier-Grade NAT", and it's going to be increasingly common. ISPs would just love to be able to NAT their customers, so as to be able to charge extra those customers who want a globally-routable IP address. Right now, it's already the norm with IP over cellular; I'm willing to bet it'll be common with low-end cable and ADSL within a few years.

Why Transmission can't use STUN (at least) technique to make its way thru all-ever NATs

It already does.

Contrary to what some people think, there's not just one STUN protocol; STUN is a set of techniques, that are used by different protocols.

STUN techniques require that a "STUN server" be deployed somewhere on the internet, and usually only work reliably for UDP. There are at least two STUN techniques that are widely deployed with BitTorrent clients, only one of which is supported by Transmission.

(1) Teredo is Microsoft's official STUN protocol. Since Teredo is supported by Microsoft, it's the one most likely to be compatible with the most NAT boxes, and ISPs are typically going to check for compatibility with Teredo before they deploy CG-NAT.

Teredo is somewhat different (IMHO better) than other STUN protocols by working on a system-wide level, not just for one application. Please see

viewtopic.php?f=1&t=9138&start=0#p42675

for more information about enabling Teredo under Linux and Mac OS X (it happens automatically under Windows).

(2) µTorrent implements a proprietary STUN technique, called "ut_holepunch". It only works with µTP, not with normal, TCP-based BitTorrent. (As a matter of fact, it is the original motivation for µTP.) ut_holepunch is completely undocumented, and only implemented by µTorrent.

--jch

[jch]

We even don't need separate STUN server - other Transmission clients can fullfil this role.

Oh, I missed this bit.

ut_holepunch works the way you suggest -- it uses other (un-NATed) µTorrent clients to serve as a STUN server.

Teredo works by using a bunch of servers provided by Microsoft (in the case of Microsoft's Teredo client), Rémi-Denis Courmont (for the Linux/BSD Teredo client) and various Linux distributors, notably Debian.

--jch

[tuxSlayer]

It already does.

then I can't see why other hosts are not able to download content from me via UDP or at least to ask me for TCP connection from my side..

[jch]

then I can't see why other hosts are not able to download content from me via UDP

They are. Any teredo-teredo communication is being encapsulated in UDP.

--jch