binhex

you cant just specify random env vars and expect them to work, i wish they did :-). you can instead try specifying the bandwidth option for key RCLONE_USER_FLAGS by setting the value to '--bwlimit 100M'

tell your vpn provider you tried the option they suggested and the above is the error you now see.

Hi all, I have made some nice changes to the core code used for all the VPN docker images I produce, details as follows:- Randomly rotate between multiple remote endpoints (openvpn only) on disconnection - Less possbility of getting stuck on a defunct endpoint Manual round-robin implementation of IP addresses for endpoints - On disconnection all endpoint IP's are rotated in /etc/hosts, reducing the possibility of getting stuck on a defunct server on the endpoint. I also have a final piece of work around this (not done yet), which is to refresh IP addresses for endpoints on each disconnect/reconnect cycle, further reducing the possibility of getting stuck on defunct servers. In short the work above should help keep the connection maintained for longer periods of time (hopefully months!) without the requirement to restart the container. The work was non-trivial and it is possible I have introduced some bugs (extensively tested) so please keep an eye out of for unexpected issues as I roll out the this change (currently rolled out to SABnzbdVPN and PrivoxyVPN), if you see a new image released then it will include the new functionality.

Hi all, I have made some nice changes to the core code used for all the VPN docker images I produce, details as follows:- Randomly rotate between multiple remote endpoints (openvpn only) on disconnection - Less possbility of getting stuck on a defunct endpoint Manual round-robin implementation of IP addresses for endpoints - On disconnection all endpoint IP's are rotated in /etc/hosts, reducing the possibility of getting stuck on a defunct server on the endpoint. I also have a final piece of work around this (not done yet), which is to refresh IP addresses for endpoints on each disconnect/reconnect cycle, further reducing the possibility of getting stuck on defunct servers. In short the work above should help keep the connection maintained for longer periods of time (hopefully months!) without the requirement to restart the container. The work was non-trivial and it is possible I have introduced some bugs (extensively tested) so please keep an eye out of for unexpected issues as I roll out the this change (currently rolled out to SABnzbdVPN and PrivoxyVPN), if you see a new image released then it will include the new functionality.

Hi all, I have made some nice changes to the core code used for all the VPN docker images I produce, details as follows:- Randomly rotate between multiple remote endpoints (openvpn only) on disconnection - Less possbility of getting stuck on a defunct endpoint Manual round-robin implementation of IP addresses for endpoints - On disconnection all endpoint IP's are rotated in /etc/hosts, reducing the possibility of getting stuck on a defunct server on the endpoint. I also have a final piece of work around this (not done yet), which is to refresh IP addresses for endpoints on each disconnect/reconnect cycle, further reducing the possibility of getting stuck on defunct servers. In short the work above should help keep the connection maintained for longer periods of time (hopefully months!) without the requirement to restart the container. The work was non-trivial and it is possible I have introduced some bugs (extensively tested) so please keep an eye out of for unexpected issues as I roll out the this change (currently rolled out to SABnzbdVPN and PrivoxyVPN), if you see a new image released then it will include the new functionality.

Hi all, I have made some nice changes to the core code used for all the VPN docker images I produce, details as follows:- Randomly rotate between multiple remote endpoints (openvpn only) on disconnection - Less possbility of getting stuck on a defunct endpoint Manual round-robin implementation of IP addresses for endpoints - On disconnection all endpoint IP's are rotated in /etc/hosts, reducing the possibility of getting stuck on a defunct server on the endpoint. I also have a final piece of work around this (not done yet), which is to refresh IP addresses for endpoints on each disconnect/reconnect cycle, further reducing the possibility of getting stuck on defunct servers. In short the work above should help keep the connection maintained for longer periods of time (hopefully months!) without the requirement to restart the container. The work was non-trivial and it is possible I have introduced some bugs (extensively tested) so please keep an eye out of for unexpected issues as I roll out the this change (currently rolled out to SABnzbdVPN and PrivoxyVPN), if you see a new image released then it will include the new functionality.

it hasnt dropped yet, latest version on here is 1.19.83.01 its automatic and should happen approx 1 hour from the update appearing on the official website (linked above)

There currently is no flag to silence the logs in the latest release of microsocks, but i see a commit to master branch has been made which includes this functionality so i have asked the developer to create a new release, if he does so then i can incorporate a env var to turn logging on/off. for ref here is the issue raised:- https://github.com/rofl0r/microsocks/issues/61

yep that's a successful start and configuration of the incoming port, have you gone through the checklist here in Q6:- https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md

As much as i would love to blame your ISP here (TalkTalk are bloody awful!) moving ISP should not affect your download speed when torrenting over a VPN connection UNLESS the ISP you moved to is bandwidth throttling VPN traffic, which is a pretty crappy thing to do. Having said all that, having a working incoming port for torrenting is HIGHLY recommended and will ensure you will be able to connect to more peers, so its def worth moving to a VPN provider that offers port forwarding. As long as the VPN provider allows connection via wireguard or openvpn AND allows P2P traffic and a mechanism to assign a port forward then you should be good, if you want an easy life go with PIA as i have coded this image to use it out of the box with minimal effort for the end user.

correct yes

https://vpnalert.com/guides/surfshark-port-forwarding/

https://www.theregister.com/2023/05/31/bugs_in_ex_sgi_xfs/?td=rt-3a Luckily we are not affected (earlier kernel) 🙂

helping strike out cos im on my laptop 🙂 Q17 https://github.com/binhex/documentation/blob/master/docker/faq/vpn.md @soana

OK so qbittorrent is a special case, for that docker image you need to specify the WEBUI_PORT and re-create the port you want, this is all due to enhanced security built into qBittorrent (CSRF protection). For all other docker images i produce you do NOT change the container port, you simply change the host port side, which you can do through the unraid web ui without the need to re-create the port, for example say you wanted to access SABnbd on port 1234, you would change it to the following, note the host port number and note the container port is greyed out to prevent you from changing it (what we want):-

ok thats interesting!, im using the libtorrentv1 tagged image myself, no crashes, perhaps your issue is something else.

sorry im unable to reproduce this, i just deleted a server from the network list, restarted the container, recheck network list and the server i deleted is still gone.

nope, not a thing!, port forwarding over a VPN is completely independent of port forwarding on your router, the port forwarding is done at the VPN providers end not yours, you don't need to and indeed should not setup any sort of port forward on your router.

you brought up the query as to why qbittorrent wasn't running in host mode, and i wanted to be clear for you and anybody else reading this in the future that 'Network Type' of 'host' is definitely a bad thing for this image, vanilla qbittorrent with no VPN built in is a different thing, you can run that in host, bridge, custom bridge, whatever really. 🙂

yeah you don't want to do that, this container is isolated from your host for a reason, it must run in 'Network Type:' 'bridge', as must all the VPN enabled docker images I produce.

if its visible in edge and not in chrome then it must be an extension you have installed on chrome that is somehow blocking that field, i use chrome myself so i know chrome and unraid 6.11.5 work with no issues, so it must be an extension.

what version of unraid are you using?, also try another browser, maybe some adblock script addon is screwing things up for ya.

OK I'm confused!, so no 'Container Port:' field?, I've filled it out to demonstrate what it should looks like once configured with your specified port number:-

Q4:- https://github.com/binhex/documentation/blob/master/docker/faq/qbittorrentvpn.md

I'm running this image myself with no issue (on tagged 'latest'), unless there is a step you guys can provide me to replicate the issue then I won't be able to fix it 😞