Having a weird issue when launching the container. Have not changed anything within the container or docker image aside from updating image from time to time. Last I ran it (some weeks ago) it worked fine.

Found in the log that its struggling with creating a tun0 interface, but not sure why. I will mention that I sometimes run the container while running NordVPN on the host. I tested turning that off, but the issue remained.

Perhaps somebody here knows what can be done about this or where to start to troubleshoot.

Here is the log

 

2024-11-01 20:47:37,861 DEBG 'start-script' stdout output:
default via 172.19.0.1 dev eth0
172.19.0.0/16 dev eth0 proto kernel scope link src 172.19.0.2
192.168.56.0/24 via 172.19.0.1 dev eth0

2024-11-01 20:47:37,861 DEBG 'start-script' stdout output:
local 127.0.0.0/8 dev lo table local proto kernel scope host src 127.0.0.1
local 127.0.0.1 dev lo table local proto kernel scope host src 127.0.0.1
broadcast 127.255.255.255 dev lo table local proto kernel scope link src 127.0.0.1
local 172.19.0.2 dev eth0 table local proto kernel scope host src 172.19.0.2
broadcast 172.19.255.255 dev eth0 table local proto kernel scope link src 172.19.0.2
local ::1 dev lo table local proto kernel metric 0 pref medium

2024-11-01 20:47:37,861 DEBG 'start-script' stdout output:
--------------------

2024-11-01 20:47:37,897 DEBG 'start-script' stdout output:
[info] iptables defined as follows...
--------------------

2024-11-01 20:47:37,898 DEBG 'start-script' stdout output:
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -s 95.174.66.27/32 -i eth0 -j ACCEPT
-A INPUT -s 172.19.0.0/16 -d 172.19.0.0/16 -j ACCEPT
-A INPUT -s 95.174.66.27/32 -i eth0 -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 1337 -j ACCEPT
-A INPUT -i eth0 -p udp -m udp --dport 1337 -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 95.174.66.27/32 -o eth0 -j ACCEPT
-A OUTPUT -s 172.19.0.0/16 -d 172.19.0.0/16 -j ACCEPT
-A OUTPUT -d 95.174.66.27/32 -o eth0 -j ACCEPT
-A OUTPUT -o eth0 -p tcp -m tcp --sport 1337 -j ACCEPT
-A OUTPUT -o eth0 -p udp -m udp --sport 1337 -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-11-01 20:47:37,899 DEBG 'start-script' stdout output:
--------------------

2024-11-01 20:47:37,899 DEBG 'start-script' stdout output:
[info] Starting OpenVPN (non daemonised)...

2024-11-01 20:47:37,904 DEBG 'start-script' stdout output:
2024-11-01 20:47:37 DEPRECATED OPTION: --cipher set to 'AES-256-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.

