UPnP and NAT-PMP port forwarding

[feross]

Universal Plug and Play (UPnP) is a set of networking protocols that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices to seamlessly discover each other's presence on the network and establish functional network services for data sharing, communications, and entertainment. UPnP is intended primarily for residential networks without enterprise-class devices.

Note: UPnP only makes sense in the node.js (server) use case. In the browser, WebTorrent uses WebRTC and the browser handles NAT traversal using the ICE, STUN, and TURN protocols. Lots of fun acronyms :)

This issue is for adding UPnP and/or NAT-PMP support to WebTorrent. There appear to be quite a few implementations on npm, so a bit of research will be required to find the best implementation to use.

[jmaris]

Second this, I'm trying to make connections and it simply won't work ..

[astro]

@jman6495 In node, right? Making outgoing connections doesn't need an open port or even a listening socket.

[feross]

@jman6495 Yeah, you should be able to download just fine without UPnP and NAT-PMP port forwarding. They're just useful if you want people to be able to make incoming connections to you.

[drwasho]

Any progress on this?

[mnaamani]

There is a nice library that I use in my own projects, node-nat-upnp but it needs a couple of small fixes

[retrohacker]

Leaving this here for future reference

RFC5128: State of Peer-to-Peer (P2P) Communication across Network Address Translators (NATs)
https://tools.ietf.org/html/rfc5128

[roccomuso]

Any update on this issue?
Is it just a matter of finding the right upnp module to use?

[feross]

@roccomuso Yeah, and someone needs to do the work of integrating it.

[roccomuso]

@feross any idea on the upnp module to use?

[feross]

No, sorry. I haven't done an exhaustive search of npm. Ideally, something with no or few dependencies. And definitely no native dependencies.

[roccomuso]

Ok, there's no wide choice around, I came out with this, https://github.com/indutny/node-nat-upnp
Take a look and let me know.

[feross]

@roccomuso That looks fine, but the dependencies are a bit heavyweight. xml2js, async, request are all substantial dependencies by webtorrent's lightweight standards. But it's probably fine to use this for now.

For NAT-PMP, this module looks excellent: https://github.com/TooTallNate/node-nat-pmp -- only has debug as a dependency, which is already used by webtorrent.

[roccomuso]

@feross So what should be the general workflow? Trying first to use NAT-PMP and if failed then having a fallback on UPNP?

[feross]

Basically, upon initialization of a WebTorrent client, we should create a port mapping using the client's listening post (torrentPort) and the DHT's listening port (dht.address().port).

You can probably just add a new function to index.js and handle this there.

[mnaamani]

Watch out there is a small bug in node-nat-upnp

I made an attempt to solve it at one point in indutny/node-nat-upnp#20 which was good enough for a use case I had, but it might be better to have a look at storj/core#78 for a complete fix.

It would be great to get the bug fix into upstream and have updated version of the npm module published.

[littleskunk]

@mnaamani
indutny/node-nat-upnp#23 already merged and released. UPnP is working fine for us. Later we would like to add NAT-PMP as well. storj/core#218

We will start with UPnP first and use NAT-PMP as fallback. Just in case NAT-PMP is not as stable as UPnP. After a few month and user feedback we can think about a different order.

We had a few problems with UPnP.
1.) Stupid user are running 2 NAT firewalls. UPnP will return a private IP address. Fixed with https://github.com/Storj/core/blob/99fa555399f2931e41693f7ca211397563daf4ff/lib/network/transport.js#L127
2.) On one windows pc UPnP returned more than a string as IP address. storj/storjshare-gui#269 (comment)

[lmatteis]

@feross without this, none of the webtorrent-desktop clients are talking to each other, right (unless you specifically open your webtorrent port on your router)? This seems like a pretty big deal, at least in terms of healthy network topologies, since webtorrent-desktop is gaining some traction.

[feross]

@lmatteis webtorrent-desktop clients that are not behind NATs can be reached by all other clients (webtorrent-desktop and otherwise). But yeah, you're right.

[gpetrov]

@feross hope we can soon see more of the https://github.com/indutny/node-nat-upnp and https://github.com/TooTallNate/node-nat-pmp integration soon, as WebRTC is not running really well with many torrents #903

[roccomuso]

I just discovered this https://github.com/bcoin-org/bupnp

[dookyoonhan]

Is there anyone who still keeps track of this issue?
We found that NAT problem does not occur when the NAT-behind clients announce themselves as WEBRTC peers onto 'ws' tracker. However, due to #1349, we concluded WebRTC peer was not an excellent option to our project currently either, especially under the condition that there was a massive number of peers. It always crushed with too-many-rtc-peer-connection error.
To resolve this, we decided to use and allow only 'udp' trackers, and tcp(udp) peers temporarily, which now brings NAT-traverse problem.
I am reading the webrtc peer part expecting to find some clue to apply ICE protocol to udp tracker/peers to resolve this NAT-traversal problem. Any suggestion or ideas about this?
(Besides, I wonder how #1437 by Oleiba was like. As far as I know, uTorrent support upmp/nat-pmp by its default. )

[oleiba]

#1437 actually worked and I used it. It was closed because no one reviewed it.

[feross]

#1437 actually worked and I used it. It was closed because no one reviewed it.

I reopened it. We're behind on code reviews but I'm trying to work my way through them slowly. Thanks for understanding!