[Support] binhex - SABnzbdVPN

[binhex]

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'.

[Lonewolf147]

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 Tuesday at 08:04 PM by Lonewolf147

[binhex]

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.

[Lonewolf147]

Changed it, but same issue.

supervisord - Copy.log

[binhex]

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.

[Lonewolf147]

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. 

[Lignumaqua]

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'.

[binhex]

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).

[Lonewolf147]

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

[binhex]

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.

[Lonewolf147]

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

[Lonewolf147]

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