How does port checking work internally?

[Pierric82]

Hi,

I'm wondering how port checking works internally, since I'm struggling with getting a proper set up working with VPN port forwarding (for background, using Proton VPN, whereby I have a VM running Debian connected to Proton via wireguard, with PMP port mapping enabled; transmission is running on another machine, as a container, using a macvlan network access whereby the Proton-connected VM is acting as its gateway; this setup works overall for other containers, but my other containers don't require port forwarding).

Here's the thing: I can successfully create a port forward with Proton. When I "connect" this onto transmission, using socat (I relay tcp and udp traffic coming in from the Proton port to the same port that Proton picked on the transmission IP), I can use sites like portchecker.co to confirm the port is open (which really means socat is getting the connection; using -d -d on socat shows me that this connection is picked up properly). But if I then configure transmission to use that same port, it tells me after a few seconds that the port is closed. After this, checking using portchecker.co no longer works! That is, until I rerun natpmpc which seems to "refresh" the port forwarding. This sequence happens no matter how fast the sequence happens and is therefore not linked to the lifetime of the port forward. Checking the port from transmission somehow temporarily breaks the port forward on Proton side.

I've asked Proton support for their input on this, but in order to understand better, I'd like to know exactly what transmission does when it checks if the port is open. I had understood earlier that it just calls canyouseemenow.org from the backend, but I'm not sure anymore. Can someone explain this to me? I've also tried to check the source code to find out but got lost in the process.

For reference I'm illustrating here the kind of setup I'm aiming for, but really my core question for now is: how does the port checking work? if I understand this better I might be able to investigate more efficiently.

Thanks in advance!
P.

[tearfur]

When Transmission does a port check, it simply calls a port checking service similar to canyouseeme.org using curl. All we do is specify the destination url, and other curl settings for an easy handle, then we leave everything to curl.

If you want to know what those curl settings are, you can look at tr_web::Impl::initEasy() in libtransmission/web.cc.

But if I then configure transmission to use that same port, it tells me after a few seconds that the port is closed. After this, checking using portchecker.co no longer works! That is, until I rerun natpmpc which seems to "refresh" the port forwarding.

That's weird. Although I can't see how it can be related atm, we do have some port forwarding code in serveral files named libtransmission/port-forwarding*. And we have been getting issue reports about problems with that part of the code here and there.

[Pierric82]

Thanks!

This is very interesting.

First interesting thing: I ran curl https://portcheck.transmissionbt.com/46562 (this being the latest port assigned by natpmpc) from the VM running the VPN gateway, and I get '1'. Running the same command from inside the transmission container gets me a '0' (after a longer time). The public IP is the same for both, which I confirmed with curl ifconfig.me, so they should be looking at the same thing...

Second interesting thing: with this approach, running the transmission check (i.e. curling transmissionbt.com) does NOT "break" the port forwarding like when I use the web front-end to run the check. I can switch go to portchecker.co again after running the curl command from inside the container, and portchecker.co will still confirm the port is open.

Now if you have any ideas about what this could mean, I'll be reading them with high interest, because this whole thing completely baffles me! I have not yet "chased down the call stack" used in the code, but will try to do so, if my meagre skills allow for it. I suppose there must be something explaining the "breaking" of my port forwarding via the UI; but the sheer fact that the curl command returns something different when run inside the transmission container is also a hint I need to make sense of.

[tearfur]

I haven't got an idea either, but as I said, we specify some custom curl options in tr_web::Impl::initEasy(). So maybe you can add the command line equivalent of each of those options to your curl tests one by one, and find out which one breaks it.

[Pierric82]

Hi again @tearfur ,

Thanks to your help, I've solved my issue! It turned out - as always - to be a rather mundane mistake. My gateway machine acting as relay between the VPN and the transmission container was only doing masquerading one way. I got the idea to check the NAT setup after thinking some more about the fact that the same curl command yielded different results from the 2 machines, even though the publicly visible IP was the same. To be honest, I still don't fully understand why this difference is there. In my mind, once the transmissionbt.com server receives my curl query, it checks the IP from the caller and tries to connect on the port from the URL. This connection attempt is in my mind independent from the incoming HTTP query, and should not be affected by where the curl command originated from in my internal network 🤔 But in any case, after thinking "maybe I should not restrict masquerading to that interface only", it started working.

I would not have solved it without your help understanding how transmission queries its website; I would probably have given up due to my lack of visibility on what was happening. So I really want to thank you from the bottom of my heart for dedicating some time to answering me!

[tearfur]

...Maybe Transmission was just binded to a different interface than what your command line curl was using? Wouldn't that explain everything?

[Pierric82]

Hmm... I'm not sure... I don't think the container had many interesting alternatives and I can't wrap my head around why it would cause the observed behaviour... but the more I think about it, the more my brain melts :D I suppose I ought to build a sandbox scenario bit by bit to understand when the failure happens. If I get time, I'm sure I'll learn a ton by doing that!