starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

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

New issue

Closed

opened 2026-02-21 19:13:18 -05:00 by deekerman · 6 comments

deekerman commented

2026-02-21 19:13:18 -05:00

Owner

Originally created by @coolio2013 on GitHub (Oct 7, 2018).

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.

Originally created by @coolio2013 on GitHub (Oct 7, 2018). **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.

deekerman

2026-02-21 19:13:18 -05:00

closed this issue
added the
Network
label

deekerman commented

2026-02-21 19:13:25 -05:00

Author

Owner

@FliessendWasser commented on GitHub (Oct 8, 2018):

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

@FliessendWasser commented on GitHub (Oct 8, 2018): Is UPnP/NAT-PMP port forwarding enabled in your qBittorrent's settings?

deekerman commented

2026-02-21 19:13:25 -05:00

Author

Owner

@coolio2013 commented on GitHub (Oct 9, 2018):

@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.

@coolio2013 commented on GitHub (Oct 9, 2018): @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.

deekerman commented

2026-02-21 19:13:25 -05:00

Author

Owner

@ghost commented on GitHub (Oct 9, 2018):

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

@ghost commented on GitHub (Oct 9, 2018): 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

deekerman commented

2026-02-21 19:13:25 -05:00

Author

Owner

@zinemaniac commented on GitHub (Oct 10, 2018):

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.

@zinemaniac commented on GitHub (Oct 10, 2018): 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.

deekerman commented

2026-02-21 19:13:25 -05:00

Author

Owner

@RoestVrijStaal commented on GitHub (Jun 26, 2019):

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

@RoestVrijStaal commented on GitHub (Jun 26, 2019): 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

deekerman commented

2026-02-21 19:13:25 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Sep 14, 2020):

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.

@FranciscoPombal commented on GitHub (Sep 14, 2020): 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.