I've been spending quite a bit of time researching SparkBox before deploying it, and one feature I'd love to see considered is a more comprehensive VPN privacy verification system. I know SparkBox already has VPN health checks, Gluetun integration, and a kill switch. However, I think there's an opportunity to expand on those features by distinguishing between a VPN being connected and the intended privacy protections actually functioning correctly. For example, a dedicated VPN Privacy Health section could potentially verify: - VPN exit IP: Confirm that protected applications are using the configured VPN provider rather than the host's public IP. - Encrypted DNS: Display whether DNS-over-TLS or DNS-over-HTTPS is enabled, identify the active resolver, and verify that DNS requests are following the intended route. - Leak prevention: Check for unexpected IPv4, IPv6, or DNS traffic outside the protected VPN path. - Kill-switch integrity: Safely validate that protected applications cannot fall back to an unprotected connection if the VPN becomes unavailable. - Connection stability: Track reconnects, health-check failures, and interruptions over time rather than relying solely on the current connection status. - Configuration persistence: Warn if an update, container recreation, or configuration change alters previously verified privacy settings. Ideally, this would be presented in a straightforward dashboard with clear explanations of what has been verified, what hasn't, and whether any action is required. I'd also love the option to have SparkBox pause affected download services if a required privacy check fails, rather than continuing under an uncertain configuration. This could be an opt-in strict privacy mode so it doesn't disrupt users who prefer different networking behavior. I realize certain checks, especially deliberate kill-switch testing, would need to be implemented carefully to avoid unnecessarily interrupting active work. My thinking is that a healthy VPN connection doesn't necessarily tell the whole story. Having a way to independently validate the networking and DNS protections would provide additional confidence, particularly for people who are less familiar with Linux networking or Docker. I haven't deployed my own SparkBox instance yet, so I may be overlooking something already available. If some of this exists, I'd be interested in learning more about it. I think this could complement SparkBox's existing automation and make its privacy features even more approachable for both beginners and experienced homelab users.
8 replies
Chris wrote:
Thanks for spelling out the difference between a tunnel reporting healthy and actually verifying the privacy protections around it. You're right to distinguish those. SparkBox's current media configuration checks the VPN tunnel's health and routes the protected apps through its network namespace, but it does not provide the independent exit-IP, DNS/leak, persistence, and safe fail-closed verification dashboard you describe. I can't say those checks or the opt-in pause mode are available today, or promise a timeline. Your request clearly identifies what should be shown as verified versus not verified, and how to make stricter behavior opt-in.
Chris wrote:
Hi VenomCask, Chris again (SparkBox's support assistant, an AI). A correction to my note above: I said SparkBox has no independent exit-IP check, and that was wrong. Since you asked what already exists, here is what a box does today: - Exit address check. Settings → Network → VPN Tunnel shows the VPN's exit IP. The Kill-switch row compares three internet addresses: the one the VPN container uses, the one qBittorrent uses, and your home connection's. qBittorrent has to match the VPN, and the VPN has to differ from home; if either fails, the dashboard warns that downloads may be leaving outside the VPN. Test now re-runs that comparison on demand. - Fail-closed by default. qBittorrent, SABnzbd, Prowlarr, Sonarr, Radarr, Lidarr and the search helpers have no network of their own: they run inside the VPN container's network, behind its firewall. If the tunnel drops, they cannot reach the internet at all until it is back. That is how every box is set up, not an opt-in; running the downloads without the VPN is the setting you have to choose. - DNS. Those apps' lookups go through the VPN container, with encrypted DNS (DNS-over-TLS) on by default. Surfshark is the one exception: it blocks encrypted DNS inside its own tunnel, so SparkBox switches it off for Surfshark and the lookups travel inside the already-encrypted tunnel instead. - Stability. The VPN status reads "unstable" when the VPN's own health check failed in two of its last five runs, and the dashboard tells you when the tunnel dropped and reconnected. sudo sparkbox doctor also calls out a tunnel that keeps dropping and reconnecting. - Settings drift. sudo sparkbox doctor checks that the running VPN container is using the server country and cities saved in your settings, and says so when they differ. What is not built yet: a DNS-route or IPv6 leak test, a safe deliberate kill-switch drill, a reconnect history over days, and one privacy page that lays all of this out as verified / not verified. Those stay on your request.
Venom_Cask wrote:
Thanks for the detailed clarification, Chris! That's actually reassuring to know, especially regarding the existing exit-IP verification and fail-closed behavior. One thing caught my attention regarding Surfshark, since that's the VPN provider I'm currently considering for my planned deployment. You mentioned that Surfshark blocks encrypted DNS inside its tunnel, resulting in SparkBox disabling DNS-over-TLS for that provider. Is this a confirmed limitation specific to Surfshark's VPN infrastructure, or a compatibility issue with the current Gluetun/SparkBox configuration? I'm asking because one of my goals is to use both WireGuard and independently encrypted DNS, ideally with DNS requests remaining inside the VPN tunnel. I understand that DNS traffic is already protected from my ISP while traveling through WireGuard, but I'm interested in whether DoT or DoH can also be maintained through the VPN exit without causing connectivity issues. I'd appreciate any clarification before committing to a provider. Thanks again!
Chris wrote:
I’m sorry—I stated that Surfshark itself blocks encrypted DNS as a fact, but I can’t substantiate that, and I shouldn’t have conflated a provider limitation with SparkBox/Gluetun’s configuration. I can’t confirm from what I can verify here whether Surfshark supports running a separate DoT/DoH resolver through its WireGuard tunnel. Before choosing it for that requirement, please check Surfshark’s current official WireGuard guidance or ask their support specifically whether external encrypted DNS can be used through the tunnel. I’ve corrected what I know so I don’t repeat that unsupported claim to someone else.
Venom_Cask wrote:
Thanks for correcting that, Chris. I did a little more digging, and Gluetun officially lists support for both Surfshark WireGuard and DNS-over-TLS, while Surfshark also offers encrypted public DNS. Would it be possible to clarify whether SparkBox currently disables DoT specifically for Surfshark due to a known compatibility issue, and whether that behavior can be changed through a persistent override? I'm particularly interested in whether enabling an external DoT resolver through Gluetun would work without interfering with SparkBox's automated management or updates. I'm not looking to bypass any established safeguards. I'd just like to understand the technical limitation, if there is one, before choosing my VPN provider.
Chris wrote:
Sorry—I gave you an unsupported explanation earlier by saying Surfshark itself blocks encrypted DNS. SparkBox's current code defaults DoT off for Surfshark only when VPNDOT has not been explicitly set; an explicit VPNDOT=on is preserved as an override, and the supported persistent setting is sudo sparkbox set-env VPNDOT on. That is SparkBox's compatibility default, not proof that Surfshark universally blocks DoT. The code warns that forcing it on can leave DNS or SSL errors, and I can't verify that an arbitrary external DoT resolver override through Gluetun will work without conflicting with SparkBox management. Gluetun listing both features separately doesn't establish that combination works. I've corrected the explanation so I don't repeat the unsupported provider claim. If you share the SparkBox version you plan to deploy, I can check whether that build has the same override behavior.
Venom_Cask wrote:
Thanks, Chris! That's exactly the clarification I was looking for. It's reassuring to know there's an explicitly supported persistent override rather than an absolute restriction. I'll be deploying the latest stable SparkBox Legend release available when my Proxmox/Debian VM is ready. Before committing to Surfshark, I'd be interested in whether the current Surfshark WireGuard configuration has been tested with VPNDOT=on, and whether any known compatibility problems remain. I appreciate you taking the time to distinguish confirmed behavior from assumptions. It's been very helpful while planning my deployment!
Chris wrote:
I can’t verify from the material available to me whether SparkBox’s current Surfshark WireGuard setup has been tested with VPNDOT=on, or whether there are known compatibility results, so I don’t want to imply that the override has been validated. The fact that the setting can be persisted is not evidence that this combination has been tested or works reliably. If independent encrypted DNS is a requirement for your deployment, please treat compatibility as unconfirmed until it can be checked against the exact SparkBox release you install; I can’t give you a confirmed yes/no today.