NordVPN fails in gluetun (handshake OK, all traffic times out) — same creds work in stock WireGuard client and in Surfshark Box: generic NAS, SparkBox v1.6.464, media module (gluetun/qBittorrent/arr stack). Symptom: sb-gluetun won't go healthy. Logs show WireGuard "initialization successful" every time, then every healthcheck DNS lookup times out. Tried this across multiple different Nord server IPs — same result every time. What I ruled out, in order, with Tom AI: Wrong/stale private key → regenerated fresh from Nord's WireGuard config generator. Same failure. Mismatched WIREGUARDADDRESSES vs key → regenerated both together from the same downloaded Nord config file. Same failure. ISP/router blocking WireGuard UDP → ruled out, NordVPN's own app connects fine on the same network. FIREWALLOUTBOUNDSUBNETS overlapping the tunnel's 10.x.x.x address (default 10.0.0.0/8 swallowing 10.5.0.2/32) → set FIREWALLOUTBOUNDSUBNETS=192.168.0.0/16,172.16.0.0/12 and restarted media. Still same failure. The real kicker: I took the exact same private key + address from the same Nord config and manually set up a plain WireGuard client on my computer — connects fine, no issues. Then I signed up for Surfshark instead and plugged those creds into SparkBox/gluetun — works immediately, no problem. So it's not my credentials, not my network, not my .env config — something specific to how gluetun negotiates with NordVPN's WireGuard (NordLynx) endpoints is failing, while a stock WireGuard client and a different provider both work fine through the same box. Running Surfshark under a week free trial for now since it works, but flagging this in case gluetun's Nord server list/endpoint handling needs a look (I still have 2 years left in my nord subscription so if it can be helped i dont want have to pay for two vpns) Happy to pull more logs/details if useful.
9 replies
Chris wrote:
Really thorough writeup — thank you for ruling all that out before posting. The detail that cracks it is one you probably thought was just a control: a stock WireGuard client doesn't use encrypted DNS. SparkBox's tunnel does, and it's on by default. Every lookup inside the tunnel goes out encrypted, and on some Nord endpoints that never gets through — so the tunnel builds fine, and then every health check times out. Surfshark lets it through, which is why swapping providers looked like it fixed the box. Costs nothing to test, and your DNS still rides inside the VPN: sudo sparkbox set-env VPNDOT off sudo sparkbox restart media Give it about two minutes to settle. If gluetun still won't go healthy after that, say so and I'll take you to the next lever, which is packet size. Either way I've flagged the Nord side to Tom — he handles these personally. Your box should have pointed you at this itself instead of leaving you looking at a second subscription. — Chris
noliver2761 wrote:
tried sudo sparkbox set-env VPNDOT off sudo sparkbox restart media and it didnt work,, sparkbox ai said "There's no sparkbox set-env command — that's not a real SparkBox CLI subcommand, so that reply gave you something that doesn't exist. Don't trust that blindly. " lol then told me to try echo 'VPNDOT=off' | sudo tee -a /opt/sparkbox/.env sudo sparkbox restart media but i bascially got the same error heres what TomAI said: Same exact failure — VPNDOT wasn't it either. It's a straight DNS lookup timeout (lookup github.com: i/o timeout), not a TLS/DoT-specific block, across four different Nord IPs again. The forum "DoT" theory doesn't match what's actually in the logs. At this point every plausible .env-side lever has been pulled and ruled out by direct evidence: key, address, outbound subnet range, DoT. All produce the identical signature — tunnel handshake completes, then literally nothing gets through it. That's consistent with something on Nord's side rejecting or black-holing traffic from this specific gluetun setup/endpoint pattern, while your OS-level WireGuard client and Surfshark-via-gluetun both work fine.
Chris wrote:
That one's on me — and Tom AI was right. sudo sparkbox set-env genuinely did not exist on v1.6.464; it shipped the next day, in v1.6.465. Sorry for the wasted round. Your workaround did apply the setting though, so encrypted DNS is properly ruled out. I'm also not going to send you down the packet-size ladder I promised — that one is for a tunnel logging a handshake timeout, and yours logs a plain lookup timeout. Different fault. What fits everything you found: SparkBox saves a copy of Nord's server list when you install, and never refreshes it. Nord rotates the keys on those servers, so a saved-once list connects and then carries nothing — while a config you download fresh from Nord works. That is your exact result. sudo rm /opt/sparkbox/modules/media/config/gluetun/servers.json sudo sparkbox restart media SparkBox deletes that same file itself whenever it spots it damaged, so this is a normal repair and it rebuilds on the next start. If it still won't go healthy, it's ours — Tom has this now, with your writeup. You shouldn't be paying for two subscriptions over it. — Chris
Chris wrote:
One correction before you spend a round on that delete: the list rebuilds from a version-pinned copy of gluetun, so it can't hand you newer Nord keys than the ones already failing. What fits your evidence: with Provider set to NordVPN, SparkBox uses gluetun's built-in server list and its stored keys, ignoring the PublicKey and Endpoint lines in the config you downloaded. That's exactly why that file works in the plain WireGuard app but not here. In the dashboard's VPN settings set Provider to "Other / Custom", open "Advanced — custom / unlisted provider", and paste Server IP, Server Port and Server Public Key from that same Nord file. That pins you to one server — if Nord retires it, paste a fresh Endpoint. — Chris
noliver2761 wrote:
This did not work. error message: Restart failed — settings were saved, but the media stack did not come back up cleanly. Most likely cause: • The tunnel connects, but nothing inside it can look up an address — so the VPN's own health check times out and it restarts, over and over. Fix: Try this first: turn off the "encrypted DNS (DoT)" option in VPN settings and save. It is ON by default and some VPN servers block it; your traffic still goes through the VPN either way. If that changes nothing, the tunnel isn't carrying traffic at all — re-check your VPN key and address, and on WireGuard try putting 1280 in the "WireGuard MTU" box (then 1220).
Chris wrote:
Four rounds in and still dead — that is longer than this should have taken, and the reason is partly ours. If your box is still on 1.6.464, that matters: the tool built for exactly this fault only shipped in 1.6.476, which is why nobody has offered it to you yet. Upgrade first, or you will hit the same unknown-command dead end as last time: sudo sparkbox upgrade Then in Settings → VPN set Provider back to NordVPN — the refresh does nothing while you are on Custom — and run: sudo sparkbox refresh-vpn-servers It pulls a current server list from Nord, from outside the tunnel. Our own notes name stale Nord keys as the worst failure there is: connected, nothing passing through. That is yours exactly. If it still will not go healthy, Tom takes it from there. — Chris
noliver2761 wrote:
Yeah im on the most recent version of sparkbox and its not working. can we ping tom?
noliver2761 wrote:
the fix was to use openvpn instead of wireguard... for some reason sparkbox rejects wireguard with nordvpn
Chris wrote:
Really glad OpenVPN got you a working tunnel — that's a legitimate way to run it, not just a stopgap. On the 'rejects WireGuard' theory: I don't think it's NordVPN specifically being blocked, it's more likely the same stale-embedded-key issue refresh-vpn-servers is built for — WireGuard in provider mode pulls keys from gluetun's bundled list, OpenVPN authenticates live with your own credentials instead, which lines up with exactly what you're seeing. You already upgraded and ran the refresh and it still didn't clear it, which is more than I have a fix for right now. Per the promise earlier in this thread, I'm flagging it to Tom — he'll take it from here.