10 hours ago, binhex said:

Looks like the endpoint you are specifying (via ip) is not operational any more, download a new wg0.conf from protonvpn for a different endpoint, from your log:-

readnatpmpresponseorretry() failed : the gateway does not support nat-pmp

Thank you, it did work after I replaced the wg0.conf. However a few hours later it happened again. This time I did not do anything, qbit just lost the ability to connect. 

Generating another wg0.conf helped again. I hope that this time it will continue to work.

37 minutes ago, plenty_box said:

Any ideas?  Thanks in advance.

Post your docker run command. Be sure to redact any sensitive info.

Has anyone managed to switch the webui to vuetorrent lately?

I'm getting the webui black screen error saying "Unacceptable file type, only regular file is allowed" when I try to switch.

On 11/26/2023 at 10:23 AM, nraygun said:

FWIW, I found this method in Reddit that seemed to work for me until they fix the log bug. But note if you have qbittorrent internet facing, it's a risk.

 

Adding this line under [Preferences], in the config file, works, for setting the default password manually to: adminadmin

WebUI\Password_PBKDF2="@ByteArray(ARQ77eY1NUZaQsuDHbIMCA==:0WMRkYTUWVT9wVvdDtHAjU9b3b7uB8NR1Gur2hmQCvCDpm39Q+PsJRJPaCU51dEiz+dTzh8qbPsL8WkFljQYFQ==)"

 

 

Maybe i am missing something.... I am assuming the config file is where you edit the docker, but I don't see preferences anywhere. Am I looking in the right space?

14 minutes ago, dgtlman said:

 

Maybe i am missing something.... I am assuming the config file is where you edit the docker, but I don't see preferences anywhere. Am I looking in the right space?

/mnt/user/appdata/binhex-qbittorrentvpn/qBittorent/config

 

Scroll down to [preferences].

Edited January 18, 20242 yr by wgstarks

Just now, wgstarks said:

user/appdata/binhex-qbittorrentvpn/qBittorent/config

 

Scroll down to [preferences].

This is assuming you are using the default location for appdata. If not you’ll need to adjust the path.

17 minutes ago, wgstarks said:

/mnt/user/appdata/binhex-qbittorrentvpn/qBittorent/config

 

Scroll down to [preferences].

 

16 minutes ago, wgstarks said:

This is assuming you are using the default location for appdata. If not you’ll need to adjust the path.

 

 

Ahh.... thank you so much!

 

Just in case anyone else isn't sure, once in the .../config directory, edit the qBittorrent.conf file. Add the string below to the bottom of the preferences, restart qbittorrent and then log in with adminadmin as the password. After that, you should change the password.

 

WebUI\Password_PBKDF2="@ByteArray(ARQ77eY1NUZaQsuDHbIMCA==:0WMRkYTUWVT9wVvdDtHAjU9b3b7uB8NR1Gur2hmQCvCDpm39Q+PsJRJPaCU51dEiz+dTzh8qbPsL8WkFljQYFQ==)"

 

Hi! All of a sudden I'm unable to view my UI for this docker with VPN enabled, UI access is fine with it disabled.  Had been working fine for a while.  Not sure when the issue began as I rarely check on qbit as I primarily utilize sabnzbd.

 

VPN Provider: Privado

Actions Taken:

1. Changed VPN password
2. Replaced OVPN files
3. Panicked
4. Deleted and rebuilt the docker
5. Followed the instructions here to make sure I addressed the UI port correctly.
6. Searched reddit/github/here etc to see if I could find anything specific
7. Edited the openvpn file to uncomment the section about version later than 2.5 (didn't resolve, was unsure if it'd help)
8. Attempted to read the container logs via unraid UI.
9. Found: "WARNING: file 'credentials.conf' is group or others accessible" and was unsure if it was a meaningful error
10. Followed instructions on page 1 of the thread to get logs (I even waited an extra minute)
11. Removed VPN name/pw from log.
12. Posted on here trying to add a bit of humor and jest as I'm sure you get angry people yelling at you all the time
13. ????
14. Profit?
15. supervisord.log

