Transmission-gtk does not properly bind to VPN interface

[fir3-1ce]

I tried creating a new rule to bind the Transmission bittorrent client to my VPN. I used /usr/bin/transmission-gtk for the executable and then selected wg-mullvad next to Network interface, with mullvad being my VPN provider and wg standing for WireGuard.

I turned off my VPN while Transmission was running to see if it worked. It seems that private trackers were successfully blocked, but public ones were not. To confirm the block wasn't working I added a very popular public torrent: the latest version of Linux Mint. Sure enough, Transmission started downloading at great speeds. Could this have something to do with DHT or PeX?

And it still asks if I want to allow connections when I open Transmission even though I just created this rule. So am I supposed to accept or deny that? I chose accept.

[Ubuntu 22.04 / Wayland / kernel 5.15.0-60-lowlatency]

[gustavo-iniguez-goya]

Hi @fir3-1ce ,

(...) selected wg-mullvad next to Network interface, with mullvad being my VPN provider and wg standing for WireGuard.

what's the name of the network interface as displayed with ip a?

I added a very popular public torrent: the latest version of Linux Mint. Sure enough, Transmission started downloading at great speeds.

Go to Addresses and Hosts tab, double click on the IP/domain of the public torrent and see what rule allowed it.

If there was no rule that allowed it, opensnitch should ask you to allow/deny it, so I guess there's a rule that is allowing it.

[fir3-1ce]

what's the name of the network interface as displayed with ip a?

Still wg-mullvad. I also have lo enp13s0 wlp12s0 and virbr0. I'm not sure what lo is but the rest are my ethernet, wi-fi and virtualbox networks, respectively.

Go to Addresses and Hosts tab, double click on the IP/domain of the public torrent and see what rule allowed it.

Pictured (above): OpenSnitch, Transmission's GTK GUI, and Mullvad's GUI - as you can see I'm unconnected

I'm not understanding what the problem is. I see systemd in there, is that what's doing it? But it also shows Transmission which I specifically edited to only go through wg-mullvad. There's also a site called tracker.openbittorrent.com that was making connections while the torrent you see pictured was the only one running.

If there was no rule that allowed it, opensnitch should ask you to allow/deny it, so I guess there's a rule that is allowing it.

I did hit "allow" a couple of times this session, but I've since removed them and only allowed one for Transmission-gtk with the wg-mullvad interface. I also removed the permanent rule I created earlier because it seemed useless if OpenSnitch was just going to create a temporary rule for Transmission anyway. Here's what my current rules look like:

Why is OpenSnitch saying that I allowed Transmission to make those connections when I clearly set it to only go through the Mullvad interface?

[gustavo-iniguez-goya]

I think this is the typical problem with systemd-resolved. Once you allow systemd-resolved, you allow many more connections than intended, not only DNS queries.

Do the following:

• Rename the transmission rule to 000-allow-transmission-vpn, and check [x] Priority rule
• Create a new rule with name 001-deny-tranmsission, set From this executable: /path/to/transmission and check [x] Deny

That should allow outbound connections to wg-mullvad interface, and deny anything else from transmission.

Besides this rule, edit the systemd-resolved rule, and configure the field To this port: 53, to allow only connections to the port 53. You'll probably also need to allow some other ports, for example: ^(53|5355)$ I usually also allow systemd-resolved connect only to my DNS nameservers IPs.

[fir3-1ce]

It worked. Here's that same torrent now, with the VPN off:

But with the VPN on, although I can download just fine, I can no longer utilize Mullvad's port forwarding feature:

This should say Open, as it was working before I set the new rules. Do I need to manually add the port somewhere in 000-allow-transmission-vpn? As you can see, the port for this IP is 57953, which falls outside the range of the ^(53|5355)$ you recommended earlier for systemd-resolve. This is good, right? They can't both use the same port, I imagine. Setting To this port: 57953 doesn't seem to open it though, which I found surprising.

I usually also allow systemd-resolved connect only to my DNS nameservers IPs.

Could you possibly expound on this for me? Do I just add the IPv4 addresses of those network interfaces I listed earlier? Specifically the ethernet and wifi ones.

Thanks

[fir3-1ce]

Wait a second, it looks like I can't connect to any https trackers anymore either. All of my private torrents use https

[gustavo-iniguez-goya]

Do I need to manually add the port somewhere in 000-allow-transmission-vpn?

In this case I don't think it'll work. The 000-allow-transmission-vpn rule should allow outbound traffic to wg-mullvad interface from tranmission, but in this configuration maybe it's not the case, maybe it's going through a different network path.

But with the VPN on, although I can download just fine, I can no longer utilize Mullvad's port forwarding feature:

I think this working method is not supported right now, but maybe there's a temporary solution.

On the one hand enable [x] Debug invalid connections and see if a pop-up appears to allow traffic to that port.

On the other hand I'll need debug logs to analyze this issue, so please, set LogLevel to DEBUG under Preferences -> Nodes. Reproduce the issue and post the log file /var/log/opensnitchd.log (remove any public IP from the log, or email me the log)

Also dump the firewall rules: $ sudo nft list ruleset There'll be probably some rule that is redirecting the traffic to/from that port.

Could you possibly expound on this for me? Do I just add the IPv4 addresses of those network interfaces I listed earlier? Specifically the ethernet and wifi ones.

No, what I suggest is to allow systemd-resolved connect only to port 53 and DNS nameserver IPs, for example:

Depending on how many DNS nameservers you have configured (/etc/resolv.conf) you'll be prompted several times systemd-resolved.

[fir3-1ce]

