23 minutes ago, Lignumaqua said:

Debug files as requested using 'latest'.supervisord.txtsabnzbdvpn_Command_Execution.txt

So i have added in the ability to assign an incoming port for all vpn images, reason why you might want this for sabnzbd (an application that does not require an incoming port) is in case you are sharing the vpn network with other containers that do require an incoming port, for instance deluge.
So you might be asking what has this got to do with your issue, well it looks like you have set STRICT_PORT_FORWARD to 'yes', from your log:-
2024-07-02 13:09:40.800309 [info] STRICT_PORT_FORWARD defined as 'yes'

This did nothing previously as sabnzbd did not require an incoming port, but with my change this setting actually does do something, if you set it to 'yes' (as you have done) you can only connect to endpoints which support port forwarding, your selected endpoint 'us-texas.privacy.network' does NOT support port forwarding, as can be seen from your log:-
[info] PIA endpoint 'us-texas.privacy.network' is NOT in the list of endpoints that support port forwarding shown below

So what's the fix?, either connect to an endpoint that does support port forwarding, check your log for details, or simply set STRICT_PORT_FORWARD to 'no'.

Here are my own files, I did not downgrade yet.  And for note, my STRICT_PORT_FORWARD is set to no.

 

supervisord - Copy.log Sabnzbd comman execution.txt

Edited July 2, 20242 yr by Lonewolf147

12 minutes ago, Lonewolf147 said:

Here are my own files, I did not downgrade yet.  And for note, my STRICT_PORT_FORWARD is set to no.

 

supervisord - Copy.log 2.71 kB · 0 downloads Sabnzbd comman execution.txt 1.32 kB · 0 downloads

OK yep this is def not related to STRICT_PORT_FORWARD, your issue looks to be name resolution related, can you try changing NAME_SERVERS to a value of '1.1.1.1', the ones you have listed are the defaults but it is possible one of the lesser known name server was having intermittent issues, or possibly that your router/firewall is blocking.

Changed it, but same issue.

supervisord - Copy.log

25 minutes ago, Lonewolf147 said:

Changed it, but same issue.

supervisord - Copy.log 2.28 kB · 1 download

OK can you check your firewall/router and ensure you are not blocking outbound port 53.

1 hour ago, binhex said:

OK can you check your firewall/router and ensure you are not blocking outbound port 53.

Looked through those, and I still don't see anything specifically blocking them (and I never programmed them to). Running netstat I see lots of references to port 53, with the TIME_WAIT status. 

3 hours ago, binhex said:

So what's the fix?, either connect to an endpoint that does support port forwarding, check your log for details, or simply set STRICT_PORT_FORWARD to 'no'.

Thank you - that did it! Now working fine with 'latest'.

10 hours ago, Lonewolf147 said:

Looked through those, and I still don't see anything specifically blocking them (and I never programmed them to). Running netstat I see lots of references to port 53, with the TIME_WAIT status. 

ok lets check iptables isn't blocking, can you do the following:-

1. start the container
2. left click container and click on 'console'
3. type 'iptables -S' and paste the result here.
    

And just for clarity here, i am unable to reproduce your issue so far, i have tried the same image (latest), with the same provider (pia) with the same endpoint (ca-toronto.privacy.network) and i see no name resolution issues, proof:-
 

\_ |__ |__| ____ |  |__   ____ ___  ___
 | __ \|  |/    \|  |  \_/ __ \\  \/  /
 | \_\ \  |   |  \   Y  \  ___/ >    <
 |___  /__|___|  /___|  /\___  >__/\_ \
     \/        \/     \/     \/      \/
   https://hub.docker.com/u/binhex/

2024-07-03 09:34:48.320018 [info] Host is running unRAID
2024-07-03 09:34:48.350510 [info] System information Linux 49f9190977ff 6.1.79-Unraid #1 SMP PREEMPT_DYNAMIC Fri Mar 29 13:34:03 PDT 2024 x86_64 GNU/Linux
2024-07-03 09:34:48.387028 [info] SHARED_NETWORK not defined (via -e SHARED_NETWORK), defaulting to 'no'
2024-07-03 09:34:48.423739 [info] PUID defined as '99'
2024-07-03 09:34:48.467732 [info] PGID defined as '100'
2024-07-03 09:34:48.524124 [info] UMASK defined as '000'
2024-07-03 09:34:48.558353 [info] Permissions already set for '/config'
2024-07-03 09:34:48.596441 [info] Deleting files in /tmp (non recursive)...
2024-07-03 09:34:48.647694 [info] VPN_ENABLED defined as 'yes'
2024-07-03 09:34:48.685685 [info] VPN_CLIENT defined as 'openvpn'
2024-07-03 09:34:48.721259 [info] VPN_PROV defined as 'pia'
2024-07-03 09:34:48.763101 [info] OpenVPN config file (ovpn extension) is located at /config/openvpn/pia-ng.ovpn
2024-07-03 09:34:48.836984 [info] VPN remote server(s) defined as 'ca-toronto.privacy.network,'
2024-07-03 09:34:48.870104 [info] VPN remote port(s) defined as '1197,'
2024-07-03 09:34:48.900562 [info] VPN remote protcol(s) defined as 'udp,'
2024-07-03 09:34:48.936538 [info] VPN_DEVICE_TYPE defined as 'tun0'
2024-07-03 09:34:48.971934 [info] VPN_OPTIONS not defined (via -e VPN_OPTIONS)
2024-07-03 09:34:49.008354 [info] NAME_SERVERS defined as '84.200.69.80,37.235.1.174,1.1.1.1,37.235.1.177,84.200.70.40,1.0.0.1'
2024-07-03 09:34:49.044967 [debug] iptables default policies available, setting policy to drop...
2024-07-03 09:34:49.084520 [debug] ip6tables default policies available, setting policy to drop...
2024-07-03 09:34:49.124388 [debug] Adding 84.200.69.80 to /etc/resolv.conf...
2024-07-03 09:34:49.162317 [debug] Adding 37.235.1.174 to /etc/resolv.conf...
2024-07-03 09:34:49.201432 [debug] Adding 1.1.1.1 to /etc/resolv.conf...
2024-07-03 09:34:49.236248 [debug] Adding 37.235.1.177 to /etc/resolv.conf...
2024-07-03 09:34:49.272821 [debug] Adding 84.200.70.40 to /etc/resolv.conf...
2024-07-03 09:34:49.307925 [debug] Adding 1.0.0.1 to /etc/resolv.conf...
2024-07-03 09:35:04.401025 [debug] DNS operational, we can resolve name 'ca-toronto.privacy.network' to address '179.61.197.191 191.96.36.67 191.96.36.71'
2024-07-03 09:35:19.493504 [debug] DNS operational, we can resolve name 'www.privateinternetaccess.com' to address '172.64.151.73 104.18.36.183'
2024-07-03 09:35:19.559160 [debug] DNS operational, we can resolve name 'serverlist.piaservers.net' to address '104.19.240.167 104.18.159.201'

 