Edited January 18, 20242 yr by TheMarf

5 hours ago, TheMarf said:

Hi! All of a sudden I'm unable to view my UI for this docker with VPN enabled, UI access is fine with it disabled.  Had been working fine for a while.  Not sure when the issue began as I rarely check on qbit as I primarily utilize sabnzbd.

 

VPN Provider: Privado

Actions Taken:

1. Changed VPN password
2. Replaced OVPN files
3. Panicked
4. Deleted and rebuilt the docker
5. Followed the instructions here to make sure I addressed the UI port correctly.
6. Searched reddit/github/here etc to see if I could find anything specific
7. Edited the openvpn file to uncomment the section about version later than 2.5 (didn't resolve, was unsure if it'd help)
8. Attempted to read the container logs via unraid UI.
9. Found: "WARNING: file 'credentials.conf' is group or others accessible" and was unsure if it was a meaningful error
10. Followed instructions on page 1 of the thread to get logs (I even waited an extra minute)
11. Removed VPN name/pw from log.
12. Posted on here trying to add a bit of humor and jest as I'm sure you get angry people yelling at you all the time
13. ????
14. Profit?
15. supervisord.log

from your log:- 2024-01-17 22:41:00 [UNDEF] Inactivity timeout (--ping-restart), restarting

 

See Q17:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

14 hours ago, wgstarks said:

Post your docker run command. Be sure to redact any sensitive info.

Hello. thanks for replying

 

here is the command

 

docker run
  -d
  --name='binhex-qbit-doujin'
  --net='nova'
  --privileged=true
  
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Unraid"
  -e HOST_CONTAINERNAME="binhex-qbit-2"
  -e 'VPN_ENABLED'='no'
  -e 'VPN_USER'='vpn username'
  -e 'VPN_PASS'='vpn password'
  -e 'VPN_PROV'='custom'
  -e 'VPN_CLIENT'='wireguard'
  -e 'VPN_OPTIONS'=''
  -e 'STRICT_PORT_FORWARD'='no'
  -e 'ENABLE_PRIVOXY'='no'
  -e 'WEBUI_PORT'='8686'
  -e 'LAN_NETWORK'='192.168.1.0/24'
  -e 'NAME_SERVERS'='[redacted]'
  -e 'VPN_INPUT_PORTS'=''
  -e 'VPN_OUTPUT_PORTS'=''
  -e 'DEBUG'='false'
  -e 'UMASK'='000'
  -e 'PUID'='99'
  -e 'PGID'='100'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8080]/'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/qbittorrent-icon.png'
  -p '6882:6881/tcp'
  -p '6882:6881/udp'
  -p '8119:8118/tcp'
  -p '8686:8686/tcp'
  -v '/mnt/user/appdata/data':'/data':'rw'
  -v '/mnt/user/appdata/binhex-qbittorrentvpn-doujin':'/config':'rw'
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-qbittorrentvpn:4.6.0-1-01'
f9bee275571ffd175e987b363c834880e32d023f35b396e40bf3850da3d4a6f5

The command finished successfully!

Edited January 18, 20242 yr by plenty_box

Anyone know how I can change the listening port setting permanently? I changed the host port 1 and 2 settings in the template but it still reverts to the default anytime the docker restarts

2 hours ago, plenty_box said:

here is the command

I don’t see anything out of the ordinary there except for the custom network. Not sure if that might be a cause or not???

5 hours ago, binhex said:

from your log:- 2024-01-17 22:41:00 [UNDEF] Inactivity timeout (--ping-restart), restarting

 

See Q17:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Thank you. My gut said it was provider side.

 

I pulled new OVPN files last night and ran into the same, but after reading your post today I went to grab new files and lo and behold there were new servers for the locations I had been trying.  Worked like a charm.  Must have been some sort of outage over the past week or so.  Every time I tried new files it still didnt work, out of the 5 servers I tried they are all removed from the new list.  Thanks for confirming.

