Bug or 'feature'? - SOCKS5 failure leaks real WAN IP

[Rainmaker]

I have a paid SOCKS5 proxy entered into qBittorrent v3.1.8 on Windows 8.1 x64. Today the proxy seems to be having issues and is refusing connections. Under any such circumstances I'd expect qBittorrent (or any app) to refuse to connect to any tracker or peer until the proxy was available to handle the traffic. Basically I expect it to bind all traffic to the proxy. Unfortunately, with the Execution Log open it is apparent that when the proxy refuses connections, qBittorrent routes traffic through the normal internet instead and my real WAN IP address is displayed in the log.

Can anyone please confirm whether this is a bug or a feature? If it's not considered a bug I'm going to have to move back over to Deluge or similar, as that's a pretty fatal security flaw from my perspective.
Thanks very much in advance.

[ciaobaby]

when the proxy refuses connections,

Tools -> Options ->Advanced -> Set the preferred network interface

[Rainmaker]

when the proxy refuses connections,

Tools -> Options ->Advanced -> Set the preferred network interface

That works for a VPN TAP or TUN adapter (for example) but a SOCKS5 proxy doesn't have a dedicated interface to bind to, it's a remote address not a local adapter. So unfortunatley that's not an option. Thanks for the reply though.

[ciaobaby]

Ok, so you're specifying the proxy in qBT only, rather than using a system proxy. Which means that qBT is simply reporting the IP of the network interface as it starts up rather than routing traffic through it.

Use http://torguard.net/checkmytorrentipaddress.php or http://checkmytorrentip.com/ to check what IP is being reported to peers and trackers.

[Rainmaker]

[quote="ciaobaby"]
Ok, so you're specifying the proxy in qBT only, rather than using a system proxy. Which means that qBT is simply reporting the IP of the network interface as it starts up rather than routing traffic through it.

Use http://torguard.net/checkmytorrentipaddress.php or http://checkmytorrentip.com/ to check what IP is being reported to peers and trackers.
[/quote]

Unfortunately that's not the case. The log usually reports the proxy IP (109.xxx.xxx.xxx) but with the proxy down it reports my true LAN IP (77.xxx.xxx.xxx) and proceeded to download torrents over the unsecured connection. I jumped in and cancelled PDQ but the point remains that for the proxy setting to have any value, it has to send traffic through the proxy ONLY; defaulting to a fail if the proxy doesn't accept the connections rather than jumping to the ISP WAN instead.

[Rainmaker]

Can any admin/devs please let me know whether this is a bug or a 'feature'? I've been on Deluge 1.3.6 since I found out qBittorrent behaves this way, but I'd like to come back if I can! Thanks.

[sledgehammer_999]

Try enabling anonymous mode under Options->Bittorrent
It seems that this is the suitable choice when under proxy or i2p.
(under vpn or normal connections this will create problems)

[zdawi]

I just noticed I have the same problem when using a socks5 proxy.
If for example I type in the wrong password, trackers won't connect but the download will still go through by using DHT and PEX.
I tried anonymous mode and it still went through with PEX.
I tested with different versions of qBittorrent and found that a very old version 2.8.5 did not let any data through so maybe a bug with the latest libtorrent?

If there's any more info you need, let me know.

[sledgehammer_999]

Open a bug at https://code.google.com/p/libtorrent/issues/list and say that proxy+anonymous mode doesn't disable PEX. Then post a link to it here too.