41 minutes ago, Tpole said:

Im having the same issue as above since the last update on Unraid due to PIA.

can you try issuing the commands in my previous post.

@Tpole @modsa @Yock as i cannot reproduce the issue i decided to simply re-create the image, please issue a 'force update' to pull down the image just built and see if it fixes the issue.

1 hour ago, binhex said:

the is the exact fix i have implemented via code, i simply do not understand yet how it works for me and appears to be completely missing for you, even though we are both using what appears to be the same image!.

 

ok can you go to the 'console' of the container and then copy and paste the command below:-

 

grep -P -o 'crl-verify' < /root/start.sh

if you have the latest image then this will return 4 matches which will printed to the screen, like so:-
 

sh-5.2# grep -P -o 'crl-verify' < /root/start.sh
crl-verify
crl-verify
crl-verify
crl-verify

if nothing is returned then you are out of date, please let me know the outcome.

Ah okay, so nothing wrong with my manual fix of the .ovpn file for now?

With the command above it does indeed print the 4 matches of crl-verify.

2 hours ago, binhex said:

can you try issuing the commands in my previous post.

Did this and got the expected print result of ctrl-verify x4

2 hours ago, binhex said:

@Tpole @modsa @Yock as i cannot reproduce the issue i decided to simply re-create the image, please issue a 'force update' to pull down the image just built and see if it fixes the issue.

I force updated and still have the same error. Anything i can supply that may assist?

7 minutes ago, Tpole said:

I force updated and still have the same error. Anything i can supply that may assist?

Ive spotted the issue!, the code to modify the ovpn file was nested in the wrong if block, fixed it, please pull down latest image just built and you should be good.

Many thanks for the fix, keep up the great work!

Here's my Docker run and log file again.  Seems to maybe have gotten lost in the shuffle.

Anyone have suggestions for helping clear the firewalled status of my qBT?

I did figure out that my VM isn't really involved, although it's firewalled as well.  I'm actually running 2 instances of qBT.  One is the one that's hosted by this docker, and is accessed via the webUI.  It's connected to my *arrs.  The other is a desktop client I have installed within a VM, that I use for various random manual downloads like Linux distros and such.  I had confused myself by forgetting that I had it set up that way. lol

Regardless, they are both listed as 'firewalled' now, so something has changed recently on the backend.  I'm guessing it might be related to my change over from Mullvad to PIA, except that it's been working with PIA just fine for the past couple weeks, and the firewall icon has only appeared in the last couple days.  The only changes I'm aware of have been container updates to this docker.

Docker Run

Command execution
docker run
  -d
  --name='binhex-qbittorrentvpn'
  --net='bridge'
  --privileged=true
  -e TZ="America/New_York"
  -e HOST_OS="Unraid"
  -e HOST_HOSTNAME="Tower"
  -e HOST_CONTAINERNAME="binhex-qbittorrentvpn"
  -e 'VPN_ENABLED'='yes'
  -e 'VPN_USER'='----'
  -e 'VPN_PASS'='----'
  -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.11.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'='45206'
  -e 'VPN_OUTPUT_PORTS'=''
  -e 'DEBUG'='false'
  -e 'UMASK'='000'
  -e 'PUID'='1001'
  -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 '6881:6881/tcp'
  -p '6881:6881/udp'
  -p '8080:8080/tcp'
  -p '8118:8118/tcp'
  -v '/mnt/user/downloads/':'/data':'rw'
  -v '/mnt/user/appdata/binhex-qbittorrentvpn':'/config':'rw'
  --sysctl="net.ipv4.conf.all.src_valid_mark=1" 'binhex/arch-qbittorrentvpn'
684f731f8e6dbd0002b0a66958de5b7dd1b130baad6e8b790c809907c8cd432e

The command finished successfully!

 

supervisord.log

 

EDIT:  OK, super weird.  I just checked, and the webUI for this container is now showing connected, no firewalled icon.  However, the one on my VM is still firewalled.  I've checked that I have the correct forwarded port (from PIA) entered into qBT.  Not sure what else I'd need to do...

Edited June 4, 20242 yr by Elmojo
added update

3 minutes ago, Elmojo said:

Regardless, they are both listed as 'firewalled' now, so something has changed recently on the backend. 

Please see Q15 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

In short your router has nothing to do with port forwarding whatsoever when using a vpn.

1 minute ago, binhex said:

short your router has nothing to do with port forwarding

Correct.  I'm not doing any forwarding in the router.

My VM setup looks like this...

 

1 hour ago, Elmojo said:

My VM setup looks like this...

why do you have a vm, what is the purpose of this?, all you need is this container running, it includes qbittorrent web ui and all required tooling to connect to a vpn provider.

 

EDIT ahh ok i read up a bit further, so the container is running just fine and your qbittorrent app running in your vm is not, im afraid that's out of scope for this support thread, i only support the container, if you are trying to setup a vm running qbittorrent then you are on your own, sorry.

Quote

EDIT:  OK, super weird.  I just checked, and the webUI for this container is now showing connected, no firewalled icon.  However, the one on my VM is still firewalled.  I've checked that I have the correct forwarded port (from PIA) entered into qBT.  Not sure what else I'd need to do...

 

I am using ProtonVPN and port forwarding port not automatically assigned after the previous update. It was working previously.

current log shows

2024-06-05 00:33:18,014 DEBG 'watchdog-script' stdout output:
[info] qBittorrent listening interface IP 0.0.0.0 and VPN provider IP 10.2.0.2 different, marking for reconfigure

2024-06-05 00:33:18,021 DEBG 'watchdog-script' stdout output:
[info] qBittorrent not running

2024-06-05 00:33:18,021 DEBG 'watchdog-script' stdout output:
[info] qBittorrent incoming port 6881 and VPN incoming port 52584 different, marking for reconfigure

