13 hours ago, binhex said:

OK so here's the thing, both wireguard and openvpn use the exact same code to get a working incoming port from PIA, so if it works on wireguard then it should also work on openvpn, and if that's the case then i would assume whatever issue you did have has now been fixed (pia related perhaps?).

Well... Maybe since I completely screwed up the docker when the upgrade initially would not run, and I had to completely rebuild my container from scratch, maybe my situation is similar to YDouble?

On 5/23/2025 at 6:04 AM, YDouble said:

I also had this problem (using PIA), reverted back to v2.1.1-8-03 and I was able to access the UI.

I created a new container with latest version and different ports, and that works!
Deleted my old container and I'm using the new one with the old port numbers.

It seems you are on the right track with RainDess'r report though maybe?

At this point I am happy to try anything that may help you with diagnostics, but my docker is again running fine.

Edited May 25, 20251 yr by craigr

20 hours ago, craigr said:

At this point I am happy to try anything that may help you with diagnostics, but my docker is again running fine.

you could try switching back to openvpn, ensure you are on latest image, does it now work?

Hello, I have been having this issue for a while, but never really needed to fix it until now. I use the delugevpn with PIA and WireGuard, and I am not sure when it started, but I am never able to get into the WebUI with the standard link. The part that confuses me is that I used to use Nginx Proxy Manager to be able to access some docker containers from outside my network. The link that I would use to access Deluge works with no issue, and I can do anything in the WebUI just fine using that link, but if I want to use the regular WebUI link directly in unraid, it never loads. Does anyone have any idea for why this might be, and suggestions to fix it?

5 hours ago, dog1259 said:

The part that confuses me is that I used to use Nginx Proxy Manager to be able to access some docker containers from outside my network. The link that I would use to access Deluge works with no issue, and I can do anything in the WebUI just fine using that link, but if I want to use the regular WebUI link directly in unraid, it never loads.

Sounds like your LAN_NETWORK option is not set correctly, see Q4 here for a start on how to configure it: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

I just wanted to add my experience. I was running into similar issues with qBit. Specifically:

"2025-05-27 17:58:42,842 DEBG 'start-script' stdout output:

[info] Port forwarding is enabled

[info] Checking endpoint 'ca-ontario.privacy.network' is port forward enabled...

2025-05-27 17:58:57,943 DEBG 'start-script' stdout output:

[warn] PIA endpoint API 'https://serverlist.piaservers.net/vpninfo/servers/v4' currently down, skipping endpoint port forward check

I reverted back to binhex/arch-qbittorrentvpn:4.6.5-1-06. After that, it started working immediately. I didn't pick that one for any particular reason, just picked an older repo to test.

22 hours ago, Jorgen said:

Sounds like your LAN_NETWORK option is not set correctly, see Q4 here for a start on how to configure it: https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Thank you, I never noticed on initial setup that one of the numbers in that field was off. Finally have it fixed.

I've been having some odd issues lately. I've had this container running for many years now without issues. I've made no configuration changes to deluge itself, and just been letting it chug along as normal. I updated to unraid 7.x a few weeks back and i had some other issues related to mover that I've since resolved. I did have issues however with deluge and krusader where the webui password just stopped working. The UI loaded, but my pw wouldn't work. I toyed with it and randomly it started working after a reboot. I forgot about it and moved on..

Well recently my wife asked me about a show, and I noticed my deluge had some auth errors., I tried to log into the webui and was getting pw incorrect. I checked the template config, it all looked normal, tried restarting the docker container, but still having issues. I checked out my config, and noticed my core.conf file appears to have been reset to the default template and i can log into the webui using the deluge default pw.

The problem is ofc that all the settings / folder locations and actions are wrong. I have a backup from 6 years back that is accurate, so I stopped deluge container, deleted the core.conf file and copied this back up in and restarted it. It came up, but my pw still failed. Checking the core.conf file it was overwritten with the default config again. Checking the log folder I'm seeing this:

00:17:12 [WARNING ][deluge.config :478 ] Unable to open config file: /config/core.conf because: list index out of range

I'm not sure is wrong with the file, it looks correct, it's valid json (for the .conf file at least) with no missing/extra comma's, etc. but clearly something is giving it problems. I'm not sure why this is suddenly an issue now when I have legitimately not made any configuration changes outside of updating the unraid OS about 2-3 weeks ago.

