Force Proxy Use causing VPN issue

[gsdsam]

My VPN client (Mullvad version 2023.4) refuses to connect when I have 'force proxy use' with a SOCKS5 proxy enabled. I spoke to mullvad, but they basically wiped their hands of it, suggesting I use their lockdown mode or qbittorrent instead.

I would however like to continue using Deluge and would like to start using a proxy within the client to restrict torrent traffic to flow via my VPN.

If my VPN is not connected and Deluge is open with the force proxy use option enabled, my VPN fails to connect, stating the below;



I, of course, checked without my AV enabled and the issue persisted.

The settings I am using are shown below.



I'm on Windows 10 22H2, using Mullvad 2023.4 and Deluge 2.1.1.

If this isn't relevant to Deluge please do not hesitate to let me know.

Thanks!

[ambipro]

So a few things...

Mullvad stopped supporting port forwarding months ago, you will have a handicapped torrenting experience with them, even if you set it up properly (SOCK5 is not a recommended use for VPN in any case, by the way)

For any VPN setup, using Socks5 is not recommended, and does not trigger kill-switches or fail-safes.

You will never be able to be connectable via a Socks5....at best you will not seed and potentially leak your IP. At worst, you won't be able to use torrents at all really.

I'd recommend getting a VPN with port forwarding that has software you can use to capture the entire application or systems traffic within it. This will stop the need for any extra VPN configuring in Deluge. Alternatively, if you use binhex's delugevpn container or something like gluetun (both are docker implementations) this would be good too, however, the lack of port forwarding with mullvad still applies.

I do not know why youre getting the error you're showing a screenshot. But it is telling you what the issue should be, a third-party connection/firewall software.

[gsdsam]

I do not know why youre getting the error you're showing a screenshot. But it is telling you what the issue should be, a third-party connection/firewall software.

Woops, I also forgot to mention I made explicit allow rules in Windows Firewall too with no luck.

That sucks that Mullvad isn't exactly compatible, I'll have to look into an alternative like you say.

Thank you for your time!

[mhertz]

BTW, just regarding the question specifically, then that option is deprecated in libtorrent and ignored(default functionality), so sounds strange that should be culprit, but hence can be left disabled in the two supplied libtorrent versions of the windows deluge 2.1.1 installers(as new enough for this, I.e somewhere in v1.2.x I believe, but did check deprecated in 1.2.15 src specifically).

Edit:

Actually, force_proxy was removed/deprecated and always enabled. I think this is much more in line with what people expect. If they configure a proxy, it will be used or fail. The previous default behavior of using it as best-effort, and circumvent it if it didn't work, is unintuitive (I think).

Source: https://github.com/arvidn/libtorrent/is ... -567719366

1.2 release

[...]
* deprecated force_proxy setting (when set, the proxy is always used)
[...]

Source: https://github.com/arvidn/libtorrent/bl ... /ChangeLog

Btw, rereading your post, you say with vpn disabled and deluge open(proxied), you fail connect to vpn. Don't know why that you say happens, but you need have vpn connected for this proxy system mulvad uses to work I.e you connect to socks5 server through local IP of connected vpn server, so open deluge with vpn already connected, not other way around.

[gsdsam]

Oh that at least clears up the neccessity of that option, thank you! To clarify, my intent is to set up Deluge with the proxy on the basis that it will not connect unless the Mullvad VPN client is connected e.g. Deluge opens prior to Mullvad on startup or Mullvad crashes/fails for whatever reason. Although I guess with what ambipro has said regarding using SOCKS5 for torrenting, I may need to look at an alternative proxy method.

[mhertz]

You're welcome Ambipro's opinion is valid, as usual - mine is that socks5 proxies _with_ force_proxy or as now where included regardless, is safe, and the issues reported all over(friendly letters), where without that option(also reason for a bunch these reports was from deluge 1.x. users, and only deluge 2.x got force_proxy introduced), or much earlier with bugs - Arvid cannot promise 100% safe, as with any software of-course, but no known bugs atleast, plus there are some low-level code-checks too, to make sure premise not violated etc, making the chance much smaller for bugs in implementation. Anyway, I generally don't recommend proxies neither, because as ambipro stated isn't accepting incoming connections, but as your VPN provider doesn't support it anyway, then moot point. Then there's too often still issues with trackers timing out and udp, so VPNs better imho, and you can set it up to have split tunnel and kill-switch fine yourself, and here you don't even need do that manually, if satisfied with the way done in the app. Anyway, if in deluge preferences setting either your local VPN IP into in/out binding options, or interface name, but on windows need be GUID instead, gotten from running from elevated cmd 'net start dot3svc & netsh lan show interfaces & net stop dot3svc', and then need be uppercased and in curlybrazes(can't remember if already are).

I haven't looked it up, but it could sound like mulvad uses windows firewwall rules as there kill-switch, which some others do I know, which helps with crashes, else can do manually e.g. a couple rules restricting in/out for deluge*.exe only through VPN IP subnet and not home Lan IP subnet. Also, if deluge starts before vpn, then probably will reconnect(announce) later presumably, atleast does on qbittorrent I believe when set such up for relative and tested that(1-2 min later).

Regardless choice is yours of-course, and my previous post was just for completeness e.g. also for others later finding from forum search researchng similar issue, and not because disagree with ambipro, which would be rare

[ambipro]

Regardless choice is yours of-course, and my previous post was just for completeness e.g. also for others later finding from forum search researchng similar issue, and not because disagree with ambipro, which would be rare :)

Awww <3

[mhertz]

@ambipro love back bro, and thanks my friend