2024-11-01 20:47:37,904 DEBG 'start-script' stdout output:
2024-11-01 20:47:37 Note: '--allow-compression' is not set to 'no', disabling data channel offload.
2024-11-01 20:47:37 WARNING: file 'credentials.conf' is group or others accessible
2024-11-01 20:47:37 OpenVPN 2.6.12 [git:makepkg/038a94bae57a446c+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Jul 18 2024
2024-11-01 20:47:37 library versions: OpenSSL 3.4.0 22 Oct 2024, LZO 2.10
2024-11-01 20:47:37 DCO version: N/A

2024-11-01 20:47:37,904 DEBG 'start-script' stdout output:
2024-11-01 20:47:37 WARNING: --ping should normally be used with --ping-restart or --ping-exit
2024-11-01 20:47:37 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2024-11-01 20:47:37 NOTE: --fast-io is disabled since we are not using UDP

2024-11-01 20:47:37,905 DEBG 'start-script' stdout output:
2024-11-01 20:47:37 TCP/UDP: Preserving recently used remote address: [AF_INET]95.174.66.27:443

2024-11-01 20:47:37,905 DEBG 'start-script' stdout output:
2024-11-01 20:47:37 Socket Buffers: R=[131072->131072] S=[16384->16384]
2024-11-01 20:47:37 Attempting to establish TCP connection with [AF_INET]95.174.66.27:443

2024-11-01 20:47:37,953 DEBG 'start-script' stdout output:
2024-11-01 20:47:37 TCP connection established with [AF_INET]95.174.66.27:443
2024-11-01 20:47:37 TCPv4_CLIENT link local: (not bound)
2024-11-01 20:47:37 TCPv4_CLIENT link remote: [AF_INET]95.174.66.27:443

2024-11-01 20:47:38,048 DEBG 'start-script' stdout output:
2024-11-01 20:47:38 TLS: Initial packet from [AF_INET]95.174.66.27:443, sid=2a172d4e 79aebbe9

2024-11-01 20:47:38,196 DEBG 'start-script' stdout output:
2024-11-01 20:47:38 VERIFY OK: depth=2, C=PA, O=NordVPN, CN=NordVPN Root CA

2024-11-01 20:47:38,196 DEBG 'start-script' stdout output:
2024-11-01 20:47:38 VERIFY OK: depth=1, O=NordVPN, CN=NordVPN CA9

2024-11-01 20:47:38,196 DEBG 'start-script' stdout output:
2024-11-01 20:47:38 VERIFY KU OK
2024-11-01 20:47:38 Validating certificate extended key usage
2024-11-01 20:47:38 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication

2024-11-01 20:47:38,196 DEBG 'start-script' stdout output:
2024-11-01 20:47:38 VERIFY EKU OK
2024-11-01 20:47:38 VERIFY X509NAME OK: CN=no149.nordvpn.com
2024-11-01 20:47:38 VERIFY OK: depth=0, CN=no149.nordvpn.com

2024-11-01 20:47:38,376 DEBG 'start-script' stdout output:
2024-11-01 20:47:38 Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 4096 bits RSA, signature: RSA-SHA512, peer temporary key: 253 bits X25519
2024-11-01 20:47:38 [no149.nordvpn.com] Peer Connection Initiated with [AF_INET]95.174.66.27:443
2024-11-01 20:47:38 TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1

2024-11-01 20:47:38,376 DEBG 'start-script' stdout output:
2024-11-01 20:47:38 TLS: tls_multi_process: initial untrusted session promoted to trusted

2024-11-01 20:47:38,508 DEBG 'start-script' stdout output:
2024-11-01 20:47:38 PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 103.86.96.100,dhcp-option DNS 103.86.99.100,explicit-exit-notify,comp-lzo no,route-gateway 10.100.0.1,topology subnet,ping 60,ping-restart 180,ifconfig 10.100.0.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'

2024-11-01 20:47:38,508 DEBG 'start-script' stdout output:
2024-11-01 20:47:38 OPTIONS IMPORT: --explicit-exit-notify can only be used with --proto udp
2024-11-01 20:47:38 OPTIONS IMPORT: --ifconfig/up options modified
2024-11-01 20:47:38 OPTIONS IMPORT: route options modified
2024-11-01 20:47:38 OPTIONS IMPORT: route-related options modified
2024-11-01 20:47:38 OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
2024-11-01 20:47:38 net_route_v4_best_gw query: dst 0.0.0.0
2024-11-01 20:47:38 net_route_v4_best_gw result: via 172.19.0.1 dev eth0
2024-11-01 20:47:38 ROUTE_GATEWAY 172.19.0.1/255.255.0.0 IFACE=eth0 HWADDR=02:42:ac:13:00:02
2024-11-01 20:47:38 ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted (errno=1)
2024-11-01 20:47:38 Exiting due to fatal error

Appreciate any input.

On 11/1/2024 at 8:00 PM, klavinsd said:

ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted (errno=1)

That is the issue in a nutshell, Please see Q23 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

I can't get a second instance of the docker to work on unRAID.

Since I am already running one instance of this docker, the new one would have conflicting port numbers.  

 

I decided to add a "1" in front of all of them since they are available. I added the same LAN_NETWORK subnets that are on my other one. I am using AirVPN, if that matters.

I followed this guide (Q4); at least, I think I did it correctly.

 

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

 

I removed "Port Web Interface"

I changed "Variable: WEBUI_PORT:" to 18080

 

I added a port Container:18080 Host: 18080

 

I applied everything, put in the VPN info, and it started the docker. There are a couple of problems.

 

1. When you go under the icon on the docker page and hover over the "WebUI" the link is still to 8080

 

2. When I manually type IP:18080 in the browser, it goes to the login page. I use the default admin/pw, which shows me the qbittorrent screen.  It immediately says "qbittorrent client is not reachable" on the bottom left.  If go to the menu and select "about" and it gives a popup error window with "n".  Any other menu selection I get the same error.

One thing I did notice is this line when it created the docker.

 

  -l net.unraid.docker.webui='http://[IP]:[PORT:8080]'

 

I'm not sure where it is getting that 8080 from, but I am betting wherever this is happening is the source of my issue.  
  
I'm not sure what else to try. This is with the latest version (5.0.1) as of today and unRAID version 6.12.13.
 

 

docker run
  -d
  --name='binhex-qbittorrentvpn-test'
  --net='bridge'
  --pids-limit 2048
  --privileged=true
  -e TZ="America/New_York"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="ByteBunker"
  -e HOST_CONTAINERNAME="binhex-qbittorrentvpn-test"
  -e 'VPN_ENABLED'='yes'
  -e 'VPN_USER'='[REMOVED]'
  -e 'VPN_PASS'='[REMOVED]'
  -e 'VPN_PROV'='airvpn'
  -e 'VPN_CLIENT'='openvpn'
  -e 'STRICT_PORT_FORWARD'='yes'
  -e 'ENABLE_PRIVOXY'='no'
  -e 'ENABLE_SOCKS'='no'
  -e 'SOCKS_USER'='admin'
  -e 'SOCKS_PASS'='socks'
  -e 'LAN_NETWORK'='192.168.1.0/24,192.168.254.0/24,198.18.3.0/24'
  -e 'WEBUI_PORT'='18080'
  -e 'VPN_INPUT_PORTS'=''
  -e 'VPN_OUTPUT_PORTS'=''
  -e 'DEBUG'='true'
  -e 'VPN_OPTIONS'=''
  -e 'ENABLE_STARTUP_SCRIPTS'='no'
  -e 'USERSPACE_WIREGUARD'='no'
  -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 'PUID'='99'
  -e 'PGID'='100'
  -e 'UMASK'='000'
  -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 '18118:8118/tcp'
  -p '19118:9118/tcp'
  -p '18080:18080/tcp'
  -p '58946:58946/tcp'
  -p '58946:58946/udp'
  -v '/mnt/user/appdata/binhex-qbittorrentvpn-test':'/config':'rw'
  -v '/mnt/user/data/':'/data':'rw'
  -v 'binhex-shared':'/shared':'rw'
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-qbittorrentvpn'
5d99a8d48703316dcb96b47d5ff355466dc5501d74b47210f6895d97ee5833d7

The command finished successfully!

 

supervisord.log

Edited November 3, 20241 yr by J4bber

41 minutes ago, J4bber said:

When you go under the icon on the docker page and hover over the "WebUI" the link is still to 8080

This is because the web ui link will be using the default value for the port, to fix it click on 'edit' for the container, then toggle 'advanced view' and then change the value for 'WebUI' to the web ui port you want, for example:-

http://[IP]:[PORT:18080]

Note sure what is going on for your second question, can you post some more screenshots showing the issue.

On 11/1/2024 at 8:33 AM, Hardcover9641 said:

The arm64 docker image 5.0.1-1-01 is still using qBit 5.0.0

investigating this.

 

Edit - Looks like a timing issue with upstream, re-kicked off the image build and i now see 5.0.1 is installed, please pull the latest image and try again.

1 hour ago, binhex said:

This is because the web ui link will be using the default value for the port, to fix it click on 'edit' for the container, then toggle 'advanced view' and then change the value for 'WebUI' to the web ui port you want, for example:-

http://[IP]:[PORT:18080]

Note sure what is going on for your second question, can you post some more screenshots showing the issue.

 

Ok, that fixed the WebUI. 

 

Now for the second question.  I figured out how to reproduce it.

 

I cleared all cookies associated with my server. 

 

I then opened the webui for the second instance (18080).  Everything works fine.  No errors.   While this one is open, I open the first instance (8080).  The second instance gives the "can't connect" error when the first instance opens.  Trying the about gives the popup.:

 

 

I tested this on chrome and firefox with the same results.

 

If the first instance (8080) is already open, and I open the second instance (18080) webui, the second instance has the error.  The first instance seems always to be the priority.

 

 

 

15 minutes ago, J4bber said:

 

If the first instance (8080) is already open, and I open the second instance (18080) webui, the second instance has the error.  The first instance seems always to be the priority.

 

 

 

Ok, I see what's happening.  The SID cookie is getting overwritten when the second one comes online.  I am guessing this is what is causing the problem because it thinks they are the same instance when they are not.

 

Before on 8080:

 

 

open 18080 before login:

 

 

Log into 18080 and the cookie for both changes:

 

 

Getting some odd behavior, image launches fine, but the WebUI times out (ERR_CONNECTION_TIMED_OUT). I tried it without VPN enabled and it launched without issue so I checked my credentials/ovpn files and refreshed those through my provider. I'm seeing the changed IP from the provider with curl ifconfig.me and I am able to ping 8.8.8.8 successfully from within the docker image. 
Relevant files requested are attached.

cmdexec.txt supervisord.log

same issue myself and a few others have, no one can seem to sort it.

48 minutes ago, ja444 said:

Getting some odd behavior, image launches fine, but the WebUI times out (ERR_CONNECTION_TIMED_OUT). I tried it without VPN enabled and it launched without issue so I checked my credentials/ovpn files and refreshed those through my provider. I'm seeing the changed IP from the provider with curl ifconfig.me and I am able to ping 8.8.8.8 successfully from within the docker image. 
Relevant files requested are attached.

cmdexec.txt 1.31 kB · 1 download supervisord.log 13.1 kB · 1 download

Your log shows a successful start. Are you trying to access the webUI from your LAN?

Edited November 3, 20241 yr by wgstarks

7 hours ago, binhex said:

That is the issue in a nutshell, Please see Q23 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Great, it worked. But why all of a sudden is this line required. My container was running fine without the two lines for a long time and on multiple docker hosts. Just curious

2 hours ago, wgstarks said:

Your log shows a successful start. Are you trying to access the webUI from your LAN?

Correct. Left clicking on the icon -> WebUI just leads to a timeout. 

I am running qbittorrent version 4.5.4 on unRAID. I use this version because of compatibility with trackers with whitelists.

 

Do we have to worry about this vulnerability as we are on a Linux base? 

Edited November 3, 20241 yr by urbanracer34

On 11/1/2024 at 10:20 AM, nerbonne said:

and I worry that all the activity is hiding the fact that multiple people are having this problem.

 

6 hours ago, nerbonne said:

same issue myself and a few others have, no one can seem to sort it.

Multiple people have the same symptom, as in the inability to view the web ui, this does not mean they have the same problem, in most cases they do not, there are literally dozens of reasons for the vpn tunnel to not come up (web ui will not load until the tunnel is up to prevent ip leakage), i shall take a look at your specific problem when i get some free time (it's late here).

 

10 hours ago, binhex said:

investigating this.

 

Edit - Looks like a timing issue with upstream, re-kicked off the image build and i now see 5.0.1 is installed, please pull the latest image and try again.

Excellent, thank you!

8 hours ago, binhex said:

 

Multiple people have the same symptom, as in the inability to view the web ui, this does not mean they have the same problem, in most cases they do not, there are literally dozens of reasons for the vpn tunnel to not come up (web ui will not load until the tunnel is up to prevent ip leakage), i shall take a look at your specific problem when i get some free time (it's late here).

 

 @nerbonne OK so taken a look, the issue is that you are specifying an IP address for the docker container that also exists within the LAN, from your command execution.txt file:-
 

  --net='br0'
  --ip='10.10.6.184'

So your options are:-

• Switch to 'bridge' network, this image was designed around bridge network and is setup to use this.
• Switch to wireguard (noted you are using openvpn), this should (when last tested) permit LAN access to the web ui with your configuration.
• Create a secondary VLAN that is separate to your LAN range and use that specify an IP for the container

2 hours ago, binhex said:

 @nerbonne OK so taken a look, the issue is that you are specifying an IP address for the docker container that also exists within the LAN, from your command execution.txt file:-
 

  --net='br0'
  --ip='10.10.6.184'

So your options are:-

• Switch to 'bridge' network, this image was designed around bridge network and is setup to use this.
• Switch to wireguard (noted you are using openvpn), this should (when last tested) permit LAN access to the web ui with your configuration.
• Create a secondary VLAN that is separate to your LAN range and use that specify an IP for the container

I keep very good records of the IPs on my LAN, the IP is most definitely not in use already.  If I disable the VPN, the GUI works.  That being said, I set it to bridge as you suggest and that is working.  Wireguard won't download the configuration file, it's possibly blocked in the country I'm in. 

 

Thanks for your assistance!

9 minutes ago, nerbonne said:

I keep very good records of the IPs on my LAN, the IP is most definitely not in use already

I'm not suggesting it's in use, what I'm saying is that this image does not work if you specify a static IP for the container AND the IP address you have specified is also in the LAN_NETWORK range (which it is), it is designed to work in a bridge network (network of container and LAN are different), glad it's working in bridge mode.

I'm unable to access my webUI while connected to a VPN. I can however access the webui when I set VPN_ENABLED to "no" in the container settings. With VPN enabled, I keep getting a "gateway does not support nat-pmp" error in my qbit log, even when I enable NAT-PMP and select a P2P-enabled Proton server in the config.

 

Sorry for not attaching Supervisor log! I followed your instructions, but I found no supervisord.log file in Qbittorrent's /config. Not sure what to do about that, so I attached the qbittorrentvpn debug log instead.

Posted this back in September and never got a reply. If I could get some insights on this, that'd be much appreciated! Thank you.

Qbit debug log (1).docx Command execution (1).docx

 

On 11/3/2024 at 11:09 AM, J4bber said:

Ok, I see what's happening.  The SID cookie is getting overwritten when the second one comes online.  I am guessing this is what is causing the problem because it thinks they are the same instance when they are not.

 

 

After further testing this morning, I found that once I changed the WEBUI password on the second instance from the temporary credentials in the supervisord.log, the SIDs were different, and I could now open both at the same time.

 

So, I guess this is either the fix or the workaround. Regardless, I'll let you decide if any code changes, etc., need to be made on the backend.

Edited November 4, 20241 yr by J4bber

Switched to airvpn for  the port forwarding.  It seems to work and I tested it with a leak tester, but this one line in my logs has me suspect that I am missing something.

 

2024-11-04 12:44:13,104 DEBG 'start-script' stdout output:
[info] VPN provider 'airvpn' not supported for automatic port forwarding, skipping incoming port assignment

I got a port in my account on the airvpn site, I added it in the qbittorrent gui under connections and I also created a new port in unraid with this port, but I still get this during startup.  Am I reading too much into this or am I missing something ?

I do see a number of tracker timeouts or operation not permitted or host not found (authoritative), but not sure if that's just common.  I mainly use pubic torrents as I don't have access to any private sites.

 

TIA, Opie

 

Edited November 4, 20241 yr by opiekeith

On 11/3/2024 at 5:46 PM, urbanracer34 said:

I am running qbittorrent version 4.5.4 on unRAID. I use this version because of compatibility with trackers with whitelists.

 

Do we have to worry about this vulnerability as we are on a Linux base? 

Can someone please answer this for me? 

On 11/4/2024 at 5:37 PM, Andible said:

I'm unable to access my webUI while connected to a VPN. I can however access the webui when I set VPN_ENABLED to "no" in the container settings. With VPN enabled, I keep getting a "gateway does not support nat-pmp" error in my qbit log, even when I enable NAT-PMP and select a P2P-enabled Proton server in the config.

 

Sorry for not attaching Supervisor log! I followed your instructions, but I found no supervisord.log file in Qbittorrent's /config. Not sure what to do about that, so I attached the qbittorrentvpn debug log instead.

Posted this back in September and never got a reply. If I could get some insights on this, that'd be much appreciated! Thank you.

Qbit debug log (1).docxUnavailable Command execution (1).docxUnavailable

 

I have the exact same problem and I have followed the FAQ and input my CIDR correctly but it still does not work. There's something like 50+ other complaints over the years, on the forum here, Github and Reddit about the exact same issue due to the aggressive VPN/firewall blocking everything locally. So I have really checked and read through everything before coming here to request help.

 

Container IP and Port Mappings:

 

Custom Docker network for all my publicly accessible apps:

 

I have the WebUI port set to 8128:

 

LAN network variable is correct according to the FAQ:

 

Unraid is running on: 192.168.1.50 and qbittorrentvpn has the same IP address, and should be accessible at: 192.168.1.50:8128

 

But I get the usual:

 

Using cloudflare I can of course access qbittorrent via the internet, however I have this behind zero trust cloudflare access. So I have to auth into that first and then into qbittorrent.

 

I still need local network access so I can use Radarr/Sonarr/Bazarr and the Flood WebUI.

 

@binhex I am really sorry to ping you mate, but can you explain why this doesn't work still, even after putting in the right values?

Edited November 5, 20241 yr by plantsandbinary

@plantsandbinary This is your first issue:-

 

Note how the container port 8080 is not the same as the host port 8128, Please see Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/qbittorrentvpn.md

2 hours ago, urbanracer34 said:

Can someone please answer this for me? 

 

2 hours ago, urbanracer34 said:

Do we have to worry about this vulnerability as we are on a Linux base? 

By the looks of this article I would say it is advisable to update, yes:- https://sharpsec.run/rce-vulnerability-in-qbittorrent/

AFAIK there have been no attacks in the wild yet, but it's better to be safe than sorry (i have updated).