After updating from unraid 7.1.0rc4 to 7.1.2, I'm not able to connect to my deluge webui anymore. Any one know what the problem could be?

If I roll back, I can access deluge webui again.

Edited June 1, 20251 yr by sabonim38

Hello,

Having an issue again using Deluge with a VPN. I have removed and reinstall Deluge as strike told me in this post :

It worked fine after reinstalling but today Deluge stopped working and it seems to be a DNS issue. I tried to reinstall again, tried many different VPN servers, changed the DNS server in the configuration, nothing work.

Anyone got this kind of problem? Is there anything else I could do in order to use Deluge with my VPN?

Thank you.

supervisord - 2025-06-01.logCommand execution - 2025-06-01.txt

Edited June 1, 20251 yr by frcouture

2 hours ago, frcouture said:

Hello,

Having an issue again using Deluge with a VPN. I have removed and reinstall Deluge as strike told me in this post :

It worked fine after reinstalling but today Deluge stopped working and it seems to be a DNS issue. I tried to reinstall again, tried many different VPN servers, changed the DNS server in the configuration, nothing work.

Anyone got this kind of problem? Is there anything else I could do in order to use Deluge with my VPN?

Thank you.

supervisord - 2025-06-01.logCommand execution - 2025-06-01.txt

def does look dns related, ensure you are not blocking dns, check things like pihole, pfsense/opnsense, also Please see Q36 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

Edit: SOLVED - I didn't re-configure privoxy when I re-created the container from the previous issues

This container is driving me bonkers lately. It stopped working randomly and I disabled tailscale/magicDNS and it was then able to connect to the VPN again and I could access the webgui once again.

For some reason now, Radarr/Sonarr/Lidarr/Readarr (all binhex btw) can no longer communicate with the container.

I'm using macvlan with docker vlan 11/IP Subnet 10.10.11.0/24 (all containers above are on this vlan). I can acces the webgui from vlan10/IP subnet 10.10.10.0/24 without issue. But Radarr/Sonarr etc logs show "connection refused" when testing the connection to deluge (I've tried re-creating from scratch) but running "curl http://10.10.11.78:8112" from inside sonarr/radarr returns the properties of the deluge webgui.

Lan_network is set to: 10.0.0.0/8

VPN is PIA using openvpn

password has been reset and tested

Label plugin is enabled (also tried removing labels)

radarr logs is showing: Connection refused (10.10.11.78:8118) even though 8112 is in the port list by default (and what deluge is using). so it seems that the other binhex containers are ignoring the 8112 set in the download client config and going to 8118

Edited June 2, 20251 yr by opticon

I am hoping someone can help. I restarted my binhex-delugevpn docker and am now unable to get access to the WebUI.

I have had this problem a few times recently and usually restarted the physical server cures the issue... but the machine is remote and I am unable to restart the server today, so thought I would see if anyone can help?

Not sure where to start diagnosing this... I have looked at the log file but am not sure what to look for. I am using PIA and have checked that the credentials are correct.

Can anyone help where to start in trying to sort this out?

Thanks

Never had an issue with deluge until today - wondering if someone could help - restarted server and cannot get the UI to come back up. Using PIA, checking the logs shows this ? Any thoughts on what the culprit might be? I haven't done any changes to the setup, username and PW for pia still works fine etc as well. I appreciate all of the help!

2025-06-03 23:52:21,007 DEBG 'start-script' stdout output:

[info] Failed on last attempt, attempting to get external IP using 'http://whatismyip.akamai.com'...

2025-06-03 23:52:21,016 DEBG 'start-script' stdout output:

[info] Failed on last attempt, attempting to get external IP using 'https://ifconfig.co/ip'...

2025-06-03 23:52:21,026 DEBG 'start-script' stdout output:

[info] Failed on last attempt, attempting to get external IP using 'https://showextip.azurewebsites.net'...

2025-06-03 23:52:21,035 DEBG 'start-script' stdout output:

[warn] Cannot determine external IP address, performing tests before setting to '127.0.0.1'...

[info] Show name servers defined for container

2025-06-03 23:52:21,036 DEBG 'start-script' stdout output:

nameserver 84.200.69.80

nameserver 37.235.1.174

nameserver 1.1.1.1

nameserver 37.235.1.177

nameserver 84.200.70.40

nameserver 1.0.0.1

2025-06-03 23:52:21,036 DEBG 'start-script' stdout output:

[info] Show contents of hosts file

2025-06-03 23:52:21,037 DEBG 'start-script' stdout output:

127.0.0.1 localhost

::1 localhost ip6-localhost ip6-loopback

fe00::0 ip6-localnet

ff00::0 ip6-mcastprefix

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

172.17.0.2 300eae012846

piavpn information next

[warn] Unable to successfully download PIA json to generate token from URL 'https://www.privateinternetaccess.com/gtoken/generateToken'

[info] 12 retries left

2025-06-03 23:56:32,490 DEBG 'start-script' stdout output:

2025-06-03 23:56:32 Bad compression stub decompression header byte: 42

2025-06-03 23:56:21 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (some id starting with AES). OpenVPN ignores --cipher for cipher negotiations.

@SaberTreasures

This is very similar to my problem... I am using PIA too and it was all working fine till I restarted my delugevpn docker. Now I cant get on the WebUI.

In case it means anything, this is some of the output in the log file...

2025-06-04 09:28:37,668 DEBG 'start-script' stdout output:

2025-06-04 09:28:37 WARNING: file 'credentials.conf' is group or others accessible

