binhex

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.

This has been done multiple times by multiple people, so far PIA have done sweet FA. So this is all you pretty much have as a workaround right now, the weird thing is i included the workaround about a month ago and you are the first person to say it doesn't work, so i can only assume either you are not running the latest image or your openvpn configuration files are read only and thus my code is unable to modify the config files. See github issue:- https://github.com/binhex/arch-qbittorrentvpn/issues/233

Hmm yes i see the DNS issues, perhaps your firewall is blocking DNS Watch, try setting NAME_SERVERS to simply a value of `1.1.1.1` see if that helps.

give it a go.

Looking at your logs i see the failure to get the token from 'https://www.privateinternetaccess.com/gtoken/generateToken', this will then prevent the script from going further to generate the wg0.conf file. Main causes of this are:- PIA intermittent failure - Yes this is a thing sadly, leaving the container to retry should result in success. Firewall block - Check you are not blocking www.privateinternetaccess.com on your router/firewall DNS issues - Try setting NAME_SERVERS to have a value of 1.1.1.1

not odd at all, without the vpn active no iptables are active (firewall) so no blocking is enforced.

thats your problem then your LAN_NETWORK value from your log:- 2024-06-16 12:10:57.486813 [info] LAN_NETWORK defined as '192.168.1.0/24' Please see Q4 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

what is the ip address of the machine running the web browser that you are using to attempt connection to the applications web ui?

Hmm so in my very unscientific experiment i switched from incoming port to port forwarded port and yes i did see a decrease in connected seeds and peers, so i think you are correct, but that doesn't stop the use of this for non torrent clients, so i think its still a worthy addition, thanks for bringing that to my attention.

what's the IP address of the machine running the web browser that you are using to connect to the applications web ui?

How would this be different to doing a traditional port forward on your router, that works right? got any links to articles that state it won't work?.

this is a known issue, and @ich777 came up with a clever idea of using a socket instead, this then permits the vpn contaner to be restarted and for the container sharing the vpn network to reconnect without issue, its on my to-do list to look at. ive come up with a neat solution for this by setting up a statically assigned port forward inside of the container, this then forwards to the dynamic port, the beauty of this is that i dont then need to reconfigure the application as the application is configured to use the static port, if the port changes the port forward is altered without the need for the application to be reconfigured, cool hu!, tested it out earlier and it works!, so with that cracked it is now possible to configure ANY application to use the incoming port, even when the port is dynamically assigned (such as pia and protonvpn).

Absolutely!, it should be applicable to any other container. that sounds like an interesting idea but i don't know if that is possible, in the meantime i am going for a more low level option and that is simply to share the assigned vpn port via a docker volume (not bind mount) as i store the assigned vpn port in a file. As mentioned the really tricky part is to reconfigure the application to use the port and also monitor it for changes, if it changes then reconfigure, and for Nicotine+ this looks like i have two options:- 1. disconnect and reconnect to re-read port change from config file 2. restart nicotine+ to force re-read of config file As you can see neither option are ideal.

from the first sentence, in the first post in the first thread of this:-

are you sure?, so there is no file /config/wireguard/wg0.conf right?

from your log:- [UNDEF] Inactivity timeout (--ping-restart), restarting Please see Q17 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

it most probably isn't, the CRL issue is PIA VPN provider related only. 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

So if i had my time again i would produce one image similar if not the same to privoxyvpn, then document the crap out of it on how to connect any other container to it, it would mean smaller image sizes in that way (no need to bake in vpn clients to multiple images) and less complexity for me (single vpn image to deal with), but we are where we are, if I deprecated the use of delugevpn, sabnzbdvpn and qbittorrentvpn i think i would have a riot on my hands :-), so i will maintain them for the foreseeable. Yeah i don't know if what you are suggesting is running multiple tunnels in a single container, or the idea of having multiple containers each connecting to a different vpn endpoint, the latter is a lot easier to code than the former, in my 'if i had my time again' model i would suggest multiple privoxyvpn (or whatever name) containers, each going to a different locations, that would be the most logical approach in my opinion, and of course would not consume much additional space, only config differences.

Check you have followed all steps to network share, Please see Q24 from the following link:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md also for now i would advise ignore cloudflare, get it working locally.

Mine :-), DelugeVPN, qBittorrentVPN, SABnzbdVPN, PrivoxyVPN, so any of those, if you only want a simple tunnel with the added bonus of proxy and socks server built in then go for PrivoxyVPN.