I'm using ProtonVPN and I have a paid plan, ive picked a server that supports port forwarding, but im not sure how to actually configure port forwarding here. How does it work?
9 replies
tomspark wrote:
You're most of the way there — picking a port-forwarding server was the right step. You don't enter a port yourself; Proton hands one out automatically once the feature is switched on. Over SSH, paste this one line: sudo sed -i '/^VPNPORTFORWARDING=/d' /opt/sparkbox/.env && echo 'VPNPORTFORWARDING=on' | sudo tee -a /opt/sparkbox/.env /dev/null && sudo sparkbox restart media After a minute or two, open the VPN (gluetun) logs from the dashboard and look for a line saying which port got forwarded. Put that number into qBittorrent under Options Connection 'Port used for incoming connections' and you're set. Worth knowing: this mainly helps seeding — downloads already work without it.
maryo wrote:
tried that, got this 2026-06-11T06:44:21Z INFO [port forwarding] starting 2026-06-11T06:46:29Z ERROR [vpn] starting port forwarding service: port forwarding for the first time: getting external IPv4 address: executing remote procedure call: connection timeout: failed attempts: read udp ...:36779-10.2.0.1:5351: i/o timeout (tries 1, 2, 3, 4, 5, 6, 7, 8, 9) honestly not sure why its failing but my seeding seems to be really throttled so I wanna get this working
tomspark wrote:
That error means Proton isn't handing your box a forwarded port right now. It's hit-or-miss on Proton and not something on your end. Two things worth knowing: it only helps seeding, never downloading, so it's a bonus and not required. And the usual reason it won't connect is the server you're on doesn't have port forwarding enabled, even if it allows P2P. Make sure you picked a Proton server that specifically lists 'P2P' AND 'port forwarding', then run sudo sparkbox restart media and give it two minutes. If the timeout keeps coming back, leave it off and seed without it for now; your downloads aren't affected either way.
skylyn wrote:
I've been fighting with this for days, and I haven't had a single successful port forwarding setup. I configured VPNPORTFORWARDING=on, I have a VPN configuration from Proton to allow P2P. I've tried setting the SERVERCITIES=Amsterdam and SERVERCITIES=Phoenix (with the appropriate country). Both of these cities only have servers that support port forwarding. However, I'm still unable to get port forwarding working. Every time I try I get the same logs: T2026-06-14T05:26:39.141167726Z 2026-06-14T05:26:39Z INFO [port forwarding] starting C2026-06-14T05:28:46.895908767Z 2026-06-14T05:28:46Z ERROR [vpn] starting port forwarding service: port forwarding for the first time: getting external IPv4 address: executing remote procedure call: connection timeout: failed attempts: read udp 172.20.4.3:55256-10.2.0.1:5351: i/o timeout (tries 1, 2, 3, 4, 5, 6, 7, 8, 9) I understand this doesn't affect my downloading directly, but it does affect my ability to seed effectively, which means I can't keep up my ratio for private indexers and therefore I can't download more. I'd really like to get this solved so that I'm able to effectively seed back what I have downloaded. Interestingly, qBittorrent occasionally shows connected instead of firewalled even when gluetun shows the same error and no further logs. However, even when it shows connected, my upload speed rarely rises above 0, even when seeding many torrents with many leechers. I did also try surfshark vpn, but my seeding rate was no better with surfshark. It's possible, of course, that no one is actually trying to connect and download the files I'm seeding, but qBittorrent does indicate many peers attempting to connect so it seems like something isn't working as expected, and the logs in Gluetun also indicate that. I did have some conversations with Tom AI, but I'm still unable to get it to successfully setup port forwarding (side note, I tried the "Share to demox" button, but got a 414 too large. It seems like it's trying to share the entire conversation, probably worth putting a size limit there, and maybe having the agent generate a summary with important points). Note that it's not intermittent. I've tried restarting and hitting many different servers many times over the past week. It has never successfully started port forwarding. I'd appreciate any suggestions that may help here.
tomspark wrote:
You're not alone here — a couple of others have hit the exact same timeout, and it's not something you misconfigured. This looks like a compatibility issue between gluetun and ProtonVPN's servers right now. Try running sudo sparkbox update — that'll pull the latest container images, and if a newer gluetun version has a fix it'll grab it automatically. If the timeout keeps coming back after that, this is something we need to look at on our end and I'll flag it.
skylyn wrote:
I have updated, I'm running the latest Sparkbox and Gluetun, but still timing out setting up port forwarding. I added PORTFORWARDONLY=on to my .env (found in the gluetun docs) but that didn't help either. I suspect something in the network configuration is blocking the request like this, but I don't see FIREWALLOUTBOUNDSUBNETS specified anywhere.
tomspark wrote:
Thanks for digging in this deep — that's genuinely helpful, and you're onto something. You've done everything right on your end, so this one's on us now. That FIREWALLOUTBOUNDSUBNETS gap you spotted looks like the real lead: the port-forward request can't reach Proton's server from inside the tunnel. I've passed it to the dev side to test and fix properly — I don't want to hand you a guess that might knock your whole VPN offline. I'll post back here the moment there's a patch. In the meantime your downloads still work fine; port forwarding only gives seeding a boost, so you're not losing anything critical while we sort it.
skylyn wrote:
The problem is FIREWALLOUTBOUNDSUBNETS contains 10.0.0.0/8, so it prevents the request to ProtonVPN to setup port forwarding on 10.2.x.x from reaching Proton through the VPN. This is documented in the GlueTun wiki. Removing 10.0.0.0/8 from the firewall allows port fowarding to work immediately. I don't have any local 10. IP address assignments, so this is unnecessary for my network anyway. I also added - PORTFORWARDONLY=${PORTFORWARDONLY:-off} to docker-compose.yml and PORTFORWARDONLY=on to .env so that I can use a nearby city and still ensure I have port forwarding instead of just picking a city that only has port forwarding servers, but is farther away. For convenience, you can also follow this Gluetun documentation to run a command to set the port in qBittorrent after proton gives you the port.
Chris wrote:
You were right, and I'm sorry nobody came back to you — you were promised a patch and never got one. Your diagnosis is on record as our bug now: the default outbound list includes 10.0.0.0/8, Proton's port-forward gateway sits inside that range, and the request never completes. There is still no fix shipped, and I'd rather say that plainly than dress it up. What has improved is that the workaround sticks. Put it in /opt/sparkbox/.env instead of editing the compose file: FIREWALLOUTBOUNDSUBNETS=192.168.0.0/16,172.16.0.0/12 then sudo sparkbox up. Compose reads that value, so an update won't overwrite it any more. One caveat for anyone else reading: only drop 10/8 if nothing on your network uses a 10.x address, or you'll lose local access to the apps. — Chris