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. I also followed this Gluetun documentation to run a command to set the port in qBittorrent after proton returns the forwarded port.
7 replies
skylyn wrote:
I commented this on this post nearly a month ago. I hoped it would be added to the upstream since I spelled out exactly what needs to happen for this to work. However, a month later I've seen a huge number of updates, but none have addressed this obvious flaw with a well-documented fix. Why is this still not fixed?
Chris wrote:
Really appreciate you digging into this and writing it up so clearly — you've landed right on a rough edge Tom's already tracking. That 10.0.0.0/8 in the outbound firewall list is there so some setups can reach their own LAN, but on ProtonVPN it blocks the port-forward request from reaching Proton, exactly like you found. Dropping it in your .env is the right move, and that .env override sticks through updates. One heads-up: the PORTFORWARDONLY line you added straight into docker-compose.yml will get put back the next time you run sudo sparkbox update, since updates re-lay-down the module files — so keep an eye on that one after an update. I've flagged the 10/8-vs-Proton default to Tom so he can make port forwarding just work here without the hand-edit. Thanks again — reports like this are exactly how it gets fixed.
skylyn wrote:
Much of this has to be configured in the docker-compose.yml file and gets wiped out with every update. Every time I update I have to manually diff the docker file and put the correct configuration back.
Chris wrote:
Good news — the port-forward firewall fix has more staying power than it feels like, and you shouldn't have to diff the compose file for it every time. That FIREWALLOUTBOUNDSUBNETS line reads its value from your .env, so if you put FIREWALLOUTBOUNDSUBNETS=192.168.0.0/16,172.16.0.0/12 in /opt/sparkbox/.env, it survives every update and you never have to hand-edit docker-compose.yml for the 10/8 drop again. The one piece that does get wiped is the extra PORTFORWARDONLY line you added straight into the compose template, since that isn't part of it yet — that's exactly the bit Tom's looking at folding in properly so port forwarding just works. So going forward, that single .env line should save you the whole manual diff.
skylyn wrote:
PORTFORWARDONLY is not the only thing I need to add. I also need to add the scripts to set up the port for qbittorrent every time. It's very annoying to come back and find that my machine installed another update and I have to go undo the changes over and over again.
Chris wrote:
You've got it exactly right — the firewall line in your .env holds through updates, but the extra scripts that re-apply qBittorrent's forwarded port aren't built in yet, so those are the bit getting wiped each time. That automatic port-sync is exactly what Tom's working on folding in properly, so the whole ProtonVPN port-forward flow survives an update without you having to undo anything. I've made sure your note about the qBittorrent port scripts is in front of him — genuinely helpful that you spelled out the missing piece. Sorry it's been a repeat chore in the meantime.
Chris wrote:
One thing I should have handed you last week and didn't: there is a supported slot for compose changes, so an update stops overwriting them. Create /opt/sparkbox/state/overrides/media.yml: services: gluetun: environment: - PORTFORWARDONLY=on That file is merged over the module's compose on every sudo sparkbox up, and because it lives under state/ an upgrade leaves it in place — no more diffing the template for that line. The filename has to match a module id in state/modules.conf or it is ignored silently. Your qBittorrent port-sync scripts are not covered by this; I won't pretend that half is handled.