Hi binhex, I have google and etc and even try this before but I can't make it works except only when I change my network type to custom network. Im running unraid OS.

 

I tried to duplicate qbittorrent and I want to use 2 qbittorrent. One is for seeding and another for personal stuff. Both are connected to the same PIA VPN account and I will always get this error. Any idea how to bypass this except changing network type? I want to use jackett/autobrr/cross-seed all of them connected to both qbit docker.

 

 

On 1/17/2024 at 12:20 PM, VRA said:

Thank you, it did work after I replaced the wg0.conf. However a few hours later it happened again. This time I did not do anything, qbit just lost the ability to connect. 

Generating another wg0.conf helped again. I hope that this time it will continue to work.

I'm also trying to setup the container using protonVPN/wireguard and have yet to get the webUI working.  I generated a fresh wireguard config file from proton, ensured port forwarding was allowed, and uploaded that to the config/wireguard directory - the container accepted it and auto-renamed to wg0.conf then started up seemingly fine, however when I try to visit the WebUI I get a connection timeout error.  I was reading this guide from Proton and when I get to the part about verifying that port forwarding (natpmpc) is allowed I get a -7 Failed response for readnatpmpresponseorretry - I don't see why it would fail though since I just created the config file with the option toggled.

supervisord.log

10 hours ago, krazytaco said:

I'm also trying to setup the container using protonVPN/wireguard and have yet to get the webUI working.  I generated a fresh wireguard config file from proton, ensured port forwarding was allowed, and uploaded that to the config/wireguard directory - the container accepted it and auto-renamed to wg0.conf then started up seemingly fine, however when I try to visit the WebUI I get a connection timeout error.  I was reading this guide from Proton and when I get to the part about verifying that port forwarding (natpmpc) is allowed I get a -7 Failed response for readnatpmpresponseorretry - I don't see why it would fail though since I just created the config file with the option toggled.

supervisord.log 29.14 kB · 1 download

from your log file:- [info] ProtonVPN username 'vpn username' does not contain the suffix '+pmp' and therefore is not enabled for port forwarding, skipping port forward assignment...

 

follow Q31:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

hi,

 

I have vpn disabled

 

but when i load the qbit gui and login i get qBittorrent client is not reachable

 

so not able to go into settings.

 

Please help 

@binhex this might be noob questions, but I am confused still about the NAME_SERVERS variable. From what I understand, the first step is resolving the VPN Provider's remote gateway, which uses the DNS on your host (which the docker also have available to it) and that this can be any Public DNS Server (in my case I am using Quad9 on my host). So now I am wondering what NAME_SERVERS is for.

 

Is this the DNS servers to resolve for anything after the VPN tunnel has formed?

If so, why do we need to even specify DNS servers, wouldn't we want to be using the VPN providers DNS servers and not manually specifying DNS to avoid leakage?

 

