I’m a long-time Transmission user but I just learned that VPN killswitches are a thing (how did it take me so long!?). I would like to try another client which has this feature in case I forget to launch my VPN client before opening Transmission. Does anybody have any recommendations? Deluge? QBittorrent? Or any others?
If you’re using Nord VPN then you can enable a kill switch directly in the VPN through a console command which is documented on the Nord docs. It works, I tested it.
I would not rely on Nord’s VPN killswitch. It can be slow and unreliable and still briefly expose your IP to the swarm. I got an ISP letter thinking I was protected through nord’s killswitch, but turns out it was not completely covering me.
I would bind the client to the wireguard network interface directly through the client. In Qbittorrent you can do it pretty easily as @CrabAndBroom@lemmy.ml mentioned.
Mullvad has one right in the GUI too, it’s called “Lockdown Mode” IIRC.
Also qBittorrent has a thing in preferences where you can bind it to a specific network interface, so you can just set it to whatever your VPN uses (for Mullvad Wireguard it’s ‘wg-mullvad’) and then if the VPN goes down it just won’t do anything.
Most can bind it an IP even if they don’t bind to an interface. I use rtorrent and airvpn/wireguard. Wireguard uses a static IP address for the client and rtorrent can bind to that IP. If the VPN goes down (which is very rare in my experience) rtorrent stays running but it won’t work on any other IP address.
Like the other comments, I use qbittorrent. I recommend running your VPN with gluetun and routing the traffic from your qbittorrent container through it. If the gluetun container is down, no traffic at all. If it’s up, everything goes through the vpn
Adding to the qbittorrent recommendations: qb has Socks5 support and and supports binding traffic to a specific interface. It doesn’t get much better than this.
As others have said, just use qBit. It’s feature-rich and supports network interface binding. Simply bind it to your VPN’s interface, and it’ll only use your VPN. If your VPN connection drops/isn’t turned on, qBit simply won’t be able to connect.
It’s not just about being simple, it’s about 1) still using transmission - because some people like decent and simple torrent clients and 2) a systemd enforced network restriction is way safer than whatever bind to interface / IP setting a program might come up with.
Its simpler than having to learn another torrent client or whatever, at the end of the day what I’m suggesting is adding a line to a text file with the interface.
I disagree that it’s simpler, because most VPNs will use dynamic IPs. So any time your internet flickers or your power goes out, you’ll need to reconfigure Transmission with the new IP. Sure your method works for a kill switch. But it requires manual intervention every time it gets killed. With qBit’s interface binding, it doesn’t care what the VPN’s IP is. All it cares about is that it’s using the specific interface. So if the VPN is disconnected (and the VPN’s interface has no connection) then qBit simply thinks there’s no connection to the internet.
you’ll need to reconfigure Transmission with the new IP. Sure your method works for a kill switch. But it requires manual intervention every time it gets killed.
It doesn’t. You can specify your VPN provider range instead of a single IP and you won’t need manual intervention.
RestrictNetworkInterfaces=
Takes a list of space-separated network interface names. This option restricts the network interfaces that processes of this unit can use.
So I guess this is a better option than doing IP or IP range restrictions - zero manual intervention like you do in qBit. I’m so used to work with IPs instead of interfaces (because of the issues that can cause) that I even forgot about that option.
I have an OpenWRT router with an OpenVPN client on it. I use the router’s firewall rules to secure the access as needed. If I’m using the VPN, then the VPN is the only way traffic can get out, as I close the direct route via firewall.
This setup persists even after a router reboot.
To do this easily, I made a Python script that can load the OpenVPN files on the router, switch on/off the OpenVPN connection and modify the firewall accordingly.
This affects the entire network, and means I am not reliant on the torrent software or desktop VPN client playing ball.
Happy to share my script if it will be handy to you.
Much like in the attached image, OP has requested help with a specific thing and the responder has not provided any helpful information and has simply told OP to do something completely different with no further explanation.
I use this Docker image of Transmission that has a built-in VPN configuration. That way only the torrent traffic goes over the VPN and it starts automatically.
Docker with a gluetun container. This container’s only role is to connect to my VPN provider. Any traffic I want through the VPN is set to use that container as its network. If the VPN goes down, gluetun loses connection, any container attached to gluetun can no longer access the internet.
I use a qbittorent docker container for my torrent client but you can attach whatever client you’re comfortable with, as well as any other container you prefer be on a VPN.
While qbittorent has a built in kill switch, this works for everything. No VPN means no connection, period.
That’s exactly what I have set up too. I also have gluetun tied to my Prowlarr and NZBget containers. I know Prowlarr tied to VPN may be overkill but it doesn’t hurt anything so why not?
As long as the tracker doesn’t have anything against VPNs doesn’t hurt.
Nowadays not sure 🤔 but some didn’t allow VPN access on the tracker webpage and at the end except in some cases that is what Prowlarr does.
Haha, same. Stuck Prowlarr on there because why not? That’s the beauty of this setup. It takes no effort after gluetun is set, so no reason not to just attach anything even remotely questionable.
You don’t need to switch to another client. Apparently Transmission can be set to bind to your VPN IP by editing settings.json:
bind-address-ipv4: String (default = “0.0.0.0”) Where to listen for peer connections. When no valid IPv4 address is provided, Transmission will bind to “0.0.0.0”.
bind-address-ipv6: String (default = “::”) Where to listen for peer connections. When no valid IPv6 address is provided, Transmission will try to bind to your default global IPv6 address. If that didn’t work, then Transmission will bind to “::”.
If you set those with your VPN IP and the VPN is down then Transmission won’t be able to communicate with any peers.
Another option, is to use systemd to restrict Transmission’s networking to your VPN IP. You can make an override of the default transmission daemon unit by using the following command:
systemctl edit transmission-daemon.service
Then type what you need to override:
[Service]
IPAddressDeny=any
IPAddressAllow=10.0.0.1 # --> your VPN IP here
Another systemd option, might be to restrict it to a single network interface:
[Service]
RestrictNetworkInterfaces=wg0 # --> your VPN interface
Save the file and run systemctl daemon-reload followed by systemctl restart transmission-daemon.service and it should be applied.
This will be safer than just doing bind-address-ipv4 and bind-address-ipv6.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !piracy@lemmy.dbzer0.com
⚓ Dedicated to the discussion of digital piracy, including ethical problems and legal advancements.
If you’re using Nord VPN then you can enable a kill switch directly in the VPN through a console command which is documented on the Nord docs. It works, I tested it.
I would not rely on Nord’s VPN killswitch. It can be slow and unreliable and still briefly expose your IP to the swarm. I got an ISP letter thinking I was protected through nord’s killswitch, but turns out it was not completely covering me.
I would bind the client to the wireguard network interface directly through the client. In Qbittorrent you can do it pretty easily as @CrabAndBroom@lemmy.ml mentioned.
Mullvad has one right in the GUI too, it’s called “Lockdown Mode” IIRC.
Also qBittorrent has a thing in preferences where you can bind it to a specific network interface, so you can just set it to whatever your VPN uses (for Mullvad Wireguard it’s ‘wg-mullvad’) and then if the VPN goes down it just won’t do anything.
Most can bind it an IP even if they don’t bind to an interface. I use rtorrent and airvpn/wireguard. Wireguard uses a static IP address for the client and rtorrent can bind to that IP. If the VPN goes down (which is very rare in my experience) rtorrent stays running but it won’t work on any other IP address.
Like the other comments, I use qbittorrent. I recommend running your VPN with gluetun and routing the traffic from your qbittorrent container through it. If the gluetun container is down, no traffic at all. If it’s up, everything goes through the vpn
qbittorrent can do this, and its what I use.
not sure if its the best nowadays but it works really well for me.
Adding to the qbittorrent recommendations: qb has Socks5 support and and supports binding traffic to a specific interface. It doesn’t get much better than this.
Yes it can get better :P https://lemmy.world/comment/5269089
I mean… That essentially does the same thing but it’s much more complicated than just clicking a button in the qb GUI…
True, but enforcing the restriction at the systemd level will be safer. Frankly I like Transmission.
Fair enough.
As others have said, just use qBit. It’s feature-rich and supports network interface binding. Simply bind it to your VPN’s interface, and it’ll only use your VPN. If your VPN connection drops/isn’t turned on, qBit simply won’t be able to connect.
There’s a simpler option for those who like Transmission: https://lemmy.world/comment/5269089
In what way does this seem simpler to you?
It’s not just about being simple, it’s about 1) still using transmission - because some people like decent and simple torrent clients and 2) a systemd enforced network restriction is way safer than whatever bind to interface / IP setting a program might come up with.
But you called it a simpler option, that’s why I’m asking
Its simpler than having to learn another torrent client or whatever, at the end of the day what I’m suggesting is adding a line to a text file with the interface.
So simpler if you already use Transmission? Okay I get it now.
:)
I disagree that it’s simpler, because most VPNs will use dynamic IPs. So any time your internet flickers or your power goes out, you’ll need to reconfigure Transmission with the new IP. Sure your method works for a kill switch. But it requires manual intervention every time it gets killed. With qBit’s interface binding, it doesn’t care what the VPN’s IP is. All it cares about is that it’s using the specific interface. So if the VPN is disconnected (and the VPN’s interface has no connection) then qBit simply thinks there’s no connection to the internet.
It doesn’t. You can specify your VPN provider range instead of a single IP and you won’t need manual intervention.
If you go the systemd route you can do it even better with RestrictNetworkInterfaces:
So I guess this is a better option than doing IP or IP range restrictions - zero manual intervention like you do in qBit. I’m so used to work with IPs instead of interfaces (because of the issues that can cause) that I even forgot about that option.
That doesn’t look like a simpler option to me…
Been using QBittorrent for longer than I can remember now. It certainly does everything I have ever wanted from it.
So, my setup might be of interest to you.
I have an OpenWRT router with an OpenVPN client on it. I use the router’s firewall rules to secure the access as needed. If I’m using the VPN, then the VPN is the only way traffic can get out, as I close the direct route via firewall.
This setup persists even after a router reboot.
To do this easily, I made a Python script that can load the OpenVPN files on the router, switch on/off the OpenVPN connection and modify the firewall accordingly.
This affects the entire network, and means I am not reliant on the torrent software or desktop VPN client playing ball.
Happy to share my script if it will be handy to you.
Ditch torrents and go to usenet
Usenet is okay but there’s some stuff I can only find on torrents
I have usenet as my primary with torrent as a backup. I get probably 80-90% hits on usenet for the most part.
Yeah, the stuff I can’t find on Usenet is usually old and very obscure. Anime, without the right usenet subs, is particularly hard to find.
What’s going on?
Much like in the attached image, OP has requested help with a specific thing and the responder has not provided any helpful information and has simply told OP to do something completely different with no further explanation.
And the person giving the correct answer got downvoted.
Nice. Will use in the future.
I use this Docker image of Transmission that has a built-in VPN configuration. That way only the torrent traffic goes over the VPN and it starts automatically.
Docker with a gluetun container. This container’s only role is to connect to my VPN provider. Any traffic I want through the VPN is set to use that container as its network. If the VPN goes down, gluetun loses connection, any container attached to gluetun can no longer access the internet.
I use a qbittorent docker container for my torrent client but you can attach whatever client you’re comfortable with, as well as any other container you prefer be on a VPN.
While qbittorent has a built in kill switch, this works for everything. No VPN means no connection, period.
That’s exactly what I have set up too. I also have gluetun tied to my Prowlarr and NZBget containers. I know Prowlarr tied to VPN may be overkill but it doesn’t hurt anything so why not?
As long as the tracker doesn’t have anything against VPNs doesn’t hurt. Nowadays not sure 🤔 but some didn’t allow VPN access on the tracker webpage and at the end except in some cases that is what Prowlarr does.
I have the same setting because some tracker only let you connect with one IP address. So I have Prowlarr and Transmission both connected via gluetun.
Haha, same. Stuck Prowlarr on there because why not? That’s the beauty of this setup. It takes no effort after gluetun is set, so no reason not to just attach anything even remotely questionable.
You don’t need to switch to another client. Apparently Transmission can be set to bind to your VPN IP by editing
settings.json:If you set those with your VPN IP and the VPN is down then Transmission won’t be able to communicate with any peers.
Another option, is to use systemd to restrict Transmission’s networking to your VPN IP. You can make an override of the default transmission daemon unit by using the following command:
Then type what you need to override:
Another systemd option, might be to restrict it to a single network interface:
Save the file and run
systemctl daemon-reloadfollowed bysystemctl restart transmission-daemon.serviceand it should be applied.This will be safer than just doing
bind-address-ipv4andbind-address-ipv6.qbittorrent > *