Remix.run Logo
akerl_ 7 months ago

The reason that peer-to-peer tools tend not to work well behind NAT is because peers can't initiate inbound connections to you.

So your router gets 1.2.3.4 as an external IP. And it assigns you 192.168.1.10 as an internal IP, and handles NAT for your outbound connections. You start your torrent client and it advertises "hey, I have all these Linux ISOs, and I'm at 1.2.3.4:50000, come connect to me". Peers try to connect to 1.2.3.4:50000, and your router says "who the hell is this".

This is what UPNP and related tools attempt to solve. UPNP works by allowing your computer to say to your router "hey, I'm going to want inbound connections on port 50000, so if you get any, send them to me".

Other methods like STUN/TURN/etc use different techniques to get around the issue.

n4bz0r 7 months ago | parent [-]

This makes perfect sense on paper, but I disabled UPNP in router settings at some point just to see what happens and the torrents still work to this day. No issues with no apps whatsoever. That got me confused and I assumed that NAT masquerading is responsible for such "port forwarding" (having the address translation table and all that).

I'm currently using Mikrotik router with the latest RouterOS and Transmission/qBitTorrent for the clients if that helps. Any idea why is this the case?

And if (just in case) Mikrotik's implementation of NAT does in fact do "UPNP", why add separate UPNP settings? By the looks of things, I would assume that, when disabled, UPNP still works, but with some default rule set, and when enabled, you get to fine tune the interfaces. But that's just a wild guess. No mentions of such behaviour in the official wiki.

Sorry, Mikrotik does some arcane things so learning network concepts on RouterOS often leaves one with more answers than questions :')

arantius 7 months ago | parent [-]

Because this misunderstanding and limitation is so common, BitTorrent has workarounds in place.

See https://superuser.com/a/1548724