[PROBLEM] qbt can expose DSL-IP, although VPN is used

[coolio2013]

Please provide the following information

qBittorrent version and Operating System

v4.1.3, Windows 32bit (not relevant)

What is the problem

For some reason, qbt detects my DSL-IP (xx.xxx.14.36) in the short time-period while e.g. router/gateway/modem boots up and the VPN has not been established and the killswitch of the firewall is not yet active.
Then qbt detects the VPN-IP (xxx.xxx.203.14) a short while later (1 or 3.5 minutes).
It can happen that the DSL-IP is published to trackers or peers. This should never happen.

(The DSL-IP sometimes is visible in peer-list of a torrent; I also have seen that the DSL-IP and VPN-IP both are in the peer-list at the same time! Showing any own IP in the peer-list is also a bug; not serious, but it exposes the problem and pointed me to it.)

LOG:
(I) 2018-10-07T14:39:55 - External IP: xx.xxx.14.36
(I) 2018-10-07T14:42:05 - External IP: xxx.xxx.203.14
(I) 2018-10-07T14:44:59 - External IP: xx.xxx.14.36
(W) 2018-10-07T14:45:03 - Failed to download RSS feed at '...'. Reason: The remote host name was not found (invalid hostname)
(I) 2018-10-07T14:48:34 - External IP: xxx.xxx.203.14

What is the expected behavior

Don't expose the DSL-IP. I do not know how this could be done,

Steps to reproduce

Might be difficult.

Extra info (if any)

The VPN-provider can't publish my DSL-IP. Also I am quite sure that the killswitch of the firewall in my router works in general.
I could NEVER see the DSL-IP using pingplotter or wtfismyip.com, while router/gateway/modem boots up or VPN-connection is (re-)established. But qbt detects it and publishes it. And this is a major issue for me.

Apologies if this has been reported before, I've searched issues.

[FliessendWasser]

Is UPnP/NAT-PMP port forwarding enabled in your qBittorrent's settings?

[coolio2013]

@FliessendWasser: Yes. It always was. I know there are concerns regarding security, but from a different perspective. Ports are closed and UPnP is disabled on my DSL router, also canyouseeme reports that port is closed.
Disabling UPnP/NAT forwarding doesn't seem to change anything (at least for the connection): with different port and disabling UPnP/NAT the status of connection becomes green again 2 min after 'Apply' in settings with same number of nodes. I'll leave it disabled for now.

[ghost]

There is nothing QB can do if it is active prior the VPN with related kill switch are in play, not sure how it is expected otherwise. Just make sure that QB starts only after VPN with related kill switch are in play.

Rather fail-safe is the socks5 proxy feature anyway, lots of VPN provide such gateways, plus the https://github.com/qbittorrent/qBittorrent/wiki/Anonymous-Mode

This is not really a code issue or sort of bug and perhaps better perused in the qbit forum

[zinemaniac]

I use Comodo(there might be other firewalls but i haven't seen any that do the same) to block my p2p clients from using my standard internet connection by blocking all them from all communication except by a network zone for my vpn that i create with ip addresses used by the vpn provider. Then your p2p client can't communicate with anything except your vpn.

[RoestVrijStaal]

Are you sure you did not run qBittorrent BEFORE initiating a VPN connection? Because at startup qBittorrent probes the trackers, which obviously contains your real IP-address since the VPN connection isn't initiated.

Make also sure you've emptied the cache of DHT, PEX and Local Peer Discovery, since your IP-addresses would be in those as well.

Setting "Networkinterface (restart required)" and "Optional IP-address to bind to (restart required)" on the one's of the VPN would do the trick. According to the docs, there is no need to listen to other interfaces. (if they behave like what's written in the docs).

But after testing with TCPView and ProcessExplorer, I discovered qBittorrent 4.1.6 still listens on those interfaces with their respective local address. Even when "Listen to IPv6-address" is toggled off.

Adding a HTTP proxy wipes those unwanted interfaces away. However, upon restart they appear again.

Anyway, it's related to #5272

[FranciscoPombal]

Network interface settings were probably not correctly configured when this was posted, but it's not relevant anymore in the libtorrent >= 1.2.x world anyway, since there have been many changes how network interfaces are handled. Currently, it's known to work correctly if the network interface settings are set correctly in qBittorrent's advanced settings.

If you have any issues with the latest version, please open a new issue report.