I am only asking because when I visit IPleak.net on a firefox container that I have routed through your qbittorrent vpn container, I do see my VPN Public IP address, but the DNS servers are listed as Cloudflare (which I currently have 1.1.1.1 configured as NAME_SERVERS because I skimmed through the template setup and didn't bother to change). I just kind of expected to see that I would be using my VPN providers DNS servers over the tunnel as I have always been told its best for security so you don't split DNS outside of the tunnel accidentally. 

 

 

On 1/21/2024 at 10:28 PM, nickydd9 said:

From what I understand, the first step is resolving the VPN Provider's remote gateway, which uses the DNS on your host

Incorrect, it uses the name servers defined for NAME_SERVERS, it does not use whatever your host is using.

On 1/21/2024 at 10:28 PM, nickydd9 said:

So now I am wondering what NAME_SERVERS is for.

To resolve the vpn endpoint (if its a name) and to do all name resolution for the application e.g. resolving peers/seeds from name to ip (if talking about a torrent client).

 

On 1/21/2024 at 10:28 PM, nickydd9 said:

Is this the DNS servers to resolve for anything after the VPN tunnel has formed?

Before AND after the tunnel is connected, but once connected all future name server lookup is restricted to vpn tunnel only, if the tunnel goes down then name server lookup for the endpoint is done via cached lookups in the form of hosts file.

 

On 1/21/2024 at 10:28 PM, nickydd9 said:

 wouldn't we want to be using the VPN providers DNS servers and not manually specifying DNS to avoid leakage?

Not all vpn providers provide name servers to use, and even if they do not all vpn name servers are publicly accessible, so name resolution for the vpn endpoint (prior to being connected to the vpn) would be blocked resulting in the inability to establish a connection.

 

On 1/21/2024 at 10:28 PM, nickydd9 said:

I am only asking because when I visit IPleak.net on a firefox container that I have routed through your qbittorrent vpn container, I do see my VPN Public IP address, but the DNS servers are listed as Cloudflare (which I currently have 1.1.1.1 configured as NAME_SERVERS because I skimmed through the template setup and didn't bother to change). I just kind of expected to see that I would be using my VPN providers DNS servers over the tunnel as I have always been told its best for security so you don't split DNS outside of the tunnel accidentally. 

Firstly lets correctly define what name server ip leakage really is, this is leaking your ISP assigned ip via name server lookup, this cannot happen with this image, as mentioned above name server lookup is restricted to vpn tunnel only once connected, in the above scenario firefox will be using a public name server (1.1.1.1) but the requests will be coming from your vpn provider ip address and will not be from your isp assigned ip address, thus no leak.

For anybody else reading this, please keep in mind that nickydd9 is using a firefox browser in a container, and thus all traffic is sent down the vpn tunnel, if you are using a browser via privoxy (proxy) then this is a different scenario and name server leakage will occur.

On 1/18/2024 at 6:33 AM, soltkr said:

Anyone know how I can change the listening port setting permanently? I changed the host port 1 and 2 settings in the template but it still reverts to the default anytime the docker restarts

I have discovered that I was fundamentally misunderstanding how the docker is set to work.  When using PIA for your vpn and if you connect to a server that has port forwarding the listening port will automatically set itself to match the port assigned by PIA.  Thanks to @binhex for making such a cool docker container.  

On 1/17/2024 at 8:20 PM, VRA said:

Thank you, it did work after I replaced the wg0.conf. However a few hours later it happened again. This time I did not do anything, qbit just lost the ability to connect. 

Generating another wg0.conf helped again. I hope that this time it will continue to work.

This has happened again
Looking at the protonVPN the config should be valid until next year. I don't really undestand why it seems to "expire" (or just stop working) after a while.

Is there something I might be doing wrong? Either on generation of them or on the configuration on unraid?

1 hour ago, VRA said:

This has happened again
Looking at the protonVPN the config should be valid until next year. I don't really undestand why it seems to "expire" (or just stop working) after a while.

Is there something I might be doing wrong? Either on generation of them or on the configuration on unraid?

i would contact ProtonVPN, this should not be happening.

Welp @binhex, never thought I'd hit a roadblock like this but here we are 2 hours of troubleshooting later.😂

 

I'm having an issue with remote access via my WireGuard server affecting only this docker container. everything works as expected on LAN including sonarr and jackett that hang off of the network on the container via -network=container:containerName.

 

on my VPN I can ping my client machine through the tunnel from the container, qbitorrent living on 8080 is accessible, but ICMP doesn't pass and sonarr and jackett are unreachable (essentially one way traffic). I've tried making a few iptables changes to allow my "192.168.2.0/24" VPN subnet through, essentially just copying what is permitted for the "192.168.1.1/24" network.

 

I'm stumped and pretty sure I just suck at iptables, any help is appreciated. 

 

docker run
  -d
  --name='binhex-qbittorrentvpn'
  --net='br0'
  --ip='192.168.1.12'
  --privileged=true
  -e TZ="America/Phoenix"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="HotBox"
  -e HOST_CONTAINERNAME="binhex-qbittorrentvpn"
  -e 'TCP_PORT_6881'='6881'
  -e 'UDP_PORT_6881'='6881'
  -e 'TCP_PORT_8080'='8080'
  -e 'TCP_PORT_8118'='8118'
  -e 'VPN_ENABLED'='yes'
  -e 'VPN_USER'='xxxxxx'
  -e 'VPN_PASS'='xxxxxx'
  -e 'VPN_PROV'='pia'
  -e 'VPN_CLIENT'='wireguard'
  -e 'VPN_OPTIONS'=''
  -e 'STRICT_PORT_FORWARD'='yes'
  -e 'ENABLE_PRIVOXY'='no'
  -e 'WEBUI_PORT'='8080'
  -e 'LAN_NETWORK'='192.168.1.0/24,192.168.2.0/24'
  -e 'NAME_SERVERS'='84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1'
  -e 'VPN_INPUT_PORTS'=''
  -e 'VPN_OUTPUT_PORTS'=''
  -e 'DEBUG'='false'
  -e 'UMASK'='000'
  -e 'PUID'='99'
  -e 'PGID'='100'
  -l net.unraid.docker.managed=dockerman
  -l net.unraid.docker.webui='http://[IP]:[PORT:8080]/'
  -l net.unraid.docker.icon='https://raw.githubusercontent.com/binhex/docker-templates/master/binhex/images/qbittorrent-icon.png'
  -v '/mnt/user/data/torrents/':'/data':'rw'
  -v '/mnt/user/appdata/binhex-qbittorrentvpn':'/config':'rw'
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-qbittorrentvpn'
f31f91700b2a9888f3b410f24e123f8bce3e9a448b13904ec73fd564b33efe99

 

Attempted IP tables fix

iptables -I INPUT 8 -s 192.168.2.0/24 -d 192.168.2.0/24 -j ACCEPT
iptables -I INPUT 22 -s 192.168.2.0/24 -d 192.168.2.0/24 -j ACCEPT
iptables -I OUTPUT 8 -s 192.168.2.0/24 -d 192.168.2.0/24 -j ACCEPT
iptables -I OUTPUT 22 -s 192.168.2.0/24 -d 192.168.2.0/24 -j ACCEPT

 

Attached supervisord.log

 

 

 

 

 

 

supervisord.log

I'm running qbittorrentvpn with free protonvpn configs. Everytime I start up the container it auto kills after connecting to the VPN. I can't even connect to the GUI...

 

text  error  warn  system  array  login  

2024-01-29 22:43:29,787 DEBG 'start-script' stdout output:
[info] iptables defined as follows...
--------------------

2024-01-29 22:43:29,788 DEBG 'start-script' stdout output:
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -s 37.19.205.202/32 -i eth0 -j ACCEPT
-A INPUT -s 37.19.205.202/32 -i eth0 -j ACCEPT
-A INPUT -s 37.19.205.202/32 -i eth0 -j ACCEPT
-A INPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A INPUT -s 37.19.205.202/32 -i eth0 -j ACCEPT
-A INPUT -s 37.19.205.202/32 -i eth0 -j ACCEPT
-A INPUT -s 37.19.205.202/32 -i eth0 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 8081 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 8081 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A OUTPUT -d 37.19.205.202/32 -o eth0 -j ACCEPT
-A OUTPUT -d 37.19.205.202/32 -o eth0 -j ACCEPT
-A OUTPUT -d 37.19.205.202/32 -o eth0 -j ACCEPT
-A OUTPUT -s 172.17.0.0/16 -d 172.17.0.0/16 -j ACCEPT
-A OUTPUT -d 37.19.205.202/32 -o eth0 -j ACCEPT
-A OUTPUT -d 37.19.205.202/32 -o eth0 -j ACCEPT
-A OUTPUT -d 37.19.205.202/32 -o eth0 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 8081 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 8081 -j ACCEPT
-A OUTPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A OUTPUT -o tun0 -j ACCEPT

2024-01-29 22:43:29,790 DEBG 'start-script' stdout output:
--------------------

2024-01-29 22:43:29,791 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2024-01-29 22:43:29,803 DEBG 'start-script' stdout output:
2024-01-29 22:43:29 WARNING: file 'credentials.conf' is group or others accessible
2024-01-29 22:43:29 OpenVPN 2.6.8 [git:makepkg/3b0d9489cc423da3+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Nov 17 2023
2024-01-29 22:43:29 library versions: OpenSSL 3.2.0 23 Nov 2023, LZO 2.10
2024-01-29 22:43:29 DCO version: N/A

2024-01-29 22:43:29,803 DEBG 'start-script' stdout output:
2024-01-29 22:43:29 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2024-01-29 22:43:29,804 DEBG 'start-script' stdout output:
2024-01-29 22:43:29 TCP/UDP: Preserving recently used remote address: [AF_INET]37.19.205.202:443

2024-01-29 22:43:29,804 DEBG 'start-script' stdout output:
2024-01-29 22:43:29 Attempting to establish TCP connection with [AF_INET]37.19.205.202:443

2024-01-29 22:43:29,977 DEBG 'start-script' stdout output:
2024-01-29 22:43:29 TCP connection established with [AF_INET]37.19.205.202:443
2024-01-29 22:43:29 TCPv4_CLIENT link local: (not bound)
2024-01-29 22:43:29 TCPv4_CLIENT link remote: [AF_INET]37.19.205.202:443

2024-01-29 22:43:30,712 DEBG 'start-script' stdout output:
2024-01-29 22:43:30 [node-jp-28.protonvpn.net] Peer Connection Initiated with [AF_INET]37.19.205.202:443

2024-01-29 22:43:36,353 DEBG 'start-script' stdout output:
2024-01-29 22:43:36 TUN/TAP device tun0 opened
2024-01-29 22:43:36 net_iface_mtu_set: mtu 1500 for tun0
2024-01-29 22:43:36 net_iface_up: set tun0 up

2024-01-29 22:43:36,353 DEBG 'start-script' stdout output:
2024-01-29 22:43:36 net_addr_v4_add: 10.98.0.28/16 dev tun0
2024-01-29 22:43:36 /root/openvpnup.sh tun0 1500 0 10.98.0.28 255.255.0.0 init

2024-01-29 22:43:36,356 DEBG 'start-script' stdout output:
2024-01-29 22:43:36 Initialization Sequence Completed

2024-01-29 22:43:53,576 DEBG 'start-script' stdout output:
[info] Attempting to get external IP using 'http://checkip.amazonaws.com'...

2024-01-29 22:44:02,597 DEBG 'start-script' stdout output:
[info] Successfully retrieved external IP address 37.19.205.204

2024-01-29 22:44:02,599 DEBG 'start-script' stdout output:
[info] Script started to assign incoming port for 'protonvpn'

2024-01-29 22:44:04,626 DEBG 'start-script' stdout output:
[info] ProtonVPN username 'MY_PROTON_USERNAME_REDACTED' does not contain the suffix '+pmp' and therefore is not enabled for port forwarding, skipping port forward assignment...
[info] Script finished to assign incoming port

2024-01-29 22:44:04,627 DEBG 'start-script' stdout output:
kill: usage: kill [-s sigspec | -n signum | -sigspec] pid | jobspec ... or kill -l [sigspec]

5 hours ago, benjipewpew said:

ProtonVPN username 'MY_PROTON_USERNAME_REDACTED' does not contain the suffix '+pmp' and therefore is not enabled for port forwarding, skipping port forward assignment...

you have set STRICT_PORT_FORWARD to 'yes' and yet you have not added the suffix for the username as shown in the log, either set STRICT_PORT_FORWARD to 'no' or fix the username.