-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Magnetic links not processed by qBittorrent while WS firewall is on #96
Comments
Hi. Please give our latest guinea pig build a try. Some other qBittorrent issues were fixed, so hopefully this build will rectify your issue as well. https://deploy.totallyacdn.com/desktop-apps/2.7.9/Windscribe_2.7.9_guinea_pig.exe |
Any update on this please? |
Hi. Our QA team is unable to replicate this issue. Can you send us a sanitized copy of your custom ovpn config so we can see if there are any settings you are using that we did not account for? |
As an updated, I have just installed the latest guinea_pig v2.7.11. I can confirm the list of trackers is translated (see this in the tracker list) and I have tried manually the tracker domain does get resolved to an IP. However even waiting long time no seeds or peers appear; it does have them! as the download starts as soon as I remove the firewall. So the issue must be somewhere else. my qBittorent doesn't have any interface binding and relies on both TCP and UTP. As requested please see below the relevant parts of my .ovpn. I have just removed the remote FQDN and the keys/certificates proto udp |
Say I'm in this position:
From this position I only disable the firewall via the dedicated button on the WS interface. Count 30sec and the peers/seeds start to appear and everything works as expected. |
@wellloaded, The configuration file pulls additional configuration from the server, it's not possible to tell what could be wrong. I'm not sure regarding the configuration of both server and client in this case.
For the second, you need to replace You can either upload the log here (if it doesn't contain information which you might consider sensitive) or send it to https://windscribe.net/contact-support with the URL of this issue. |
I can confirm 10.10.0.0/16 is my local (intra site VPN) and should have no importance in this issue. Reading your answer I'm not sure why you refer to DNS, may be it's me but I don't have the feeling this to be a resolution issue. I'll follow up on the verbosity and run some more test but for the time being I can add that the Split tunneling is exclusive for:
As a side test (I can open an apart issue for this if required) I have tried to specify "Windscribe" in the "qBittorrent/Options/Advanced/Network Interface" but this appears to completely brake all the torrenting traffic with or without firewall. so I has to revert to "Any Interface". Strange. |
The verb 4 log can be found here below: Please note:
|
I've asked our resident OpenVPN custom config expert (windscribe-eva-01) to have a look at the new logs. |
Everything suggests for this NOT to be a qBittorent/magnetic link issue but rather a parent issue as described on issue #127 related to the firewall in general. |
So to recap on this: this is NOT relevant (as I understand) to split tunneling as initially thought. The teamviewer issue was resolved in a different way #127 Going back to the magnet link issue as a reminder a magnet will get sucked into qBittorrent and stay in its hash format forever or until I disable the firewall. So disabling the firewall transforms the hash into a proper torrent and I can see filenames/peers etc. Unless I'm missing something this specific issue might be related to some sort of DNS resolution or something. I did mention above that I use my own router DNS (FreshTomato) that runs for me Stubby and DNSCRYPT so here my relevant DNS's WS config: 10.10.10.0/24 is my local subnet |
@wellloaded,
With such configuration, qBitTorrent v4.5.5 doesn't have any issue with either contacting torrent announcer URLs, connecting to DHT and receive magnet links, or downloading the torrents, in both all-interface and WindscribeOpenVPN interfaces selected. Please clarify whether you have:
Just out of blue: are you sure you use VPN which doesn't block DHT communications? |
Firstly, indeed this is not WS related Secondly, I still think you/we should be aware of this, and perhaps report on similar cases. To get something out of this and all the time we both put into this issue, can I suggest you add a little control/report with the WS Client that could help troubleshooting these cases? Essentially getting out of the system what is the DNS server in use regardless of the WS settings could help shortening the troubleshooting time. Thirdly, I also found that Firefox re-enabled (mine despite) DoH, so I have disabled that as well. |
This comment was marked as off-topic.
This comment was marked as off-topic.
Yes. When you configure custom DNS in Windscribe client with Robert enabled, local ctrld instance is launched and configured to your upstream DNS, while your system is configured to this local instance. Can't answer two other questions, need to check it. |
Thanks! This is where I am at the moment:
Now... as I have uninstalled crytpmator I can only assume there's a link left behin from 127.0.0.1 to cryptomator-vault but yes ultimately 127.0.0.1 is always my default server when connected to Wireguard. If this is correct I can confirm that unfortunately the issue still persists despite me changing Firefox DoH to off and removing cryptomator. |
As a matter of facts cryptomator is not part of any of this any more a soon as I manually removed the references to it in the host (only leftover):
So actually this was only an alias. Still the DNS resolution is an issue here :-/ |
I don't have R.O.B.E.R.T. enabled though |
netstat -a -b confirms this: ctrld.exe is listening on port 53 This tells me two things:
|
(parenthesis) A suggestion for Windscribe: Could you create a very simple flowchart (within WS client) that clearly display what components are involved (enabled) in the DNS resolution and whish one is working or not? E.g. a block called DNS client that goes into CTRLD but CTRLD is for whatever reason not running or unable to communicate could have this second box color in red or something. This is irrelevant of my issue here but in general a good idea to provide some sort of advanced troubleshooting when it comes to name resolution. Thanks |
Very importantly I picked up one random tracker FQDN and performed an nslookup directly on the router and I can confirm this is resolvable:
So everything suggests CTRLD is playing a part here. |
|
I did as suggested. As far as I can tell in both scenarios (Firewall on and Firewall off) only the LAN dns filter is visible. The Windscribe VPN doesn't appear to handle any traffic. This said, I was not expecting any VPN traffic on the VPN. Now... I'm starting to wonder if this is an issue with qBittorrent instead? There's an option in the preference/Advanced/Network Interface that allows you to specify the interface the program should be operating over. This historically (I remember Yegor comment on this long time ago) has apparently it never worked with Windscribe (as in setting Windscribe a the binding interface). That said.... default is "any" and I'm now worried it might use my LAN interface so I will perform some additional sniffing. |
I am connected to the custom .ovpn.
Now, same test but using internal Windscribe hosts (best location)
In both cases I do see the double reference:
however there's a little difference. .ovpn uses metric 15 for them where built in VPN uses metric 5. Is it possible that you have an issue with tunnel redirection on custom .ovpn? |
Tested on my laptop as well. When connected to .ovpn this also applies!
the route metric in this case is 56 |
Please share |
@wellloaded, are you on Windscribe's discord? Maybe we could debug this live. |
Disconnected:
Connected
|
Sorry no I'm not on discord... |
I think I have found the solution to this issue. In qBittorent for some reason I had the binding to the "WIndscribeWireGuard" interface setting this to any (and leaving the WS firewall on always on) fixed the issue. Now, you might want an FAQ reference on this one. That said... all good folks! |
Using an external .ovpn file. As per title this might mean two potential things to me:
1 - if I disable WS's firewall they might be processed via plain Internet
2 - This is meant to be (but unwanted from my perspective at least)
So currently I can add magnets but I need to stop the firewall just to make the translation between hash and torrent info, then manually re-enable the WS firewall to protect the download but I guess at that point my security level is already compromised.
I did try to fiddle with the internal windows firewall but this appears not to be relevant. Also qB is set to use any interface (binding to VPN has always created issues to me so I prefer to avoid this).
The text was updated successfully, but these errors were encountered: