i figured it out. i had to change 0.0.0.0/0 to 0.0.0.0/1, 128.0.0.0/1

Hi, I currently have binhex-sabnzbdvpn which is being used by Radarr, Sonarr, and NZBHydra through Privoxy. I also have binhex-qbittorrentvpn which is being used with Readarr and Prowlarr.

 

This has lead me to a position where I have two separate VPN containers with usenet traffic going through sab's vpn and my torrent traffic goes through qbittorrent vpn. Nothing wrong with this per se but I'd like to consolidate them to use a single container to manage VPN and Privoxy so my *arr containers can use both sab and qbit.

 

Would the recommended approach here be to:

1. Install this container
2. Disable VPN on both sab and qbit
3. Install this container and add the VPN input/output ports
4. Route all *arr containers to use this new container?

Any concerns with this approach or advantage by going with the built in vpn containers I have now?

3 hours ago, unRaide said:

Hi, I currently have binhex-sabnzbdvpn which is being used by Radarr, Sonarr, and NZBHydra through Privoxy. I also have binhex-qbittorrentvpn which is being used with Readarr and Prowlarr.

 

This has lead me to a position where I have two separate VPN containers with usenet traffic going through sab's vpn and my torrent traffic goes through qbittorrent vpn. Nothing wrong with this per se but I'd like to consolidate them to use a single container to manage VPN and Privoxy so my *arr containers can use both sab and qbit.

 

Would the recommended approach here be to:

1. Install this container
2. Disable VPN on both sab and qbit
3. Install this container and add the VPN input/output ports
4. Route all *arr containers to use this new container?

Any concerns with this approach or advantage by going with the built in vpn containers I have now?

two concerns with this approach:-

 

1. you will have no incoming port assigned and thus torrenting will be slow

2. you are going to be routing usenet and torrent traffic over a single vpn tunnel, this will result in lower speeds if you are torrenting and performing usenet downloads at the same time.

7 hours ago, binhex said:

two concerns with this approach:-

 

1. you will have no incoming port assigned and thus torrenting will be slow

2. you are going to be routing usenet and torrent traffic over a single vpn tunnel, this will result in lower speeds if you are torrenting and performing usenet downloads at the same time.

Hi @binhex, thx for responding!

 

One of the issues I'm not sure how to solve is giving my *arr containers to access either usenet OR torrent? The kludgy way I got around this is to setup Hydra exclusively for usenet and point it towards sabnzbdvpn and prowlarr just for torrents pointing to qbittorrentvpn. However this means Radarr / Sonarr can't acsess Prowlarr as they are also setup to use privoxy from the sabnzbdvpn container  

 

Do you have any thoughts on the best way to tackle this? 

1 hour ago, unRaide said:

I'm not sure how to solve is giving my *arr containers to access either usenet OR torrent?

assuming you have sabnbdvpn setup and qbittorrentvpn running (for example - both in default 'bridge' mode) you would then point your arrs at http://<your unraid server ip>:<the port for sab/qbit> does this not work?.

On 9/10/2024 at 1:18 AM, binhex said:

assuming you have sabnbdvpn setup and qbittorrentvpn running (for example - both in default 'bridge' mode) you would then point your arrs at http://<your unraid server ip>:<the port for sab/qbit> does this not work?.

 

Hi again, I am likely doing something wrong, but when I have Prowlarr connected to my qbittorrent vpn, I can't seem to connect it to sabnzbd-vpn?

 

I've tried using both "localhost" on port 8080 or "192.168.1.217" on port 8080 as the host but it doesn’t connect. 

 

My current setup is:

• sabnzbd-vpn (8080)
  • Privoxy on 8118
    • Radarr
    • Sonarr
    • NZBd Hydra
• qbittorrent-vpn (8081)
  • Readarr
  • Prowlarr
  • Privoxy - I tried to set this up on port 8119 for Prowlarr and Readarr to go through but it always defaults to port 8118 after startup in the logs even after removing the original port and creating a new one??

Ideally, I'd like to retire Hydra and just use Prowlarr for all my *arrs, running through privoxy, with the ability for each *arr to use either usenet or torrents.

 

 

Edited September 11, 20241 yr by unRaide

On 9/10/2024 at 10:07 PM, unRaide said:

 

Hi again, I am likely doing something wrong, but when I have Prowlarr connected to my qbittorrent vpn, I can't seem to connect it to sabnzbd-vpn?

 

I've tried using both "localhost" on port 8080 or "192.168.1.217" on port 8080 as the host but it doesn’t connect. 

 

My current setup is:

• sabnzbd-vpn (8080)
  • Privoxy on 8118
    • Radarr
    • Sonarr
    • NZBd Hydra
• qbittorrent-vpn (8081)
  • Readarr
  • Prowlarr
  • Privoxy - I tried to set this up on port 8119 for Prowlarr and Readarr to go through but it always defaults to port 8118 after startup in the logs even after removing the original port and creating a new one??

Ideally, I'd like to retire Hydra and just use Prowlarr for all my *arrs, running through privoxy, with the ability for each *arr to use either usenet or torrents.

 

 

Hi @binhex, apologies for the bump but would appreciate any thoughts you have on the optimal way to set this up.

After years of working correctly, my sonarr and radarr (routed thru privoxyvpn) started to have an issue with indexers (not connecting). If I restart all involved dockers: privoxyvpn, radarr and sonarr - in that order, everything seems to work for a minute. After that indexers cannot connect. If I open a console for either radarr or sonarr and ping any domain (including indexers) it works fine. I've not made any changes in my system in months other than updating dockers.

 

When i configured sonarr to connect directly (bridge), everything worked.

 

I'm running Unraid 6.12.13

Edited October 3, 20241 yr by dariusz65

On 7/15/2024 at 11:27 AM, binhex said:

nope, its not a bind mount, its a docker volume, so therefore no forward slash, its correct as it is, FYI its a new feature that has been added to the latest template, it will be used to store the incoming port and then shared between containers.

I have a Binhex Docker where the /shared is mapping to binhex-share which obviously does not work

 

Path: /shared:      --> binhex-shared

 

do i have to define a path instead of the "Binhex-shared"?

 

My Appdata Backup always brings up this error

'binhex-shared' does NOT exist! Please check your mappings! Skipping it for now.

On 7/15/2024 at 11:27 AM, binhex said:

nope, its not a bind mount, its a docker volume, so therefore no forward slash, its correct as it is, FYI its a new feature that has been added to the latest template, it will be used to store the incoming port and then shared between containers.

I also have a docker from binhex but the mapping is wrong

Path: /shared:   --->>   binhex-shared

this is obviously wrong... do i have to set a  path instead of "binhex-shared"?

 

Because my Appdata Backup brings this erorr:
'binhex-shared' does NOT exist! Please check your mappings! Skipping it for now.

Edited October 23, 20241 yr by zuerom
update screenshot

2 hours ago, zuerom said:

this is obviously wrong

no it's not.

 

2 hours ago, zuerom said:

Because my Appdata Backup brings this erorr:
'binhex-shared' does NOT exist! Please check your mappings! Skipping it for now.

Thats because this app does not understand the idea of docker volumes, which this is, ignore it.

Hey, so i am having an issue here, I have a few containers that I need to route through the VPN because they don't have any other way of doing it, however, I can't seem to get access to the WebUI working at all. I passed the webui port of the child container through the privoxy container and it just doesn't work anymore. I haven't done this in a long time for sure but I have done it in the past. I have been searching tirelessly for days trying to find a solution and it just isn't working.

I have the Binhex sab and qbittorrent containers too and I also tried using those as the VPN containers and nothing still. I can log into a console for the child container(s) curl ifconfig.io and it is indeed getting internet access and it is indeed using the VPN IP for it, just no WebUI.

 

Any assistance would be greatly appreciated.

Doing some more digging here and I have found something. I decided to use nmap and see what I could find while waiting for a reply here. Here are my results.

 