2024-06-05 00:33:18,021 DEBG 'watchdog-script' stdout output:
[info] qBittorrent config file already exists, skipping copy
[info] Removing session lock file (if it exists)...

2024-06-05 00:33:18,029 DEBG 'watchdog-script' stdout output:
[info] Attempting to start qBittorrent...

2024-06-05 00:33:18,031 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process started

2024-06-05 00:33:18,031 DEBG 'watchdog-script' stdout output:
[info] Waiting for qBittorrent process to start listening on port 8082...

2024-06-05 00:33:18,138 DEBG 'watchdog-script' stdout output:
[info] qBittorrent process listening on port 8082

 

it say marking for reconfigure, but it never does. I have to manually change it in webui

previously the "start-script" shows that the automatic port forward works:

2024-06-04 07:37:38,955 DEBG 'start-script' stdout output:
[info] Successfully assigned and bound incoming port '58741'

 

Edited June 4, 20242 yr by Sak

8 minutes ago, Sak said:

I am using ProtonVPN and port forwarding port not automatically assigned after the previous update. It was working previously.

wireguard or openvpn? also which country endpoint are you using?

Just now, binhex said:

wireguard or openvpn? also which country endpoint are you using?

wireguard connecting to ProtonVPN Cambodia

6 minutes ago, Sak said:

wireguard connecting to ProtonVPN Cambodia

ok thanks for the info, leave it with me, i did do extensive testing with protonvpn and i have a 1month subscription so i can test it, but unless something has changed this WAS working with the current image.

Just now, binhex said:

ok thanks for the info, leave it with me, i did do extensive testing with protonvpn and i have a 1month subscription so i can test it, but unless something has changed this WAS working with the current image.

thanks for the work, really appreciate it. It was working fine until the recent update.

btw I am also getting this warning

Warning: `/config/wireguard/wg0.conf' is world accessible

did I misconfigure something, or can I ignore this warning?

2 minutes ago, Sak said:

did I misconfigure something, or can I ignore this warning?

can be ignored.

 

ok so i have just tested it connecting to cambodia via wireguard protonvpn and the port is correctly assigned and qbittorrent is correctly configured and once i add in a torrent then the orange flame turns into a green globe to indicate port forwarding is operational, so i cannot reproduce it at present 😞

Just now, binhex said:

can be ignored.

 

ok so i have just tested it connecting to cambodia via wireguard protonvpn and the port is correctly assigned and qbittorrent is correctly configured and once i add in a torrent then the orange flame turns into a green globe to indicate port forwarding is operational, so i cannot reproduce it at present 😞

 

Quote

2024-06-04 19:06:27,676 DEBG 'start-script' stdout output:
[debug] ProtonVPN assigned incoming port is '54238'

19 minutes ago, binhex said:

 

I just recreated the container with a new image still but still facing the same problem. Maybe it's just my setup, I'll do it manually for now, till it works again. thanks anyway

55 minutes ago, binhex said:

so the container is running just fine and your qbittorrent app running in your vm is not

The container is connecting correctly at the moment, but it wasn't as of last night.  I have no idea why it suddenly started working, unless there was an update overnight and I didn't notice?  I'm concerned that it'll break again in the background and I may not notice.

As for the VM, I get that it's not directly in-scope for this thread, but I thought maybe since the config was so similar, you might have some insights. 

8 hours ago, binhex said:

Ive spotted the issue!, the code to modify the ovpn file was nested in the wrong if block, fixed it, please pull down latest image just built and you should be good.

i still have the issue even after updating the docker. using private internetaccess + ovpn file. i recreated the ovpn file just in case. 

The log still says.

2024-06-04 22:11:53 OpenSSL: error:068000E9:asn1 encoding routines::utctime is too short:
2024-06-04 22:11:53 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=revocationDate, Type=X509_REVOKED
2024-06-04 22:11:53 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=revoked, Type=X509_CRL_INFO
2024-06-04 22:11:53 OpenSSL: error:0688010A:asn1 encoding routines::nested asn1 error:Field=crl, Type=X509_CRL
2024-06-04 22:11:53 OpenSSL: error:0488000D:PEM routines::ASN1 lib:

ive got the same error with PIA. only works when VPN is disabled. ive followed the earlier steps and still cannot access unless i turn the VPN off. 

ive forced the update as well and still nothing 

 

14 hours ago, binhex said:

the is the exact fix i have implemented via code, i simply do not understand yet how it works for me and appears to be completely missing for you, even though we are both using what appears to be the same image!.

 

ok can you go to the 'console' of the container and then copy and paste the command below:-

 

grep -P -o 'crl-verify' < /root/start.sh

if you have the latest image then this will return 4 matches which will printed to the screen, like so:-
 

sh-5.2# grep -P -o 'crl-verify' < /root/start.sh
crl-verify
crl-verify
crl-verify
crl-verify

if nothing is returned then you are out of date, please let me know the outcome.

I ran the command you asked, and this is the result from my end. I am also experiencing this issue now (it started yesterday)

sh-5.2# grep -P -o 'crl-verify' < /root/start.sh
crl-verify
crl-verify
crl-verify
crl-verify

 

Edited June 4, 20242 yr by asherbig

12 hours ago, binhex said:

Ive spotted the issue!, the code to modify the ovpn file was nested in the wrong if block, fixed it, please pull down latest image just built and you should be good.

absolute legend that fixed it! thanks so much!

8 hours ago, asherbig said:

 

I ran the command you asked, and this is the result from my end. I am also experiencing this issue now (it started yesterday)

sh-5.2# grep -P -o 'crl-verify' < /root/start.sh
crl-verify
crl-verify
crl-verify
crl-verify

 

Do a 'force update' I think you are not running the latest image