binhex

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

no probs, if you are thinking 'why would i want port forwarding in any case for a proxy server?' then the answer is that people do share networking from other container with vpn enabled containers such as this, and these other containers may require a working incoming port, e.g. torrent client, soulseek, etc

port forwarding support has been added to all vpn images, if you don't want to have to connect to a port forward enabled endpoint then set STRICT_PORT_FORWARD to 'no'

That is an interesting idea and would explain it, i have had to be more aggressive with blocking due to this issue, and thus the name resolution is now forced straight away and will only use the defined NAME_SERVERS (a good thing in my opinon), whereas before that code was further down the chain and thus a potential name lookup could happen using the hosts define name servers before the re-write of resolv.conf, so yeah I think this probably is the case, sadly though for you I will not be reversing this change due to the linked issue.

i have no idea how the previous version worked for you, if you are blocking port 53 then name resolution should only happen by your pihole, which will be blocked once the vpn tunnel is established. Ahh fair enough!. i appreciate the info!, I'm just letting you know that local name resolution will not work.

Isn't this your issue then?, remove this block and you should then be able to use public NS. what is this?, VPN_NAMESERVERS is an env var not defined for any of my images so it will do nothing, the correct name is NAME_SERVERS. No you can't, i actively block internal DNS to prevent ip leakage.

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