The log file has become quite long and shows everything I've ever done with OpenSnitch, but thankfully it's only been one day. Should I clear the log and start over? I have about 1,000 torrents in my Transmission currently so I assume you'll be seeing many incoming/outgoing connections from many different trackers. I'll allow posting of my addresses for now. I will remove it once I see that you've got it. Here's the log (19MB):

opensnitchd.log

There are over 4,000 instances of "57953" - the port I was trying to use. I hit the "Test Port" button a few times not too long before copying the log, so I would search that string starting from the end going backwards. Currently, all of my torrents are paused. If you want, I can clear the log, start over and just hit the "Test Port" button to see what it outputs. But you'll have to tell me how to clear the log.

Here is the output of sudo nft list ruleset > firewallrules.txt

firewallrules.txt

I still have debug invalid connections checked, but unfortunately it didn't seem to do anything.

[fir3-1ce]

Depending on how many DNS nameservers you have configured (/etc/resolv.conf)

I think I only have one? I only see one IP address in there, like this:

nameserver [IP] options edns0 trust-ad search .

So I can just leave the systemd-resolved rule at 53?

[gustavo-iniguez-goya]

Thank you for the info @fir3-1ce !

Itis gonna take a while to get the rules correctly configured, so please, be patient :)

• The rule 000-allow-transmission-vpn allowing outbound connections to wg-mullvad seems to be working fine. It's allowing traffic to port 57953 and IP 10.64.0.1 port 53, which seems to be the DNS nameserver of the VPN.

• The rule 001-deny-tranmsission to deny everything from transmission is also working great, blocking everything that is not going through the wg-mullvad interface. But it's blocking DNS queries to port 53, that's why the trackers don't connect.

Now we need to allow traffic to port 53 from transmission, but that traffic goes through the localhost interface lo:

• modify 000-allow-transmission-vpn to allow network traffic to the VPN and the local DNS stub resolver: ^(lo|wg-mullvad)$

Once you change the rule, systemd-resolved will use whatever DNS nameserver is configured in your server. If you VPN is connected, according to the logs, all queries will go to 10.64.0.1.

Test it and let me know if it works.

Should I clear the log and start over?

Yes please, it'll help to identify how it works when the VPN is connected vs not connected:

Before connecting to the VPN, close transmission, clear out the log, and launch transmission again:

~ $ sudo su
~ # truncate -s0 /var/log/opensnitchd.log

Let it run for a couple of minutes, and then close it.

Clear out the log again, connect to the VPN, and launch transmission. Let it run for a couple of minutes, etc.. and post the logs.

So I can just leave the systemd-resolved rule at 53?

Yes, leave it as it's right now.

[fir3-1ce]

Ok, starting off, I reset my PC, disconnected from the VPN, and hit 'Allow' for the usual stuff like apt, flatpak, sudo, etc.

I opened Transmission which had all torrents paused. I started two public torrents with udp://announce.opentrackr.org announce urls. (they were Linux Mint isos) Transmission was not able to connect to the trackers, which is good.

I hit the Test Port button, which of course is not supposed to work. It hung for a much longer time on "Testing TCP port...," whereas before it would've said Port is closed by now. But it does now say the port is closed, so that's ok.

Here is that log (It seems that it still caches all of my trackers even though they were paused) [6.8 MB]:

opensnitchd1.log

Cleared the log, and started Transmission again. Immediately it started to connect to that Mint iso torrent.

Tested port, and it says Open. Success!

Decided to start all of my torrents now. They all seem to be successfully getting peer lists, including the private https trackers. Everything seems to be working so far.

Left it running for another minute, here is the log [already at 16 MB]:

opensnitchd2.log

I am turning off Debug for now so I don't end up with a 100GB file. I will have to run more tests but I think you got it. Thank you for the quick responses and being so helpful.

Once you change the rule, systemd-resolved will use whatever DNS nameserver is configured in your server

I will need to do some of my own research on systemd. Is this one of the reasons people don't like it? It seems to make things complicated here

[gustavo-iniguez-goya]

wow, I thought it'd take us more tries to get it working :)

I will need to do some of my own research on systemd. Is this one of the reasons people don't like it? It seems to make things complicated here

Partially yes. Some use cases are complex, specially the ones related to multiple network routes, network interfaces, VPNs, routing DNS traffic to certain interfaces... after reading what it tries to solve I think it make sense.

Let's close this issue for now, since it seems to be solved.

[fir3-1ce]

Hi, I recently purged then reinstalled OpenSnitch so I could update the deb package, and I had just one quick question:

Is the systemd-resolved rule supposed to show nothing in the application path? I waited for it to show up in the pop up window, and that's when I set the rule to always allow to port 53 and my DNS namserver IP as it's destination (under Network).

In your screenshot above it says /lib/systemd/systemd-resolved for the binary path, but when I open the rule in mine it says nothing:

I don't remember what file path it specified in the pop-up window for me, but the name was definitely systemd-resolved. Since systemd is PID 1 does that mean it doesn't need to be specified? Thanks and thank you for the great software

[fir3-1ce]

Ok, that was weird. I just launched Steam and I got the systemd-resolved prompt with the actual full binary path of /usr/lib/systemd/systemd-resolved. I checked Allow/Always and went into the Network tab to add port 53 and my DNS nameserver IP. Now I'm not sure what to do with the other one.

cat /etc/resolv.conf shows me only one nameserver, but resolvectl has a second one listed under "Link 2", which is my ethernet connection, or enp13s0. The one listed in my /etc/ file is listed under "Global" here, at the very top.

[fir3-1ce]

I made 2 systemd rules, one for my Global DNS and one for my Ethernet's DNS. Both to port 53. I couldn't figure out how to add a list of IPs in just one rule, that wasn't working for me for some reason