-
[Support] binhex - qBittorrentVPN
I need to run a custom curl command to update my VPN IP with a private tracker. Is there a "tunnel up" script that I can add that command to? Will it persist between version updates? Or is there a better way to have this container run a curl command upon VPN connection? (Apologies if this is a common question. I scanned through the FAQ, but if there is relevant information there I did not see it.)
-
[Support] binhex - qBittorrentVPN
Yup, I followed your instructions there for my original setup and they worked great! Thank you for those. It only broke when ProtonVPN seemingly disabled port forwarding on the server selected in my wg0.conf. Generating a new .conf with a new ProtonVPN server (that does allow port forwarding) has fixed this problem for me. While I have your attention I'll mention that this part in the 4th bullet of A31: scroll down to VPN_USER and append the string +pmp to the end of the username, e.g. zuqWGtyy7SMGQM8C+pmp Seems to only apply to OpenVPN? But it is directly after the Wireguard instructions (in the third bullet), implying it needs to be done for Wireguard too. I found that a little confusing. @binhexThank you again for all you do!
-
[Support] binhex - qBittorrentVPN
I had been having the same problem others have mentioned recently: With VPN on I could no longer access the web UI. Turning VPN off allowed me to access the web UI, but with the obvious downside of no VPN. As soon as VPN was reenabled and the container restarted, the web UI would be inaccessible again. I found the problem in the log for this container. My VPN provided (Proton) had apparently disabled port forwarding on the server set in my wg0.conf file. That was causing VPN to fail. The VPN failure interfered with the scripts / startup, so it was never getting to the "qBittorrent process listening on port 8585" point. I went to my VPN provider's site and generated a new .conf file using a new server that was specifically enabled for port forwarding, then placed that file in appdata/binhex-qbittorrentvpn/wireguard/ and renamed it to wg0.conf Turns out in my case it had nothing to do with my local system software or configuration at all! Not sure if anyone else is suffering from this seemingly very specific problem, but since others are reporting similar symptoms I thought I'd mention. Always worth reading the log. Relevant bit from my supervisord.log: 2025-03-09 01:54:43,125 DEBG 'start-script' stdout output: [info] Script started to assign incoming port for 'protonvpn' 2025-03-09 01:54:43,125 DEBG 'start-script' stdout output: [info] WireGuard interface 'up' 2025-03-09 01:54:45,150 DEBG 'start-script' stdout output: initnatpmp() returned 0 (SUCCESS) using gateway : 10.2.0.1 sendpublicaddressrequest returned 2 (SUCCESS) readnatpmpresponseorretry returned -7 (FAILED) 2025-03-09 01:54:45,150 DEBG 'start-script' stderr output: readnatpmpresponseorretry() failed : the gateway does not support nat-pmp errno=111 'Connection refused' 2025-03-09 01:54:45,150 DEBG 'start-script' stdout output: [warn] ProtonVPN endpoint '149.36.48.129' is not enabled for P2P port forwarding, skipping port forward assignment... [info] Script finished to assign incoming port 2025-03-09 03:24:40,200 DEBG 'watchdog-script' stdout output: [info] qbittorrent incoming port closed, marking for reconfigure 2025-03-09 03:24:43,295 DEBG 'start-script' stdout output: [info] Sending 'down' command to WireGuard due to port closed...
sofauxboho
Members
-
Joined
-
Last visited