I tried enabling everything as per kolofotias and it didn't change anything for me. I've attached my scrubbed log from before enabling socks or privoxy.

log.rtf

I used to have a dedicated pihole rPi attached to my home network but it's been disconnected for a while now.

Could it have anything to do with VPN input or output ports?

Edited June 8, 20251 yr by cambrionic
formatting

1 hour ago, cambrionic said:

Could it have anything to do with VPN input or output ports?

no.

nothing wrong in your log, what is the ip address of the machine running the web browser?

4 hours ago, binhex said:

is there any pihole/pfsense/opnsense/adguard or similar running on your network that maybe blocking?, if so please do check the logs and configuration, it all points at something blocking to me.

I do have a pfsense firewall/gateway, but nothing has changed in its configuration for many months. Why would it suddenly start blocking? Has something changed with the way this container talks to/through PIA/WG/whatever that would cause it to suddenly be blocked? I'm afraid that I'm not skilled enough on that end of things to know what I'd need to change, if so. I got my pfsense set up with lots of kind assistance from those with far more knowledge than myself on that front. :)

EDIT: I just restarted the container, while watching my firewall log in dynamic (live) mode. Nothing was reported as blocked at any point during the startup process.

Oddly, I also don't see any traffic passed from my server IP during that same period on any of the expected ports, so perhaps I'm not monitoring correctly.

Edited June 8, 20251 yr by Elmojo
typo

Just to make sure you got all the settings as I have set with wireguard connected to swiis server.... try different server as well

Try adding a NAME_SERVERS var...

Edited June 8, 20251 yr by kolofotias

3 hours ago, cambrionic said:

I tried enabling everything as per kolofotias and it didn't change anything for me. I've attached my scrubbed log from before enabling socks or privoxy.

log.rtf

I used to have a dedicated pihole rPi attached to my home network but it's been disconnected for a while now.

Could it have anything to do with VPN input or output ports?

You didn't enable privoxy and shadowsocks....enable them even if you don't use them for now

Edited June 8, 20251 yr by kolofotias

8 hours ago, kolofotias said:

You didn't enable privoxy and shadowsocks....enable them even if you don't use them for now

Enabling privoxy and/or microsocks (its not shadowsocks, thats different) will not make any difference to connectivity to the vpn tunnel, feel free to enable it if you wish but it won't help.

9 hours ago, Elmojo said:

I do have a pfsense firewall/gateway, but nothing has changed in its configuration for many months. Why would it suddenly start blocking?

