binhex

ok lets check iptables isn't blocking, can you do the following:- start the container left click container and click on 'console' type 'iptables -S' and paste the result here.

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.

can you please try setting NAME_SERVERS to a value of 1.1.1.1 let me know the outcome.

OK so i haven't dealt with bonded NIC's before, i can only assume creating a bonded NIC for some reason hides the port mappings, or perhaps changes the network type from bridge to another type. As for your question about the WebUI shortcut, you can set it by left clicking the container icon, going to edit, then toggle 'basic view' to advanced view (top right) then look for WebUI: and change the value to be http://[IP]:[PORT:8112] then click on apply at the bottom

hmm probably not, i know its not ideal but can you not simply restart the container? p.s. I'm not exactly sure how you got into this state to be honest, i use this container myself extensively and i have not seen a orphaned vnc session before, it def is an odd one, if you can replicate the issue i would be interested.

ok lets check iptables isn't blocking, can you do the following:- start the container left click container and click on 'console' 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).

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

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.

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

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

if you want to help then switch back to latest and:- 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

i have not altered iptables so no additional blocking should be in place, so im not clear why you are seeing this, i will need to see logs, see end of this post. this is a new feature i have introduced, docs will follow but for now ignore it. expected, if ip6tables are not available then it will warn and ignore, otherwise it will actively block all ipv6 traffic. 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

check your firewall/router, are you blocking port 53 (name servers), in particular look for any sign of 84.200.69.80 being blocked.

post a screenshot showing the issue if you can.

from your log:- 2024-06-29 17:57:38 AUTH: Received control message: AUTH_FAILED Please see Q16 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

PIA is cheap, they have been proven in a court of law not to log, and i have code in place to auto assign an incoming port, yes they aren't perfect, their support is a bit sucky but as long as the don't log then i'm personally happy enough. If you want to change protonvpn or airvpn are good choices.

Please post your config of the container here

what is the value of NAME_SERVERS? i am going to guess you do not have this defined or the value is empty right?, if so i see what the fix is.

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

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

OK so I have had a look at the code and for your particular case I think what happened was the endpoint you were attempting to connect to was disabled and/or possibly shutdown, including deletion of all name records for the endpoint which then lead to a name resolution retry loop on start-up for the VPN container. So how to prevent this situation - I will put in additional code to drop all packets but permit name resolution for a short period of time on start-up (will be included in the next image), this will allow name resolution of the endpoint but will ensure all other traffic is not permitted, even if name resolution fails, as was your case. Do note this particular issue would only affect containers routed through the VPN container, it will not affect the application running in the VPN container (in this case Deluge), as the application will not start until the tunnel is established. UPDATE - Image now built with change included above, please do note there are a number of additional changes included unrelated to the above.

@jonp and @trurl 'Why can't i post new topics here?' - Sadly this is no longer true!, can a moderator please set permissions back to what they were pre forum upgrade, otherwise we are going to end up inundated with Topics like these Note:- The Topic linked above has now been moved by a moderator but the underlying issue remains - any user can create topics here.

exactly this, so either re-download from pia and they will get processed correctly or do the hack yourself, the choice is yours.

you add the next network with a comma as the separator e.g.:- 192.168.1.0/24,192.168.2.0/24

prowlarr is working fine for me (torrent index sites), are you sharing network with a vpn enabled container?, if so stop prowlarr then stop the vpn container, then start the vpn container and then prowlarr.