EDIT - oh and BTW your openvpn config file is out of date, you should be connecting on port 1198 not port 1197 (as shown in your log), so please update your config files (not related to the name resolution issue).

1 hour ago, binhex said:

EDIT - oh and BTW your openvpn config file is out of date, you should be connecting on port 1198 not port 1197 (as shown in your log), so please update your config files (not related to the name resolution issue).

I'll do the rest of the testing after work today.

As for the openvpn config files, I'm using PIA's strong encryption file which uses port 1197

4 minutes ago, Lonewolf147 said:

I'll do the rest of the testing after work today.

As for the openvpn config files, I'm using PIA's strong encryption file which uses port 1197

Ahh ok fair enough, i hacked my openvpn cofig file to look like yours but did not change AES etc so it failed to start but you should be fine if you downloaded it from PIA.

17 hours ago, binhex said:

ok lets check iptables isn't blocking, can you do the following:-

1. start the container
2. left click container and click on 'console'
3. type 'iptables -S' and paste the result here.

Alright, sorry for the delay. It's been a day...

iptables -S

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 53 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT

Switched back to ver .03 this morning and all is working again.

Upgraded a little while ago and having similar problem as Lonewolf147

 

I created a new pia config file to ensure nothing was screwed up there. 

 

sh-5.2# iptables -S
-P INPUT DROP
-P FORWARD DROP
-P OUTPUT DROP
-A INPUT -p udp -m udp --sport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --sport 53 -j ACCEPT
-A OUTPUT -p udp -m udp --dport 53 -j ACCEPT
-A OUTPUT -p tcp -m tcp --dport 53 -j ACCEPT

Command execution.txt supervisord.log.txt

Anyone know if there is a problem with PIA wireguard in the last day or so?

Just woke up this morning and Sab and my privoxyvpn containers are both getting the following error recurring

 

Error: error sending query: Error creating socket

Error: error sending query: Error creating socket

 

I use the same wireguard config file on my rtorrentvpn container and its working just fine. 

 

EDIT

I've tried an updated wg0.conf and i'm getting the same issue. 

Also tried ovpn and same issue. 

 

Edited July 5, 20242 yr by tazire

2 hours ago, tazire said:

Anyone know if there is a problem with PIA wireguard in the last day or so?

Just woke up this morning and Sab and my privoxyvpn containers are both getting the following error recurring

 

Error: error sending query: Error creating socket

Error: error sending query: Error creating socket

I've got the same issue with AirVPN today

Having the same problem with binhex-delugevpn, so whatever changed in common between them is probably causing the problem. Rolled both back to previous versions and the problem went away.
 

i'm aware of the issue guys and i think i have a fix, i shall post back when i have built a fixed image.

Like others, I'm getting the same issue, but after investigating it a bit (I'm no expert btw), I realised that changing the docker network type from custom (which is what I've using) to bridge resolved the issue. The issue appears to be with resolving DNS using the custom docker network DNS server 127.0.0.11. Not sure if this will help anyone, or assist in fixing the root cause, but I thought it wouldn't hurt to post.

Ok guys a new image has been produced, for anybody with the name resolution issue please do the following:-
 

1. login to unraid web ui
2. go to docker tab
3. toggle switch top right to 'advanced view'
4. click on 'force update' for the container
5. check logs for errors.

you rock! worked after forced update!

Thanks @binhex - Also working for me after update (and back on my custom docker network). Thank you!

Ahhh you legend 🙂 its all back up and running again!! Thanks for fixing this one so quickly! 💪

Latest version fixed my issues too!  Thanks binhex!

 

Can also confirm everything is working again.

Forced upgrade fixed the problem.

 

Thanks for your work in fixing this.