cammelspit@daddy-archlinux ~
❯❯❯ nmap -p 3333 10.10.10.99                                                                                                                                                                                    No
Starting Nmap 7.95 ( https://nmap.org ) at 2024-11-05 07:29 MST
Nmap scan report for 10.10.10.99
Host is up (0.00010s latency).

PORT     STATE    SERVICE
3333/tcp filtered dec-notes

Nmap done: 1 IP address (1 host up) scanned in 0.21 seconds

cammelspit@daddy-archlinux ~
❯❯❯ nmap -p 3344 10.10.10.99                                                                                                                                                                                    No
Starting Nmap 7.95 ( https://nmap.org ) at 2024-11-05 07:30 MST
Nmap scan report for 10.10.10.99
Host is up (0.00010s latency).

PORT     STATE  SERVICE
3344/tcp closed bnt-manager

Nmap done: 1 IP address (1 host up) scanned in 0.01 seconds

cammelspit@daddy-archlinux ~
❯❯❯ nmap -p 80 10.10.10.99                                                                                                                                                                                      No
Starting Nmap 7.95 ( https://nmap.org ) at 2024-11-05 07:31 MST
Nmap scan report for 10.10.10.99
Host is up (0.00011s latency).

PORT   STATE SERVICE
80/tcp open  http

Nmap done: 1 IP address (1 host up) scanned in 0.01 seconds

 

Ok, so as you can see, port 80, the unraid UI is open, no issues there, port 3344 is closed, that makes some sense as I havent mapped that port in privoxyvpn but it is used by the bitmagnet container, port 3333 is the webui port of the bitmagnet container I am trying to access and it says filtered, meaning I believe that the privoxy container is seeing the incoming request for 3333 and rejecting it instead of forwarding it? I dunno, I am just not versed enough in these things to say for sure but because it is niether open nor closed, that implies something is actively blocking it. Thankfullt all containers I wish to use are Binhex ones for this so i am hoping someone can help out.

3 hours ago, cammelspit said:

Hey, so i am having an issue here, I have a few containers that I need to route through the VPN because they don't have any other way of doing it, however, I can't seem to get access to the WebUI working at all.

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

10 hours ago, binhex said:

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

Thanks for the heads up on Q25, I reviewed Q24 half a dozen times, lol. it seems to be working now, appreciate it.

Hello thanks for creating this amazing application.

I have read your VPN FAQ to the best of my abilities and had some questions/ some things I wanted clarification on

 

Question 1: It seems there are multiple ways to utilize the VPN that is within the privoxyvpn container/image. I was wondering if there is a preferred way of utilizing the VPN. Using the Privoxy (FAQ reference Q3,Q12) VS routing the docker containers together (FAQ reference Q24)

 

Question 2: I am curious about security; If someone can see the data being transmitting to the privoxy (if they are within my local network). How does the containers connect to the Privoxy? Is it through TCP (HTTP)? TCP (HTTPS)? I assume HTTP unless i provide my own cert?

 

Question 2b: If i do need to provide my own cert, how would I go about that?

 

Question 2c: I believe I can utilize socks with a password but the application would need to support socks? (Q12)

 

Question 3: From reading the documentation if I did route all docker container together (Q24), I don't need to use a privoxy because I am utilize the VPN that is established in the privoxyvpn container? (FAQ reference Q3) This means that I can ENABLE_PRIVOXY=no

 

Question 4: If i did route docker containers together, would it be best to have one privoxyvpn container per application/docker container to ensure I don't saturate the network?

 

Sample of docker compose/ docker network:

• application a -> privoxyvpn a
• application b -> privoxyvpn b

OR

• application a -> privoxyvpn a
• application b -> privoxyvpn a

 

These are the FAQ questions I am referencing.

- Q3. What is the purpose of Privoxy?

- Q12. I have an application that does not seem to support the use of a proxy (privoxy), how do I configure the application to use Privoxy?

- Q24. I would like to be able to route other docker containers through one of my existing VPN containers, how do I do this?

 

Thanks very much for anyone support

 

I've been running the privoxyvpn container for years now in my setup, without much fuss. However, it seems in the past week, something has broken, and the container can no longer configure the tun/tap device. The container seems to start up OK, but eventually gets into an OpenVPN restart loop with the following message:

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

 

I checked git (I deploy the container using ansible, so my setup is version controlled), and I've not changed my docker compose setup in 22 months. All I've been doing is installing updates through apt, and occasionally re-running my ansible playbook to update the docker images.

 

I did get a shell in the container, and I did see that /dev/net/tun

 

Attached is a dump of the container log from start until the first failure, and a copy of the relevant bits of my docker compose file configuring privoxyvpn. I'm running Docker version 27.4.1, build b9d17ea on Ubuntu 22.04.5.

 

Any help is greatly appreciated!

EDIT:

Not 2 minutes after posting this, I figured out the solution - I needed to pass the tun device through in my compose setup. I added the following to the service definition for the container:

devices:
      - "/dev/net/tun:/dev/net/tun"

Maybe this was something new that's required with the latest version of Docker/Docker Compose? I don't see this in the readme for the container.
 

privoxyvpn.log privoxyvpn docker compose.yml

Edited December 20, 20241 yr by docker4dayz

2 hours ago, docker4dayz said:

Maybe this was something new that's required with the latest version of Docker/Docker Compose? I don't see this in the readme for the container.

it is a recent change to docker containerd, if you fancy a read click here and follow the links:- https://github.com/binhex/arch-qbittorrentvpn/issues/294#issuecomment-2536696369

Many thanks for your work on this and other dockers - THANKS!

I am running privoxyvpn with PIA and using strict port forwarding and openvpn.

Two questions:

1. Is there a web GUI for the actual privoxyvpn docker? I assume this (http://config.privoxy.org/) is not it and I need to update it in my docker setup? My GUIs to the dockers running through privoxyvpn are all good.  I am assuming local host or my Unraid IP with the correct port? I would stop it to try but that leads me to (2)....
2. I am using PIA and running several dockers through privoxyvpn. One of these is deluge (not deluge VPN). I note that to get this fully connected to the service it is using I need to go into the preference in Deluge client and change the port from 58946 to the port that shows up in the privoxyvpn logs. I think I understand why but would like to understand. PIA must "randomly" (??) give a port and the service ports that we input when setting up the privoxyvpn are just used to route in the Unraid VPN network we created? Will I need to look in the logs every time I restart privoxyvpn to check on the port to use for the Deluge client? I may be totally lost or explaining it poorly.

 

Many thanks for any clarity you can provide! Happy holidays to all!

Edited December 24, 20241 yr by TexasDave

After upgrading to unRAID 7.0.0, I am having an issue with a single docker (rdesktop-Ubuntu-KDE) which is on my privoxy container network.  The container natively listens on port 3389.  This is the only container on my privoxy container network that I can no longer access on my LAN.  I have blown the config for that container away and rebuilt it, to no avail. 

 

The ports are removed from the rdesktop container, and on the privoxy setup I have 3389 listed in VPN_INPUT_PORTS (along with others (comma separated) that ARE working properly), and have added a port for 3389 container to 3390 remapped.  It doesn't work; which it did prior to 7.0.0 upgrade.  The container throws NO errors and there is nothing meaningful in the rdesktop container log.  From the rdesktop container's shell, I *can* reach the internet via the Privoxy VPN container that it's bound to, but I cannot connect from my LAN to port 3390 (it's not listening). 

 

To test, I've removed it from the container network and set it on the bridge network and it works perfectly.

 

Nothing in the supervisord log looks 'off' to me, but it's attached below.  Suggestions for further troubleshooting steps?

supervisord_log.txt

On 2/22/2025 at 1:57 PM, NDDan said:

After upgrading to unRAID 7.0.0, I am having an issue with a single docker (rdesktop-Ubuntu-KDE) which is on my privoxy container network.  The container natively listens on port 3389.  This is the only container on my privoxy container network that I can no longer access on my LAN.  I have blown the config for that container away and rebuilt it, to no avail. 

 

The ports are removed from the rdesktop container, and on the privoxy setup I have 3389 listed in VPN_INPUT_PORTS (along with others (comma separated) that ARE working properly), and have added a port for 3389 container to 3390 remapped.  It doesn't work; which it did prior to 7.0.0 upgrade.  The container throws NO errors and there is nothing meaningful in the rdesktop container log.  From the rdesktop container's shell, I *can* reach the internet via the Privoxy VPN container that it's bound to, but I cannot connect from my LAN to port 3390 (it's not listening). 

 

To test, I've removed it from the container network and set it on the bridge network and it works perfectly.

 

Nothing in the supervisord log looks 'off' to me, but it's attached below.  Suggestions for further troubleshooting steps?

supervisord_log.txt 9.38 kB · 1 download

This is resolved. 

I'm not sure what changed, but I suspect it's the rdesktop container.  In case this helps abyone, the problem related to the x11 session manager, it was only binding on the ivp6 address though it was set to the ipv4.  Adding (to the rdesktop container) extra paramters to disable ipv6 within that container, solved the issue -- again in case it helps someone, here are the extra parms to accomplish that (DON'T to this on your privoxy container!):

--sysctl net.ipv6.conf.all.disable_ipv6=1
--sysctl net.ipv6.conf.default.disable_ipv6=1

On 3/9/2025 at 2:49 PM, NDDan said:

This is resolved. 

I'm not sure what changed, but I suspect it's the rdesktop container.  In case this helps abyone, the problem related to the x11 session manager, it was only binding on the ivp6 address though it was set to the ipv4.  Adding (to the rdesktop container) extra paramters to disable ipv6 within that container, solved the issue -- again in case it helps someone, here are the extra parms to accomplish that (DON'T to this on your privoxy container!):

--sysctl net.ipv6.conf.all.disable_ipv6=1
--sysctl net.ipv6.conf.default.disable_ipv6=1

OK, well that didn't solve my issue, there are other services that bind to ipv6 on lo that DO NOT WORK (like some pulseaudio dependencies).  I was able to get this working, but @binhex I'm wondering if I could submit a feature request, or if you think this is a security issue?  The containers involved for me appear to have some dependencies on loopback and binding on ipv6 in a way that I'm unable to force bind them to ipv4.  To address:
Specifically I created a replacement container network to enable ipv6 with a private address space (I made a new one and did that).  The rules are all default all DROP, but I specifically set allows on lo for ipv6 only, replicating what you have already for ipv4:
ip6tables -A INPUT -i lo -j ACCEPT
ip6tables -A OUTPUT -o lo -j ACCEPT

This should allow containers that reside in the vpn container network to function when they require ipv6 loopback and translation.  It solved my issue, and on it's face I don't *think* I've introduced a security issue, but I will wait for the expert(s) to opine.
 

how do you disable auth for socks proxy?

Xteve WebUI Inaccessible via LAN (net=container:privoxyvpn) - Stream Works, UI Blocked (Port 34400)

Help provided by Gemini

I would be extremely grateful if someone can help with this, or provide a solution/recommendation for something like the xTeVe container that can reliably run through privoxyvpn.

Edit: I should mention I also tried Threadfin, and this resulted in the same issue where I couldn't access the WebUI once I routed through privoxyvpn.

I have configured the xteve container to use the network stack of binhex-privoxyvpn (i.e., --net=container:binhex-privoxyvpn). The core function—Xteve's IPTV stream—works perfectly and is correctly routed through the VPN. However, the WebUI at http://192.168.1.2:34400/web/ is completely inaccessible via the LAN. I receive a connection timeout/refused error.

This strongly suggests a firewall (IPTables) rule is blocking LAN-to-container access on port 34400, despite all documented settings being correct.

Container Configuration Details

1. binhex-privoxyvpn (VPN Container) Settings

Variable	Value	Purpose
Network Type	Bridge	(Correct for VPN container)
LAN_NETWORK	192.168.1.0/24, 172.17.0.0/16, 10.253.0.0/24	Includes LAN, Docker Bridge, and WireGuard ranges.
ENABLE_PRIVOXY	yes	Confirmed set to yes to enable LAN access to bound containers.
VPN_INPUT_PORTS	..., 34400, 5004	Explicitly includes Xteve's ports for forwarding.
VPN_OUTPUT_PORTS	..., 34400, 5004	Also includes Xteve's ports.
Other Services	Prowlarr and qBittorrent are also running successfully on this VPN container's network stack.	This confirms the VPN is functional.

2. xteve (Client Container) Settings

Variable	Value	Rationale
Network Type	Container: binhex-privoxyvpn	Correct for routing through the VPN.
Port Mappings	None (0)	Confirmed removed (no Host:Container port entries for 34400/5004).
Log Output	Web interface is running on http://172.17.0.4:34400/web/	Confirms Xteve is running on the internal Docker Bridge network.

Troubleshooting Steps Taken (Did NOT Work)

I have exhausted all known fixes, including low-level system resets:

• Verified all configuration variables (LAN_NETWORK, ENABLE_PRIVOXY, VPN_INPUT_PORTS) are correctly set.

• Confirmed Port Mappings were removed from the xteve container.

• Attempted the Bridge/Revert fix: Temporarily switched Xteve to Bridge mode, added ports, confirmed access, switched back to Container mode, and removed ports. No change.

• Performed a full Docker and IPTables reset: Stopped Docker, ran iptables --flush, iptables -t nat --flush, and iptables -X (and ip6tables equivalents), then re-enabled Docker. No change.

• Attempted Manual URL Access: Tried accessing http://192.168.1.2:34400/web/ directly. No change.

Given that the Xteve stream works (VPN is routed) and the WebUI is inaccessible (LAN is blocked), what specific, non-standard IPTables chain or rule might be blocking traffic from the 192.168.1.x LAN to the internal 172.17.0.4:34400 path, which is managed by the binhex-privoxyvpn container? Is there a known Unraid-specific bug or a custom kernel setting that interferes with this container-to-host forwarding?

Edited December 14, 2025Dec 14 by Hindsy
Clarification this wasn't exclusive to xteve

After updating to newest version I'm having problems starting up the docker. It gets stuck on "[info] Applying chown to paths '/etc/privoxy /home/nobody'..."

Full log

Created by...

___. .__ .__

\_ |__ |__| ____ | |__ ____ ___ ___

| __ \| |/ \| | \_/ __ \\ \/ /

| \_\ \ | | \ Y \ ___/ > <

|___ /__|___| /___| /\___ >__/\_ \

\/ \/ \/ \/ \/

https://hub.docker.com/u/binhex/

2026-03-03 21:59:01.358880 [info] Host is running unRAID

2026-03-03 21:59:01.393153 [info] System information: Linux f63f64a8e7bd 6.12.54-Unraid #1 SMP PREEMPT_DYNAMIC Tue Oct 21 15:58:46 PDT 2025 x86_64 GNU/Linux

2026-03-03 21:59:01.444165 [info] Image architecture: 'amd64'

2026-03-03 21:59:01.481001 [info] Application name: 'privoxyvpn'

2026-03-03 21:59:01.507793 [info] Base image release tag: '2026012601'

2026-03-03 21:59:01.535600 [info] Application image release tag: '4.1.0-1-01'

2026-03-03 21:59:01.567760 [info] PUID defined as '99'

2026-03-03 21:59:01.600647 [info] User 'nobody' already has UID '99', skipping usermod

2026-03-03 21:59:01.626485 [info] PGID defined as '100'

2026-03-03 21:59:01.654569 [info] Group 'users' already has GID '100', skipping groupmod

2026-03-03 21:59:01.680195 [info] UMASK defined as '000'

2026-03-03 21:59:01.708743 [info] Permissions file '/config/perms.txt' exists, skipping setting ownership and permissions on '/config' and '/data'

2026-03-03 21:59:01.745689 [info] Deleting files in /tmp (non recursive)...

2026-03-03 21:59:01.783134 [info] VPN_ENABLED defined as 'yes'

2026-03-03 21:59:01.814859 [info] VPN_CLIENT defined as 'wireguard'

2026-03-03 21:59:01.847386 [info] VPN_PROV defined as 'pia'

2026-03-03 21:59:01.884469 [info] VPN_CONFIG not defined (wireguard config doesnt file exists), defaulting to '/config/wireguard/wg0.conf'

2026-03-03 21:59:01.913402 [info] VPN_REMOTE_SERVER not defined (wireguard config doesnt file exists), defaulting to 'nl-amsterdam.privacy.network'

2026-03-03 21:59:01.941484 [info] VPN_REMOTE_PORT not defined (wireguard config file doesnt exists), defaulting to '1337'

2026-03-03 21:59:01.967635 [info] VPN_DEVICE_TYPE defined as 'wg0'

2026-03-03 21:59:01.997104 [info] VPN_REMOTE_PROTOCOL defined as 'udp'

2026-03-03 21:59:02.028474 [info] USERSPACE_WIREGUARD defined as 'no'

2026-03-03 21:59:02.061099 [info] NAME_SERVERS defined as '1.1.1.1,1.0.0.1'

2026-03-03 21:59:02.099491 [debug] iptables default policies available, setting policy to drop...

2026-03-03 21:59:02.132553 [debug] ip6tables default policies available, setting policy to drop...

2026-03-03 21:59:02.213407 [debug] DNS operational, we can resolve name 'nl-amsterdam.privacy.network' to address '212.56.48.14 212.56.48.28 212.56.48.36'

2026-03-03 21:59:02.273876 [debug] DNS operational, we can resolve name 'www.privateinternetaccess.com' to address '172.64.147.163 104.18.40.93'

2026-03-03 21:59:02.337412 [debug] DNS operational, we can resolve name 'piaproxy.net' to address '172.64.150.50 104.18.37.206'

2026-03-03 21:59:02.398532 [debug] DNS operational, we can resolve name 'serverlist.piaservers.net' to address '104.18.159.201 104.19.240.167'

2026-03-03 21:59:02.442892 [debug] Showing name servers in '/etc/resolv.conf' before overwrite from NAME_SERVERS...

2026-03-03 21:59:02.472259 [debug] # Generated by Docker Engine.

2026-03-03 21:59:02.472300 [debug] # This file can be edited; Docker Engine will not make further changes once it

2026-03-03 21:59:02.472313 [debug] # has been modified.

2026-03-03 21:59:02.472325 [debug]

2026-03-03 21:59:02.472335 [debug] nameserver 192.168.1.1

2026-03-03 21:59:02.472345 [debug] search fritz.box

2026-03-03 21:59:02.472355 [debug]

2026-03-03 21:59:02.472365 [debug] # Based on host file: '/etc/resolv.conf' (legacy)

2026-03-03 21:59:02.472375 [debug] # Overrides: []

2026-03-03 21:59:02.507037 [debug] Showing name servers in '/etc/resolv.conf' after overwrite from NAME_SERVERS...

2026-03-03 21:59:02.535676 [debug] nameserver 1.1.1.1

2026-03-03 21:59:02.535724 [debug] nameserver 1.0.0.1

2026-03-03 21:59:02.767449 [debug] Docker interface name, Gateway interface name, Gateway IP, Docker interface IP, Subnet mask and CIDR are defined as 'eth0,eth0,172.17.0.1,172.17.0.3,255.255.0.0,172.17.0.0/16'

2026-03-03 21:59:02.860939 [info] LAN_NETWORK defined as '192.168.1.0/24,100.95.246.0/24'

2026-03-03 21:59:02.907811 [info] LAN_NETWORK exported as '192.168.1.0/24,100.95.246.0/24'

2026-03-03 21:59:02.939398 [info] VPN_USER defined as 'user'

2026-03-03 21:59:02.971447 [info] VPN_PASS defined as 'password'

2026-03-03 21:59:02.997830 [info] STRICT_PORT_FORWARD defined as 'yes'

2026-03-03 21:59:03.031129 [info] VPN_INPUT_PORTS not defined (via -e VPN_INPUT_PORTS), skipping allow for custom incoming ports

2026-03-03 21:59:03.063192 [info] VPN_OUTPUT_PORTS not defined (via -e VPN_OUTPUT_PORTS), skipping allow for custom outgoing ports

2026-03-03 21:59:03.091032 [info] ENABLE_STARTUP_SCRIPTS defined as 'no'

2026-03-03 21:59:03.121915 [info] ENABLE_SOCKS defined as 'yes'

2026-03-03 21:59:03.153617 [info] ENABLE_PRIVOXY defined as 'yes'

2026-03-03 21:59:03.184508 [info] SOCKS_USER defined as 'socksuser'

2026-03-03 21:59:03.214592 [info] SOCKS_PASS defined as 'sockspassword'

2026-03-03 21:59:03.243529 [info] Applying chown to paths '/etc/privoxy /home/nobody'...