2025-06-04 09:28:37 OpenVPN 2.6.14 [git:makepkg/f588592ee6c6323b+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Apr 2 2025

2025-06-04 09:28:37 library versions: OpenSSL 3.5.0 8 Apr 2025, LZO 2.10

2025-06-04 09:28:37 DCO version: N/A

2025-06-04 09:28:38,668 DEBG 'start-script' stdout output:

2025-06-04 09:28:38 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2025-06-04 09:28:38,670 DEBG 'start-script' stdout output:

2025-06-04 09:28:38 TCP/UDP: Preserving recently used remote address: [AF_INET]156.146.63.171:1198

2025-06-04 09:28:38 UDPv4 link local: (not bound)

2025-06-04 09:28:38 UDPv4 link remote: [AF_INET]156.146.63.171:1198

2025-06-04 09:28:38,800 DEBG 'start-script' stdout output:

2025-06-04 09:28:38 [paris414] Peer Connection Initiated with [AF_INET]156.146.63.171:1198

2025-06-04 09:28:38,812 DEBG 'start-script' stdout output:

2025-06-04 09:28:38 TUN/TAP device tun0 opened

2025-06-04 09:28:38 net_iface_mtu_set: mtu 1500 for tun0

2025-06-04 09:28:38,812 DEBG 'start-script' stdout output:

2025-06-04 09:28:38 net_iface_up: set tun0 up

2025-06-04 09:28:38 net_addr_v4_add: 10.14.112.75/24 dev tun0

2025-06-04 09:28:38 /root/openvpnup.sh tun0 1500 0 10.14.112.75 255.255.255.0 init

2025-06-04 09:28:38,821 DEBG 'start-script' stdout output:

2025-06-04 09:28:38 Initialization Sequence Completed

2025-06-04 09:28:48,959 DEBG 'start-script' stdout output:

2025-06-04 09:28:48 Bad compression stub decompression header byte: 42

2025-06-04 09:28:59,022 DEBG 'start-script' stdout output:

2025-06-04 09:28:59 Bad compression stub decompression header byte: 42

2025-06-04 09:29:09,492 DEBG 'start-script' stdout output:

2025-06-04 09:29:09 Bad compression stub decompression header byte: 42

2025-06-04 09:29:19,503 DEBG 'start-script' stdout output:

2025-06-04 09:29:19 Bad compression stub decompression header byte: 42

2025-06-04 09:29:29,524 DEBG 'start-script' stdout output:

2025-06-04 09:29:29 Bad compression stub decompression header byte: 42

2025-06-04 09:29:39,072 DEBG 'start-script' stdout output:

2025-06-04 09:29:39 [paris414] Inactivity timeout (--ping-restart), restarting

2025-06-04 09:29:39,072 DEBG 'start-script' stdout output:

2025-06-04 09:29:39 net_addr_v4_del: 10.14.112.75 dev tun0

2025-06-04 09:29:39,081 DEBG 'start-script' stdout output:

2025-06-04 09:29:39 /root/openvpndown.sh tun0 1500 0 10.14.112.75 255.255.255.0 init

2025-06-04 09:29:39,091 DEBG 'start-script' stdout output:

2025-06-04 09:29:39 SIGHUP[soft,ping-restart] received, process restarting

2025-06-04 09:29:39,092 DEBG 'start-script' stdout output:

2025-06-04 09:29:39 DEPRECATED OPTION: --cipher set to 'aes-128-cbc' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.

2025-06-04 09:29:39 WARNING: file 'credentials.conf' is group or others accessible

2025-06-04 09:29:39,092 DEBG 'start-script' stdout output:

2025-06-04 09:29:39 OpenVPN 2.6.14 [git:makepkg/f588592ee6c6323b+] x86_64-pc-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [PKCS11] [MH/PKTINFO] [AEAD] [DCO] built on Apr 2 2025

2025-06-04 09:29:39 library versions: OpenSSL 3.5.0 8 Apr 2025, LZO 2.10

2025-06-04 09:29:39 DCO version: N/A

2025-06-04 09:29:40,093 DEBG 'start-script' stdout output:

2025-06-04 09:29:40 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts

2025-06-04 09:29:40,094 DEBG 'start-script' stdout output:

2025-06-04 09:29:40 TCP/UDP: Preserving recently used remote address: [AF_INET]104.19.240.167:1198

2025-06-04 09:29:40 UDPv4 link local: (not bound)

2025-06-04 09:29:40 UDPv4 link remote: [AF_INET]104.19.240.167:1198

2025-06-04 09:29:44,533 DEBG 'start-script' stdout output:

[info] Attempting to get external IP using 'http://checkip.amazonaws.com'...

2025-06-04 09:29:44,554 DEBG 'start-script' stdout output:

[info] Failed on last attempt, attempting to get external IP using 'http://whatismyip.akamai.com'...

2025-06-04 09:29:44,577 DEBG 'start-script' stdout output:

[info] Failed on last attempt, attempting to get external IP using 'https://ifconfig.co/ip'...

2025-06-04 09:29:44,596 DEBG 'start-script' stdout output:

[info] Failed on last attempt, attempting to get external IP using 'https://showextip.azurewebsites.net'...

2025-06-04 09:29:44,615 DEBG 'start-script' stdout output:

[warn] Cannot determine external IP address, performing tests before setting to '127.0.0.1'...

[info] Show name servers defined for container

2025-06-04 09:29:44,617 DEBG 'start-script' stdout output:

nameserver 84.200.69.80

nameserver 37.235.1.174

nameserver 1.1.1.1

nameserver 37.235.1.177

nameserver 84.200.70.40

nameserver 1.0.0.1

nameserver 8.8.8.8

2025-06-04 09:29:44,617 DEBG 'start-script' stdout output:

[info] Show contents of hosts file

2025-06-04 09:29:44,619 DEBG 'start-script' stdout output:

127.0.0.1 localhost

::1 localhost ip6-localhost ip6-loopback

fe00::0 ip6-localnet

ff00::0 ip6-mcastprefix

ff02::1 ip6-allnodes

ff02::2 ip6-allrouters

172.17.0.2 f4606343ff9c

156.146.63.171 france.privacy.network

172.64.147.163 www.privateinternetaccess.com

104.18.159.201 serverlist.piaservers.net

2025-06-04 09:29:44,622 DEBG 'start-script' stdout output:

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

2025-06-04 09:29:44,622 DEBG 'start-script' stdout output:

[info] Port forwarding is enabled

[info] Checking endpoint 'france.privacy.network' is port forward enabled...

2025-06-04 09:29:44,725 DEBG 'start-script' stdout output:

[info] PIA endpoint 'france.privacy.network' is in the list of endpoints that support port forwarding shown below:-

2025-06-04 09:29:44,836 DEBG 'start-script' stdout output:

[info] List of PIA endpoints that support port forwarding:-

2025-06-04 09:29:44,836 DEBG 'start-script' stdout output:

[info] japan-2.privacy.network

[info] ec-ecuador-pf.privacy.network

[info] pt.privacy.network

[info] israel.privacy.network

[info] br.privacy.network

[info] austria.privacy.network

[info] ireland.privacy.network

[info] italy.privacy.network

[info] philippines.privacy.network

[info] au-sydney.privacy.network

[info] au-brisbane-pf.privacy.network

[info] bahamas.privacy.network

[info] panama.privacy.network

[info] nl-netherlands-so.privacy.network

[info] ca-toronto.privacy.network

[info] tr.privacy.network

[info] sweden-2.privacy.network

[info] uk-manchester.privacy.network

[info] italy-2.privacy.network

[info] sanjose.privacy.network

[info] georgia.privacy.network

[info] slovenia.privacy.network

[info] pe-peru-pf.privacy.network

2025-06-04 09:29:44,836 DEBG 'start-script' stdout output:

[info] brussels.privacy.network

[info] de-frankfurt.privacy.network

[info] ca-ontario.privacy.network

[info] japan.privacy.network

[info] es-valencia.privacy.network

[info] ee.privacy.network

[info] ro.privacy.network

[info] lv.privacy.network

[info] mongolia.privacy.network

[info] cyprus.privacy.network

[info] sofia.privacy.network

[info] uk-london.privacy.network

[info] uk-southampton.privacy.network

[info] venezuela.privacy.network

[info] au-australia-so.privacy.network

[info] ca-vancouver.privacy.network

[info] spain.privacy.network

[info] vietnam.privacy.network

[info] fi-2.privacy.network

[info] uy-uruguay-pf.privacy.network

[info] macau.privacy.network

[info] saudiarabia.privacy.network

[info] dz.privacy.network

[info] za.privacy.network

[info] kazakhstan.privacy.network

[info] in.privacy.network

[info] ad.privacy.network

[info] al.privacy.network

[info] greenland.privacy.network

[info] au-adelaide-pf.privacy.network

[info] aus-perth.privacy.network

[info] no.privacy.network

[info] srilanka.privacy.network

[info] nigeria.privacy.network

[info] fi.privacy.network

[info] kr-south-korea-pf.privacy.network

2025-06-04 09:29:44,837 DEBG 'start-script' stdout output:

[info] cambodia.privacy.network

[info] sk.privacy.network

[info] ca-ontario-so.privacy.network

[info] gt-guatemala-pf.privacy.network

[info] poland.privacy.network

[info] np-nepal-pf.privacy.network

[info] qatar.privacy.network

[info] liechtenstein.privacy.network

[info] nz.privacy.network

[info] lu.privacy.network

[info] morocco.privacy.network

[info] hungary.privacy.network

[info] uk-2.privacy.network

[info] gr.privacy.network

[info] mexico.privacy.network

[info] egypt.privacy.network

[info] ua.privacy.network

[info] malta.privacy.network

[info] czech.privacy.network

[info] ca-montreal.privacy.network

[info] china.privacy.network

[info] sg.privacy.network

[info] jakarta.privacy.network

[info] nl-amsterdam.privacy.network

[info] aus-melbourne.privacy.network

[info] de-germany-so.privacy.network

[info] hk.privacy.network

[info] lt.privacy.network

2025-06-04 09:29:44,837 DEBG 'start-script' stdout output:

[info] santiago.privacy.network

[info] swiss.privacy.network

[info] monaco.privacy.network

[info] ba.privacy.network

[info] zagreb.privacy.network

[info] mk.privacy.network

[info] sweden.privacy.network

[info] ar.privacy.network

[info] bangladesh.privacy.network

[info] ae.privacy.network

[info] is.privacy.network

[info] taiwan.privacy.network

[info] denmark.privacy.network

[info] montenegro.privacy.network

[info] man.privacy.network

[info] france.privacy.network

[info] kualalumpur.privacy.network

[info] yerevan.privacy.network

[info] bo-bolivia-pf.privacy.network

[info] md.privacy.network

[info] rs.privacy.network

[info] denmark-2.privacy.network

[info] bogota.privacy.network

[info] de-berlin.privacy.network

2025-06-04 09:29:45,950 DEBG 'start-script' stdout output:

[info] Attempting to get external IP using 'http://checkip.amazonaws.com'...

2025-06-04 09:29:45,973 DEBG 'start-script' stdout output:

[info] Failed on last attempt, attempting to get external IP using 'http://whatismyip.akamai.com'...

2025-06-04 09:29:45,993 DEBG 'start-script' stdout output:

[info] Failed on last attempt, attempting to get external IP using 'https://ifconfig.co/ip'...

2025-06-04 09:29:46,015 DEBG 'start-script' stdout output:

[info] Failed on last attempt, attempting to get external IP using 'https://showextip.azurewebsites.net'...

2025-06-04 09:29:46,035 DEBG 'start-script' stdout output:

[warn] Cannot determine external IP address, performing tests before setting to '127.0.0.1'...

[info] Show name servers defined for container

2025-06-04 09:29:46,036 DEBG 'start-script' stdout output:

nameserver 84.200.69.80

nameserver 37.235.1.174

nameserver 1.1.1.1

nameserver 37.235.1.177

nameserver 84.200.70.40

nameserver 1.0.0.1

nameserver 8.8.8.8

2025-06-04 09:29:46,037 DEBG 'start-script' stdout output:

[info] Show contents of hosts file

1 hour ago, SliMat said:

nameserver 84.200.69.80

nameserver 37.235.1.174

nameserver 1.1.1.1

nameserver 37.235.1.177

nameserver 84.200.70.40

nameserver 1.0.0.1

nameserver 8.8.8.8

try changing NAME_SERVERS to have a value of 1.1.1.1,1.0.0.1

6 hours ago, SaberTreasures said:

nameserver 84.200.69.80

nameserver 37.235.1.174

nameserver 1.1.1.1

nameserver 37.235.1.177

nameserver 84.200.70.40

nameserver 1.0.0.1

same, try changing NAME_SERVERS to have a value of 1.1.1.1,1.0.0.1

9 hours ago, binhex said:

try changing NAME_SERVERS to have a value of 1.1.1.1,1.0.0.1

Thanks for the response - I tried this and am still unable to access WebUI... I have also rebooted the physical UnRAID server as previously when I have had this issue it fixed the problem.

Attached is the log - any help appreciated as it has been offline for a couple of days now :-(

Thanks

binhex delugevpn log.txt

8 minutes ago, SliMat said:

Thanks for the response - I tried this and am still unable to access WebUI... I have also rebooted the physical UnRAID server as previously when I have had this issue it fixed the problem.

Attached is the log - any help appreciated as it has been offline for a couple of days now :-(

Thanks

binhex delugevpn log.txt

from your log:- 2025-06-04 20:27:23 [UNDEF] Inactivity timeout (--ping-restart), restarting

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

6 minutes ago, binhex said:

from your log:- 2025-06-04 20:27:23 [UNDEF] Inactivity timeout (--ping-restart), restarting

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

Many thanks @binhex - I appreciate your time. Since the post above, I forced an update and restarted - I have attached the log as on lines 252 & 254 I see;

2025-06-04 20:49:47 sitnl_send: rtnl: generic error (-101): Network is unreachable

I will in the meantime look into creating a new ovpn config file with new server details in case something has changed.

I will confirm if the new ovpn config file fixes it.

binhex delugevpn log2.txt

Thanks @binhex

I downloaded new ovpn config file and it has started and allowed me to connect to the UI 😁

I do have one question, which someone may be able to help with... as mentioned before, I am using Private Internet Access and from the delugevpn log, I see...

2025-06-04 09:29:44,836 DEBG 'start-script' stdout output:

[info] List of PIA endpoints that support port forwarding:-

2025-06-04 09:29:44,836 DEBG 'start-script' stdout output:

[info] japan-2.privacy.network

[info] ec-ecuador-pf.privacy.network

[info] pt.privacy.network

[info] israel.privacy.network

[info] br.privacy.network

[info] austria.privacy.network

[info] ireland.privacy.network

[info] italy.privacy.network

[info] philippines.privacy.network

[info] au-sydney.privacy.network

[info] au-brisbane-pf.privacy.network

[info] bahamas.privacy.network

[info] panama.privacy.network

[info] nl-netherlands-so.privacy.network

[info] ca-toronto.privacy.network

[info] tr.privacy.network

[info] sweden-2.privacy.network

[info] uk-manchester.privacy.network

[info] italy-2.privacy.network

[info] sanjose.privacy.network

[info] georgia.privacy.network

[info] slovenia.privacy.network

[info] pe-peru-pf.privacy.network

But from the PIA list of ovpn config files I dont see any endpoints which match above, they are all similar to this...

So, none of them are called xxxxxxxxx.privacy.network - so from the list of endpoints which support port forwarding it lists - nl-netherlands-so.privacy.network, in the list of ovpn config files from PIA it has one called netherlands.ovpn, so I am using this one... is this the correct endpoint which delugevpn lists as supporting port forwarding, or is there another list somewhere which I havent found?

Alternatively, how do I test whether the endpoint I am using supports port forwarding?

But, regardless of this, many thanks for your help.

15 hours ago, binhex said:

same, try changing NAME_SERVERS to have a value of 1.1.1.1,1.0.0.1

Hey There @binhex , I appreciate all of your time and help!

I have tried this and it did not help. I then tried what @SliMat did and that also did not help (I updated .crt / .pem / .ovpn files). I then tried changing them to a different strong connection from pia (instead of ca.rsa.2048.crt did the ca.rsa.4096.crt with associated pem and ovpn), but that did not help.

One thing that comes up alot in the log is bad compression header byte 42, idk if that is anything really or not. Let me know what I can provide outside of the above and I certainly will.

Would it help if I switched VPN's at all? I've had PIA for a long while (years) but my membership is about to renew so would be a good time to switch if that is the culprit lol!

Thanks again for all of the help.

10 hours ago, SliMat said:

But from the PIA list of ovpn config files I dont see any endpoints which match above

the listed endpoints in the log are the actual remote names you would use to connect if you wanted to edit your ovpn ocnfig file and replace the 'remote' line with another endpoint, whereas the ovpn config filenames are just the locations of the endpoints, e.g. netherlands.ovpn.

10 hours ago, SliMat said:

so I am using this one.

yes, netherlands.ovpn config file will be for nl-netherlands-so.privacy.network, if you want to confirm then open the ovpn file with notepad and look at the 'remote' line

10 hours ago, SliMat said:

Alternatively, how do I test whether the endpoint I am using supports port forwarding?

if you have set STRICT_PORT_FORWARD to 'yes' then you wll not be able to access the web ui unless you are connected to an endpoint that supports port forwarding (incoming port will be assigned).

6 hours ago, SaberTreasures said:

Hey There @binhex , I appreciate all of your time and help!

I have tried this and it did not help. I then tried what @SliMat did and that also did not help (I updated .crt / .pem / .ovpn files). I then tried changing them to a different strong connection from pia (instead of ca.rsa.2048.crt did the ca.rsa.4096.crt with associated pem and ovpn), but that did not help.

One thing that comes up alot in the log is bad compression header byte 42, idk if that is anything really or not. Let me know what I can provide outside of the above and I certainly will.

Would it help if I switched VPN's at all? I've had PIA for a long while (years) but my membership is about to renew so would be a good time to switch if that is the culprit lol!

Thanks again for all of the help.

I will need to see a log to help further, please see the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/help.md#unraid-users

11 hours ago, binhex said:

the listed endpoints in the log are the actual remote names you would use to connect if you wanted to edit your ovpn ocnfig file and replace the 'remote' line with another endpoint, whereas the ovpn config filenames are just the locations of the endpoints, e.g. netherlands.ovpn.

yes, netherlands.ovpn config file will be for nl-netherlands-so.privacy.network, if you want to confirm then open the ovpn file with notepad and look at the 'remote' line

if you have set STRICT_PORT_FORWARD to 'yes' then you wll not be able to access the web ui unless you are connected to an endpoint that supports port forwarding (incoming port will be assigned).

Perfect - many thanks for the help

On 5/23/2025 at 11:56 AM, binhex said:

LOVELY!, thanks for the feedback, I've been waiting on @craigr but he seems to of gone AFK on me :-), OK let's give it till the end of the weekend, hopefully we might get a couple more people who were seeing the issue chime in, if it looks good i shall merge into main.

Hey friend! No rush since I'm sure you're busy but I was curious if you were still thinking to drop this into the main branch at all. 🙏