[Support] binhex - qBittorrentVPN


binhex

Recommended Posts

PIA Finally posted some info on NextGen port-forwarding.  There's 3 official bash scripts here that are available to be pulled via Github.  I thought folks in this thread would be interested.  Please forgive me if this has already been mentioned.

 

https://www.privateinternetaccess.com/helpdesk/kb/articles/next-generation-port-forwarding

 

 

Edited by dtctechs
grammar
Link to comment

--> post moved from DelugeVPN thread

 

On 9/22/2020 at 4:00 PM, binhex said:

looks like you have name resolution issues on your host, it cannot resolve the vpn endpoint you are trying to connect to, from your log:-

2020-09-22 15:37:38,948 DEBG 'start-script' stderr output: Error: error sending query: Could not send or receive, because of network error

you need to figure out why you cannot do name lookups, most probably firewall related, also i noted you have your network set to '--net='proxynet' i would remove that and set it back to 'bridge' as per normal and see if it connects ok then.

 

@Binhex

 

Found the problem... but need your opnion..

So what I did, made a shell connection to the running container, did a ping to bg.torguard.com --> could net resolve

Then did a ping to 89.249.73.170 (ip of bg.torguard.com) --> resolves

So since I'm using Pi-Hole as DNS server I set my Pi-Hole DNS in DNS_SERVERS and all was working... except error trying to resolve to google.com etc.

To my knowledge it needs my Pi-Hole DNS to setup the connection but once VPN is up it needs an open DNS

Then I did NAME_SERVER=pihole dns,1.1.1.1

And now all seems te be working fine.

However is there any privacy problem in setting my pihole dns as first dns?(My pihole uses unbound as resolver)

And why doesn't this happen to other developer qbittorentvpn container? Maybe somthing with the IPtables config?

 

Also on thing I don't understand, why is the torrent tcp/udp port exposed in the container? This makes no sense to me since this port is only availlable through the VPN. So only webui en privoxy port should be included in the docker or am I wrong?

Edited by Kopernikus
Link to comment
On 9/27/2020 at 1:31 AM, kslaguardia said:

Binhex, are you going to make a :test version of this docker?

im assuming you are talking in reference to the newly added support for pia next-gen right?, i wont be creating a test tagged version of this no, once im happy its working as intended it will be promoted to 'latest' and pushed out to all the images at once.

Link to comment
4 minutes ago, binhex said:

im assuming you are talking in reference to the newly added support for pia next-gen right?, i wont be creating a test tagged version of this no, once im happy its working as intended it will be promoted to 'latest' and pushed out to all the images at once.

 @Binhex Can you have a look at my question above? Thx 🙂 Also expect to do see donation for your great work ;-)

Link to comment
On 9/25/2020 at 8:50 AM, Kopernikus said:

So since I'm using Pi-Hole as DNS server I set my Pi-Hole DNS in DNS_SERVERS and all was working... except error trying to resolve to google.com etc.

OK so there are two states with DNS, firstly we require DNS in order to resolve the vpn providers remote host address (assuming its a hostname and not a ip address), this name resolution will be done by the dns set on your host and thus available to docker (NOT via NAME_SERVERS), you can use whatever name server you want at this point.

 

Once the name is resolved its stored in the hosts file in the container and name resolution over your lan is then blocked, that means things like pi hole will NOT work from that point, this is why this happens:-

 

On 9/25/2020 at 8:50 AM, Kopernikus said:

So since I'm using Pi-Hole as DNS server I set my Pi-Hole DNS in DNS_SERVERS and all was working... except error trying to resolve to google.com etc.

So when defining NAME_SERVERS you cannot use local name server, you have to use public name server, such as 1.1.1.1, 1.0.0.1 etc, the defaults should be just fine for this.

 

On 9/25/2020 at 8:50 AM, Kopernikus said:

Then I did NAME_SERVER=pihole dns,1.1.1.1

And now all seems te be working fine.

No, whats happening here is that it cannot use 'pihole dns' and thus skips to using 1.1.1.1, you cannot use a hostname as a name server, it would lead to a catch-22 situation - you need name resolution to resolve the name server that is used for name resolution, you see the problem right :-).
 

On 9/25/2020 at 8:50 AM, Kopernikus said:

However is there any privacy problem in setting my pihole dns as first dns?(My pihole uses unbound as resolver)

nope, cos its not used, see above 🙂

 

On 9/25/2020 at 8:50 AM, Kopernikus said:

Also on thing I don't understand, why is the torrent tcp/udp port exposed in the container?

because not everybody wants to use a vpn (although nearly everybody does), and in that scenario they need a port they can use for port forwarding.

Link to comment
23 minutes ago, binhex said:

 

Once the name is resolved its stored in the hosts file in the container and name resolution over your lan is then blocked, that means things like pi hole will NOT work from that point, this is why this happens:-

 