if you are using a blocklist then it will get updated on a regular basis. its potentially possible for a blocklist to incorrectly block vpn provider ip range (vpn's are often used by hackers).

lets rule out the latest image being the issue, try left click container, select edit, set 'repository' value to 'binhex/arch-qbittorrentvpn:5.0.5-1-01' then click apply at the bottom and see how it goes.

5 hours ago, binhex said:

if you are using a blocklist then it will get updated on a regular basis. its potentially possible for a blocklist to incorrectly block vpn provider ip range (vpn's are often used by hackers).

lets rule out the latest image being the issue, try left click container, select edit, set 'repository' value to 'binhex/arch-qbittorrentvpn:5.0.5-1-01' then click apply at the bottom and see how it goes.

I'm not using any blocklists. My firewall is pretty default, except for a few custom rules I've added to allow access for specific services, but none of those have changed since I set it all up over a year ago. I don't have any custom rules to block anything.

I pulled the image from the new (old) repo, as suggested, and... no change. The startup sequence seems to be exactly the same. It still errors when trying to connect to the PIA API, then stalls at "[info] Script finished to assign incoming port".

I decided to try watching the firewall logs again while the container started, to see if I could catch what was happening.
During the startup, I see 2 outgoing ports that are being blocked from my server, but neither of them are the ones listed in the docker settings. Just for giggles, I set up rules to pass that traffic (not 100% sure I did those correctly). Now, when I start the container, it does the same thing, and stalls at the same point, but it seems to do it quicker, and I don't get the timeouts like I did before. Is this progress? lol

ok so you can clearly see it is your router (pfsense) that is blocking, if you look at your 'firewall log entries' screenshot, you can see the action is a red cross, i assume in pfsense that means block, and if you look at the destination you can see its blocking to destination ip addresses on port 443 (https).

So you don't want to allow on the source port (35046 and 33210) those ports are randomly assigned and will change every time, instead you want to permit destination port 443.

Yes, of course you see blocking entries, because I filtered it to show only blocking. lol
That's what a firewall does, it blocks unwanted traffic (among other things).
I can't just randomly unblock port 443, as that would allow all traffic from any IP on that port.
Theoretically, all traffic should already be passed on port 443, since that should be authenticated https traffic, but for some reason it's not liking whatever this particular activity is.
Regardless, nothing in the documentation for this container says anything about needing port 443 (not that I've seen anyway), so I'm not even sure if what you see blocked in that screenshot is even related. I just tried it as a guess, since it happened to be in the same timeframe as when I was restarting the container.
I wish I knew more about how this docker is trying to communicate, and why it's suddenly doing something differently. It's been working perfectly for well over a year. It's obviously something VPN-related, since I can disable the VPN and it will connect right away.
I wonder if PIA made some change with their API. Could that be the problem?

EDIT: Oh, and THANK YOU for your patience and help with this. You've done an amazing job creating and maintaining this container for all these years, and it's not like we're paying anything for all this. Speaking of which, is there a way to donate or support you for your work?

Edited June 9, 20251 yr by Elmojo

12 minutes ago, Elmojo said:

That's what a firewall does, it blocks unwanted traffic (among other things).

indeed, but firewals typically block incoming traffic (default configuration), and permit all traffic outbound, so why your firewall is blocking outbound traffic to port 443 i have no idea!, that is extremely odd.

14 minutes ago, Elmojo said:

I can't just randomly unblock port 443, as that would allow all traffic from any IP on that port.

permitting outbound traffic for any ip to port 443 is as i mentioned above, is perfectly normal, otherwise you will have to create bypass rules to permit every website on the internet that use https (nearly all of them), but that decision is yours, sounds like a lot of work :-).

17 minutes ago, Elmojo said:

Regardless, nothing in the documentation for this container says anything about needing port 443 (not that I've seen anyway)

As it's not normal to block port 443 and thus not documented.

17 minutes ago, Elmojo said:

I wish I knew more about how this docker is trying to communicate, and why it's suddenly doing something differently.

In short the vpn container will require 2 things on startup, to be able to resolve names (port 53) and the ability to talk to pia (typically port 443), after it has got everything it requires then the connection will be established to the tunnel and all subsequent traffic will be sent down the tunnel, the only exception being connectivity to the applications web ui - no change in communication that im aware of.

You're absolutely correct about not blocking outbound 443 traffic. I misunderstood what you meant, sorry. I thought you were suggesting that I unblock incoming port 443. Like I said, all outgoing 443 traffic should already be allowed, and it seems that it is, since I have no trouble accessing any web sites from any of my desktops, and the server itself never has any connection issues either, it's just this one container.
I went back and modified the firewall rule, to specifically allow outgoing traffic on port 443 from the server IP, and it hasn't made any difference. Same errors, stalls at the same point.

I do have an adblocking DNS on my desktop, but that has nothing to do with the server or the pfsense firewall.
The gateway (pfsense) is using Clouflare (1.1.1.1) as the primary DNS, so I assume no issues there.

This is so baffling... I just know it's gonna end up being something simple, and stupid (on my end very likely). lol

16 minutes ago, Elmojo said:

You're absolutely correct about not blocking outbound 443 traffic. I misunderstood what you meant, sorry. I thought you were suggesting that I unblock incoming port 443. Like I said, all outgoing 443 traffic should already be allowed, and it seems that it is, since I have no trouble accessing any web sites from any of my desktops, and the server itself never has any connection issues either, it's just this one container.
I went back and modified the firewall rule, to specifically allow outgoing traffic on port 443 from the server IP, and it hasn't made any difference. Same errors, stalls at the same point.

I do have an adblocking DNS on my desktop, but that has nothing to do with the server or the pfsense firewall.
The gateway (pfsense) is using Clouflare (1.1.1.1) as the primary DNS, so I assume no issues there.

This is so baffling... I just know it's gonna end up being something simple, and stupid (on my end very likely). lol

ok staring at your screenshot of the last log from the container i can see we have a connection, its now just having issues with the incoming port assignment, for now lets just turn that off and see if you can access the web ui, so set STRICT_PORT_FORWARD to 'no' and see if you can reach the web ui.

47 minutes ago, binhex said:

set STRICT_PORT_FORWARD to 'no' and see if you can reach the web ui.

Success!! It loaded very quickly (like I remember from before all this started) and connected no problem. I can access the webGUI!

So what does that tell us? Obviously, it's something to do with it accessing the forwarding info via the PIA API, right?

41 minutes ago, Elmojo said:

Success!! It loaded very quickly (like I remember from before all this started) and connected no problem. I can access the webGUI!

So what does that tell us? Obviously, it's something to do with it accessing the forwarding info via the PIA API, right?

It means something (still unknown) is blocking access to https://serverlist.piaservers.net/vpninfo/servers/v4 which is a list of port forward enabled endpoints, can you try going to the 'console' of the container and pasting in the following and pressing return:-

curl https://serverlist.piaservers.net/vpninfo/servers/v4

It should spit out a long json string, also can you try it from your browser (i think we did this previously, but just to be sure you can access it from a 'normal' host), let me know the outcome from console and from your browser.

FYI - so for now you can run like this with STRICT_PORT_FORWARD set to yes, there is no security issues, but your download speed will be impacted as you won't be able to connect to as many peers.

49 minutes ago, binhex said:

try going to the 'console' of the container and pasting in the following and pressing return:-

Long pause, followed by...

curl: (35) TLS connect error: error:00000000:lib(0)::reason(0)

When I click it from my browser, it opens right up, with a screen full of unformatted text.

51 minutes ago, binhex said:

for now you can run like this with STRICT_PORT_FORWARD set to yes

I presume you mean set to NO, right? Yeah, it seems to be working, but it's for sure super slooow. lol
I won't say it's useless, but I would absolutely like to get it back up running full speed at some point if we can sort out why it can't see that server list.

12 hours ago, Elmojo said:

I presume you mean set to NO, right

Sorry, brain fart, i did mean 'no'.

3 hours ago, binhex said:

Sorry, brain fart, i did mean 'no'.

I figured. :)

Did that curl error mean anything to you? I watched the firewall log during that command, and nothing was reported as being blocked.

@Elmojo

Looking at your docker run you have this for local networks -e 'LAN_NETWORK'='192.168.1.0/24, 100.64.98.0/24'

Looking at your PFSense rules you have a 192.168.11.0/24 network.

Should you not be adding that network to your docker also?

53 minutes ago, Ebirts said:

Looking at your docker run you have this for local networks -e 'LAN_NETWORK'='192.168.1.0/24, 100.64.98.0/24'

That's outdated info. That 2nd network was just for my Tailscale remote access. Since I wiped everything and started fresh, I didn't include that extra network. If we can get everything else working, I may go back and add it, but it's not critical. Thanks for looking, though! :)

On 6/8/2025 at 1:31 PM, binhex said:

no.

nothing wrong in your log, what is the ip address of the machine running the web browser?

The server is babel.local
LAN IP is 192.168.0.137:8080

Container IP is 172.18.0.2

I think I figured it out!!

So the default value for Variable: LAN_Network is 192.168.1.0/24, but my LAN IP for the container was 192.168.0.137. Changing this to 192.168.0.0/24 fixed the issue for me, at least with regards to the WebGUI access!

Thank you!!!

I have found out what is going on with network and this container. The container is not correctly editing the resolv.conf file fast enough and DNS just breaks. I have found that i have to change the nameserver in /etc/resolv.conf from "nameserver 127.0.0.11" to "nameserver 1.1.1.1" then it starts loading, it appears the DNS/resolv.conf update script triggers AFTER it starts the connection to a VPN server, so without working VPN before the script updates resolv.conf DNS is broken forever.

Is there any reason for this, and are any other people having the same issue? I have pasted some info from the container Log below so people can see where it breaks.

2025-06-12 00:53:16.581378 [debug] Having issues resolving name 'ca-toronto.privacy.network', sleeping before retry...

2025-06-12 00:53:21.674007 [debug] DNS operational, we can resolve name 'ca-toronto.privacy.network' to address '179.61.197.44 191.96.36.209 191.96.36.210'

2025-06-12 00:53:21.775482 [debug] DNS operational, we can resolve name 'www.privateinternetaccess.com' to address '104.18.40.93 172.64.147.163'

2025-06-12 00:53:21.879617 [debug] DNS operational, we can resolve name 'serverlist.piaservers.net' to address '104.18.159.201 104.19.240.167'

2025-06-12 00:53:21.908167 [debug] Showing name servers in '/etc/resolv.conf' before overwrite from NAME_SERVERS...

2025-06-12 00:53:21.926360 [debug] # Generated by Docker Engine.

2025-06-12 00:53:21.926396 [debug] # This file can be edited; Docker Engine will not make further changes once it

2025-06-12 00:53:21.926402 [debug] # has been modified.

2025-06-12 00:53:21.926406 [debug]

2025-06-12 00:53:21.926409 [debug] nameserver 1.1.1.1 ***(CHANGED FROM "nameserver 127.0.0.11" TO GET DNS TO WORK)***

2025-06-12 00:53:21.926414 [debug] options ndots:0

2025-06-12 00:53:21.926417 [debug]

2025-06-12 00:53:21.926420 [debug] # Based on host file: '/etc/resolv.conf' (internal resolver)

2025-06-12 00:53:21.926423 [debug] # ExtServers: [100.100.100.100]

2025-06-12 00:53:21.926427 [debug] # Overrides: []

2025-06-12 00:53:21.926430 [debug] # Option ndots from: internal

2025-06-12 00:53:21.950627 [debug] Showing name servers in '/etc/resolv.conf' after overwrite from NAME_SERVERS...

2025-06-12 00:53:21.968717 [debug] nameserver 1.1.1.1

2025-06-12 00:53:21.968753 [debug] nameserver 84.200.69.80

2025-06-12 00:53:21.968759 [debug] nameserver 37.235.1.174

2025-06-12 00:53:21.968762 [debug] nameserver 37.235.1.177

2025-06-12 00:53:21.968765 [debug] nameserver 84.200.70.40

For a while now I've been having issues with the client using excessive CPU resources. All of my cores are running on 100% which only leaves me with hyper-threads. I'm not sure what's going on. The torrent client isn't even downloading anything. The logs don't seem to indicate anything special either:

2025-06-12 17:47:44,059 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port '32775'

2025-06-12 17:57:44,127 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port '32775'

2025-06-12 18:07:44,167 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port '32775'

2025-06-12 18:17:44,208 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port '32775'

2025-06-12 18:27:44,248 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port '32775'

2025-06-12 18:37:44,290 DEBG 'start-script' stdout output:

[info] Successfully assigned and bound incoming port '32775'

I have looked into the other supervisord files as well and I'm not sure what to look for, it all seems relatively normal for me. Any input would really help!

So something odd I have noticed is that it seems the port assigned via the VPN (proton) isnt updating on the qbit container correctly, I was having a weird tracker connectivity issue where I had to manually set the Incoming port on the configuration in unraid, and after I did that everything started connecting correctly. Thankfully with proton the Port assigned doesnt normally change if you do a quick disconnect and reconnect (IE restarting the container)
There wasn't really any logs about it, qbit seemed to think it had correctly assigned the port:

2025-06-13 13:39:59,562 DEBG 'start-script' stdout output:

[info] Script started to assign incoming port for 'protonvpn'

2025-06-13 13:39:59,566 DEBG 'start-script' stdout output:

[info] WireGuard interface 'up'

2025-06-13 13:40:01,629 DEBG 'start-script' stdout output:

initnatpmp() returned 0 (SUCCESS)

using gateway : 10.0.0.0

sendpublicaddressrequest returned 2 (SUCCESS)

readnatpmpresponseorretry returned 0 (OK)

Public IP address : *.*0.0

epoch = 000000

closenatpmp() returned 0 (SUCCESS)

2025-06-13 13:40:02,490 DEBG 'watchdog-script' stdout output:

[info] qBittorrent listening interface IP 0.0.0.0 and VPN provider IP 10.0.0.0 different, marking for reconfigure

2025-06-13 13:40:02,502 DEBG 'watchdog-script' stdout output:

[info] qBittorrent not running

2025-06-13 13:40:02,503 DEBG 'watchdog-script' stdout output:

[info] qBittorrent incoming port 6881 and VPN incoming port 33333 different, marking for reconfigure

2025-06-13 13:40:02,505 DEBG 'watchdog-script' stdout output:

[info] qBittorrent config file already exists, skipping copy

[info] Removing session lock file (if it exists)...

2025-06-13 13:40:02,577 DEBG 'watchdog-script' stdout output:

[info] Attempting to start qBittorrent...

2025-06-13 13:40:02,586 DEBG 'watchdog-script' stdout output:

[info] qBittorrent process started

[info] Waiting for qBittorrent process to start listening on port 8080...

2025-06-13 13:40:55,637 DEBG 'watchdog-script' stdout output:

[info] qBittorrent process listening on port 8080

But in the logs on the Web UI i see this before I manually assigned the port in the unraid qbit config on the webportal: [CRITICAL] Failed to listen on IP. IP: "10.0.0.0". Port: "TCP/33333". Reason: "Address already in use"

also was unable to manually assign the Port in the Qbit Web UI for the incoming port, it still was displaying the old port from when my internet reconnected last night. Even though according to the old logs it had gone though the same steps of reconnecting and reassigning the new port.

Another thing I have noticed aswell is that it is somehow using two IPs over the VPN, I dont know how that is possible but I see it using two different IPs on a website.

Edited June 13, 20251 yr by Kognac