binhex

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.

Yep confirmed, from your log:- Database corruption: sqlite3_statement_backend::loadOne: database disk image is malformed See Q5:- https://github.com/binhex/documentation/blob/master/docker/faq/plex.md

Sorry i cannot support GlueTunVPN.

In a word, no, instead network sharing is where I'm trying to go with any future docker images, maintaining VPN enabled docker images is hard work so i would prefer to keep the workload as light as possible and leverage existing VPN connectivity instead, as mentioned above I am working on a solution to read in the incoming port from a VPN enabled docker container, the tricky part is reconfiguring Nicotine+ when the port changes.

i am doing just this, routing nicotine+ network through privoxyvpn, but you could use any of my vpn images to do this, and yep at present there is no mechanism to get the assigned incoming port, but i am working on a cunning plan to pass the info so you can see what the port is set to.

are you guys not seeing the wizard on initial startup of nicotine+ where it asks you to create a username and password? screenshots from the container:- so basically enter in whatever username and password you like, obviously you will need to have a unique username that is not already in use and you should be good!.

OK that makes sense to me, so for obvious reasons I have to permit outgoing and incoming traffic to the VPN endpoint in order to establish the VPN tunnel in the first place, and thus iptables permit this. qBittorrent is a very chatty Bittorrent client and it will communicate on all adapters by default, including the LAN adapter, and as the VPN endpoints have to be open qBittorrent may (not always) attempt to connect to the VPN endpoint over the LAN, obviously it would fail as the VPN endpoint is not a Bittorrent client. But i hear you cry, can't you simply tie qBittorrent down to use just the tunnel adapter?, well yes you can and i do exactly this by editing the configuration file before qBittorrent starts, but it appears qBittorrent does not always (looks to be random) pick this setting up straight away, leading to this approx. 1 second delay before switching to talk only on the tunnel adapter (as defined in the config file), so i can only assume this is a bug in qBittorrent - it should be reading the configuration and binding to the adapter BEFORE attempting any communication. In any case, this in my opinion is NOT an IP leak, your VPN provider already knows your ISP assigned IP address by this point and obviously a lot more besides, you are not talking to another Bittorrent client so there has been no peer to peer communication taking place and thus the risk is extremely low (in my opinion it's zero).