So when defining NAME_SERVERS you cannot use local name server, you have to use public name server, such as 1.1.1.1, 1.0.0.1 etc, the defaults should be just fine for this.

 

No, whats happening here is that it cannot use 'pihole dns' and thus skips to using 1.1.1.1, you cannot use a hostname as a name server, it would lead to a catch-22 situation - you need name resolution to resolve the name server that is used for name resolution, you see the problem right :-).
 

 

 

I'm not using the hostname of pihole but it's DNS so NAME_SERVERS=10.10.50.50,1.1.1.1,8.8.88

I understand your explanation however as soon as I remove the pihole dns from the name server line, the containers fails to make the VPN connection.

As stated before this does not happen to all containers who have VPN connection, with some I can leave the pihole DNS away.

Link to comment
5 minutes ago, Kopernikus said:

I understand your explanation however as soon as I remove the pihole dns from the name server line,

so just to be clear, you mean your NAME_SERVERS=1.1.1.1,8.8.8.8 and that doesnt work?.

6 minutes ago, Kopernikus said:

As stated before this does not happen to all containers who have VPN connection, with some I can leave the pihole DNS away.

most probably because not all containers are as secure as mine, i block dns on the lan for a reason - to prevent name resolution ip leakage.

Link to comment
1 minute ago, binhex said:

so just to be clear, you mean your NAME_SERVERS=1.1.1.1,8.8.8.8 and that doesnt work?.

most probably because not all containers are as secure as mine, i block dns on the lan for a reason - to prevent name resolution ip leakage.

Correct if I put NAME_SERVERS=1.1.1.1,8.8.8.8 the container can't connect to the VPN, I get unable to resolve errors

When I put NAME_SERVERS=10.10.50.50 without public the container connects to VPN but can't resolve once connection is made (seems logic)

When I put NAME_SERVERS=10.10.50.50,1.1.1.1,8.8.8.8 all is working fine without any problems

 

Also one more question, I have setup portforwarding with my VPN provider (TorGuard), do I need to specify the port somewhere in teh eniorement variables of the docker?

 

Thx

Link to comment
1 minute ago, Kopernikus said:

Correct if I put NAME_SERVERS=1.1.1.1,8.8.8.8 the container can't connect to the VPN, I get unable to resolve errors

i think you will find it probably has connected, the unable to resolve errors are part of the initialisation AFTER a vpn tunnel has been established, however that should work just fine with those ip addresses, please can you do the following:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

 

2 minutes ago, Kopernikus said:

Also one more question, I have setup portforwarding with my VPN provider (TorGuard), do I need to specify the port somewhere in teh eniorement variables of the docker?

nope, no env vars are required, you just need to configure the app with the port assigned to you, thats it.

Link to comment
10 minutes ago, binhex said:

i think you will find it probably has connected, the unable to resolve errors are part of the initialisation AFTER a vpn tunnel has been established, however that should work just fine with those ip addresses, please can you do the following:-

https://github.com/binhex/documentation/blob/master/docker/faq/help.md

 

nope, no env vars are required, you just need to configure the app with the port assigned to you, thats it.

Don't now what changed but seems to be working now with:

NAME_SERVERS=1.1.1.1,8.8.8.8

 

Tried 100000x..... sorry

 

  • Like 1
Link to comment
12 minutes ago, Kopernikus said:

Don't now what changed but seems to be working now with:

NAME_SERVERS=1.1.1.1,8.8.8.8

 

Tried 100000x..... sorry

 

then i can only assume either your vpn provider had issues and was blocking access to port 53 or all ports perhaps and its now working correctly, or the name server you had first in the list was having issues which have now been resolved.

Link to comment
1 hour ago, TexasUnraid said:

I didn't have any issues, just entered the ip and port then the user name and password for the webui and everything just worked.

hmm so looks like if you use custom bridge network Sonarr and Radarr cannot connect to QBittorrent. 

only via Provoxy can they connect to it. if you disable proxy it stops.

Anyone know how to fix it so that custom bridge network works without using proxy?

Edited by nekromantik
Link to comment

Question........I'm currently having random reboots of my unRaid server (that is a different issue) but because of it, I'm having all kinds of issues with QBittorrent resetting the paths for downloads under the Options. Not only that, I'm, finding QBittorrent is automatically moving all the files it has downloaded or is downloading (incompletes) on to my cache drive. The first time it happened it took me forever to figure out it was QBittorrent spooling stuff to the cache (400GB+ of stuff). Today when it happened, after the reboot and the docker started up, the files from my array started moving to the cache. Granted, IF it was moving the files to the cache with the exact same structure as on the array, I'd be good. But in this case, it appears to be wiping out the options I set for folders in QBittorrent under options, setting it to the defaults and then moving everything over/around which is completely forcing me to do a ton of clean-up and restart over a whole bunch of downloads. 

 

Is there something I should do with the QBittorrent docker to make sure the settings don't reset to defaults if a reboot occurs? I haven't seen this issue with a simple docker restart.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.