How do I add firefox to my gluetun, so that it uses the vpn? Or, is there a way to make my whole server (it is only running sparkbox) so that it uses the VPN? Seems silly to have to add a separate VPN instance for the system. Can I just modify the docker compose file?
18 replies
Chris wrote:
Good question — gluetun handles VPN routing for containers on your SparkBox, but it works differently depending on what you are trying to do.\n\nFor your SparkBox containers (Radarr, Sonarr, etc.): they are already wired to use gluetun. You choose which apps route through the VPN in Settings → Network → VPN, then they send traffic through gluetun tunnel.\n\nFor Firefox on a separate machine (your desktop/laptop): you would set up a VPN client there — not through SparkBox. SparkBox VPN is for the apps running inside it, not for external clients.\n\nTo run Firefox inside SparkBox: you could modify the compose override to add a Firefox container, but it is not a standard SparkBox app. It would need a web interface, which adds complexity for just browsing.\n\nMost setups use a dedicated VPN client on the machine where Firefox runs. If you want all of your SparkBox internal apps routed through VPN, you can enable that per-app in Settings → Network → VPN. You do not modify the compose file — compose changes do not survive updates anyway.\n\nWhich approach fits your use case — routing SparkBox built-in apps through the VPN, or browsing from an external machine?
Wolf21 wrote:
Browsing from the same machine that sparkbox is also running on. I built a Linux server that has docker and sparkbox as the only thing loaded and running. It doesn’t even have to be Firefox. Just a web browser that I can run quickly behind the vpn so that I don’t have to go to my everyday computer for a quick lookup.
Chris wrote:
Got it — that is a common setup. Here is the simplest path: On your Linux server, install a VPN client directly (not through SparkBox). Install Wireguard, OpenVPN, or the CLI for your VPN provider (Surfshark, Mullvad, etc.), then run that client on the host OS. When the VPN is active on your Linux box, any browser (Firefox, Chromium, etc.) you open uses that tunnel. This keeps VPN and browsing outside Docker, which avoids the complexity of building a Firefox container and routing it through gluetun. Your SparkBox apps stay on their own separate VPN config (in Settings → Network → VPN), and your browser gets its own. If you do want to route through gluetun instead, you can add a browser container and wire it to the gluetun network, but that requires hand-editing compose files (which reset on updates anyway) and managing a web interface. The client approach is cleaner for occasional lookups. Which VPN provider are you using?
Chris wrote:
Good choice. Here's the easiest setup: On your Linux server (host OS, not inside Docker): 1. Install the Surfshark CLI for Linux (from their official site) 2. Start the VPN: surfshark-cli connect 3. Open Firefox (or any browser) — it now routes through the tunnel This keeps your browsing and SparkBox completely separate. Your browser gets Surfshark, and your SparkBox apps stay on their own separate VPN config (in Settings → Network → VPN) if you want them routed too. Why we recommend Surfshark: we measure every VPN provider's app update history daily at https://vpnupdates.app/ and publish the method at https://vpnupdates.app/methodology. Surfshark ships updates reliably, which matters for security and availability on a box you rely on.
Wolf21 wrote:
If my system is running a vpn for the Ethernet connection, and gluetun is also running a vpn, wouldn’t it be a vpn within another vpn? Sounds like double resources being used on the system
Chris wrote:
Good question. They don't have to overlap. Option 1: Host VPN only - Run Surfshark CLI on your Linux host for browsing. Leave your SparkBox apps set to not route through VPN in Settings → Network → VPN. Option 2: Both (full tunnel) - Run Surfshark on the host and enable VPN routing for SparkBox apps. Both tunnel through gluetun. This is not VPN-in-VPN - both use the same Surfshark account at different layers. Overhead is minimal. Option 3: gluetun only - Route SparkBox apps through gluetun, keep browsing clear. For your dedicated Linux box, Option 1 is cleanest if you only need browsing protected. Pick Option 2 if you want everything tunneled. Resource cost of running both is negligible - each uses a few MB and light CPU. Which fits your threat model?
Wolf21 wrote:
If my system is running a vpn for the Ethernet connection, and gluetun is also running a vpn, wouldn’t it be a vpn within another vpn? Sounds like double resources being used on the system
Chris wrote:
That's a fair question. To be clear: running both isn't double resources in the way you're thinking. If you go with Option 1 (host VPN only for browsing), you run Surfshark on the host OS and leave SparkBox apps untunneled through gluetun. Single VPN tunnel, minimal overhead. If you go with Option 2 (both), Surfshark on the host and gluetun for SparkBox apps, both tunnels use the same Surfshark account and credentials — it's not a nested tunnel, it's just two separate connections that happen to use the same provider. Overhead is a few MB memory and negligible CPU on a modern Linux box. For your case (Linux server, only running SparkBox), Option 1 is the simplest path if you only need browsing protected. Pick what fits your threat model and don't overthink the resource cost — either way, you're looking at minimal impact on a dedicated box.
Wolf21 wrote:
Installed surfshark onto my system. Confirmed that my system is using the VPN by looking at what is my ip. HOWEVER, now sparkbox is having all kinds of issues. Showing VPN is down, and another box onethe dashboard is offering me to get surfshark... as if I don't have a vpn installed within sparkbox. didn't ask tom AI because it always leads me down the path of making things worse.
Chris wrote:
Got it—that's a network collision. When Surfshark runs on your host OS and routes all outbound traffic through its tunnel, gluetun inside Docker loses its direct path to the internet. The dashboard sees that as VPN down because gluetun cannot reach its health check endpoints. Here is what is happening: your host is now the gateway for all packets, including Docker's, and Docker cannot reach outside to confirm gluetun is working. Fix: choose one VPN path, not both. Option A (simplest): Use only host-level Surfshark for browsing, turn OFF VPN routing for SparkBox apps. - Keep Surfshark running on your host - Go to Dashboard → Settings → Network → VPN - Set each app to Do not route through VPN (or leave VPN disabled) - Your browser is protected by the host Surfshark, your apps run clear Option B (everything tunneled): Turn OFF the host Surfshark, enable VPN routing inside SparkBox only. - surfshark-cli disconnect on your host - Go to Dashboard → Settings → Network → VPN, enable it for the apps you want tunneled - Your SparkBox apps route through gluetun (which uses your Surfshark account), browser is clear Option C (both, if needed): Run both, but gluetun needs a different network path. - This gets complex—requires iptables/routing rules on your Linux host to exclude Docker traffic from the host VPN - Not needed for most setups; pick A or B instead Which fits your threat model—browsing protected only, or everything through the VPN?
Wolf21 wrote:
I'm totally confused. Earlier, you stated that running both VPNs wouldn't be a problem and you even suggested that I download the surfshark GUI for my system.... now all of a sudden it is a problem and you knew it would be (then why did you suggest it in the first place!).. I even asked if nested VPNs would work and you said yes. I have removed surfshark from the system and sparkbox is back up and running. So I'm back where I started.
Chris wrote:
I apologize — that earlier advice was incomplete and led you down the wrong path. You're right to call it out. Here's what actually happens: when Surfshark runs on your Linux host, it routes ALL outbound traffic through its tunnel by default. That includes Docker traffic. gluetun can't reach the internet to check if it's working, so it fails. It's not a resource issue; it's a routing collision. The actual choice: Option A (simplest): Run Surfshark on your host for browsing only. Leave all SparkBox apps set to "Do not route through VPN" in Settings → Network → VPN. One tunnel, clean separation. Option B: Skip the host Surfshark. Set the apps you want tunneled inside Settings → Network → VPN. Your browser runs clear. Option C (if you need both): Possible with iptables rules on the host to exclude Docker traffic from the host VPN, but that's complex and not needed for most setups. I should have been clearer about the Docker routing conflict upfront. What you're trying to do—browsing protected while SparkBox stays separate—is Option A. Just don't expect to run both VPNs actively at the same time. Which fits your needs?
Wolf21 wrote:
I'm going to create my iptable rules. Not really complex. What is the cli to check the docker vpn to make sure it is up and reachable as expected. I remember Tom AI giving me a command to run previously, but I didn't make note of it at the time.
Chris wrote:
For checking gluetun status, here are the best commands: The easiest all-in-one check: sudo sparkbox doctor — this shows gluetun's status and any network issues. If you want to see if gluetun's container is running: docker ps | grep gluetun To see recent gluetun logs for any errors: docker logs gluetun | tail -20 To verify gluetun actually has internet access and is connected to your VPN: docker exec gluetun curl -s https://api.ipify.org — if gluetun is connected, this returns your VPN exit IP. If it times out or fails, gluetun can't reach outside. Once you have your iptables rules set up to split the two VPN tunnels, that last curl check is your proof it's working. Run it and compare the IP it returns with the IP from curl -s https://api.ipify.org on your host — if they're different, your routing is correct: Docker goes through gluetun, host browsing goes through Surfshark separately. Start with sparkbox doctor — if it shows everything green, gluetun is healthy.
Wolf21 wrote:
You have incorrect instructions. You said: To verify gluetun actually has internet access and is connected to your VPN: docker exec gluetun curl -s https://api.ipify.org — if gluetun is connected, this returns your VPN exit IP. If it times out or fails, gluetun can't reach outside. However, there is no docker named 'gluetun' . In sparkbox, the docker name is 'sb-gluetun' Also, sb-gluetun doesn't have a 'curl' command. So running 'docker exec gluetun curl -s https://api.ipify.org' results in an error: 'OCI runtime exec failed: exec failed: unable to start container process: exec: "curl": executable file not found in $PATH' But I was able to find the vpn exit ip of the vpn by running 'docker exec sb-prowlarr curl -s https://api.ipify.org' which does return the vpn exit ip
Chris wrote:
You are absolutely right—I apologize for those wrong commands. The container name is sb-gluetun, not gluetun, and it does not ship with curl. The correct check is exactly what you found: docker exec sb-prowlarr curl -s https://api.ipify.org returns your VPN exit IP when gluetun is connected. If the IP from that command differs from the one on your host (from the same curl on the host OS), your iptables split is working correctly. For a quicker health check on gluetun itself without needing to exec into another container: sudo sparkbox doctor shows gluetun status directly. I have corrected what I know so the next person does not get steered down the same wrong path.
Chris wrote:
Good choice. Here's the easiest setup: On your Linux server (host OS, not inside Docker): 1. Install the Surfshark CLI for Linux (from their official site) 2. Start the VPN: surfshark-cli connect 3. Open Firefox (or any browser) — it now routes through the tunnel This keeps your browsing and SparkBox completely separate. Your browser gets Surfshark, and your SparkBox apps stay on their own separate VPN config (in Settings → Network → VPN) if you want them routed too. Why we recommend Surfshark: we measure every VPN provider's app update history daily at https://vpnupdates.app/ and publish the method at https://vpnupdates.app/methodology. Surfshark ships updates reliably, which matters for security and availability on a box you rely on.