Setup: SparkBox, media module, gluetun v3.41.1 VPNPROVIDER=surfshark, VPNTYPE=wireguard WIREGUARDPRIVATEKEY + WIREGUARDADDRESSES=10.14.0.2/16 both set (generated fresh from Surfshark's manual WireGuard setup page) SERVERCOUNTRIES=United States, no city/hostname pinned Confirmed no duplicate WIREGUARDPRIVATEKEY line in .env (grep -c returns 1) Symptom: gluetun connects to a WireGuard endpoint, logs "Wireguard setup is complete," then fails the startup healthcheck ~7 seconds later with: running TLS handshake: context deadline exceeded It then restarts and tries a different Surfshark server IP each time (saw 37.19.221.86, 138.199.2.132, 212.102.44.91, 185.156.46.110 in one log window) — same failure every time, never completes a handshake. What already works: Same box, same .env, switched to VPNTYPE=openvpn with the same Surfshark account creds — connects fine, passes healthcheck, shows "healthy" in docker ps. So it's WireGuard-specific, not a general connectivity/firewall block on this network. (OpenVPN does have its own separate MTU/EMSGSIZE log spam issue, but that's not blocking connection — flagging as unrelated context.) Question: Is this a known Surfshark WireGuard key generation issue, an MTU/UDP block specific to WireGuard's port, or something in gluetun's healthcheck for Surfshark WG endpoints? Any known .env tweak (e.g. forcing a specific WG MTU, disabling the TLS healthcheck target) that fixes this?
10 replies
Chris wrote:
That sequence matches a known gluetun DNS-over-TLS failure mode more than a bad Surfshark key: the WireGuard tunnel completes, then encrypted DNS health times out and gluetun cycles. In the Media Center settings, open Advanced and set Encrypted DNS (VPNDOT) to off, save, and let SparkBox restart Media Center. DNS still travels inside the encrypted WireGuard tunnel; this only disables the extra DNS-over-TLS layer. Please report whether the server cycling stops. If not, post only the last 30 lines around the TLS error from sb-gluetun with any keys redacted—never post the private key or full .env. The separate OpenVPN MTU warning can stay separate for now.
johnnyjj wrote:
pdate: Ruled out network — same failure on a hotspot too Followed up on both suggestions: DoT/VPNDOT off — set VPNDOT=off in .env, ran sparkbox up media to apply. No change. Identical cycling, same running TLS handshake: context deadline exceeded error, still hopping to a new Surfshark endpoint every ~7 seconds. Network isolation test — connected the box via a phone hotspot instead of my home network/ISP. Same exact failure. WireGuard sets up, then times out on the handshake, cycles to a new server IP, repeats. Since this reproduces identically on two completely different networks, it rules out my router or ISP blocking WireGuard/UDP 51820. Fresh log sample (hotspot test), several different Surfshark endpoints, all identical failure: Connecting to 64.44.86.157:51820 → Wireguard setup is complete → WARN restarting VPN because it failed to pass the healthcheck: running TLS handshake: context deadline exceeded (x2 parallel attempts) → stopping/starting → repeat with new IP Confirmed again: OpenVPN with the same Surfshark account/creds connects fine and passes healthcheck on this same box. So it's WireGuard-specific, not a general Surfshark/account/connectivity issue. At this point I've ruled out: bad private key formatting (checked, single clean line in .env), DNS-over-TLS, single bad server, router/ISP blocking. Given it fails identically across totally different networks, this looks like either a Surfshark WireGuard key/account issue or something on the gluetun/container side. Appreciate any more specific direction — happy to pull any other log window or config detail needed.
tomspark wrote:
Good detective work ruling out the network with the hotspot test — that narrows it a lot. Honest read: OpenVPN connecting cleanly on the same box with the same account means you lose nothing by staying on it for now — same encryption, same kill-switch, fully protected. The WireGuard side failing the handshake right after "setup is complete" looks like a WireGuard packet-size quirk that SparkBox doesn't currently expose as a setting, so rather than hand you a guess that might not stick, I've flagged the exact behavior to Tom — he handles these personally and I'd rather you get the verified fix than a shot in the dark. The OpenVPN MTU log spam is just noise, not blocking anything. Stay on OpenVPN meanwhile and I'll follow up here once there's a real WG fix.
Chris wrote:
Following up as promised: Tom shipped the fix today in v1.6.434, and your report is what it was built from. Run sudo sparkbox update, then in Media Center settings open Advanced and set WireGuard MTU to 1320 — if it still cycles, try 1280 — then apply with sudo sparkbox up media. Leave it blank on any box that is working. One correction to what you were told earlier: the hotspot test does not rule this out. Hotspots usually have a lower path MTU, which makes it more likely, and it is why OpenVPN was fine — it clamps packet size automatically and WireGuard does not. Let me know if it goes healthy.
Chris wrote:
That advice needs a correction, and it is mine to make: 1320 was never going to change anything — it is already gluetun's own default. And 1280 still needs your link to carry 1340 bytes, because WireGuard adds about 60 to every packet. Tom corrected the whole ladder in v1.6.442. Over SSH: sudo sparkbox update echo 'WIREGUARDMTU=1280' | sudo tee -a /opt/sparkbox/.env sudo sparkbox restart media Still cycling? Step down to 1220, then 1160. If that file already has a WIREGUARDMTU line, change that one rather than adding a second. And the OpenVPN EMSGSIZE spam you set aside as unrelated isn't — if it prints a Path-MTU number, use that minus 80 and skip the ladder.
johnnyjj wrote:
Thank you Tom and Chris, Updated all the way to v1.6.451 (had to run sparkbox update twice — first attempt left the Media module stuck in "created" state on qBittorrent/Sonarr/Radarr/Prowlarr/FlareSolverr/SABnzbd until I re-ran the update and then sparkbox up media). Switched VPNTYPE back to wireguard in .env to test the fix, but: No "Advanced" section or WireGuard MTU field anywhere in the Media module's settings page in the dashboard. Checked .env directly: grep -n "MTU" /opt/sparkbox/.env returns nothing — no MTU key exists at all. So the fix described in the earlier reply (set WireGuard MTU to 1320/1280 under Media Center → Settings → Advanced) doesn't seem to actually be present on my box, even on v1.6.451. Not sure if this is a rollout gap, a channel issue (I'm on Stable), or something that didn't fully ship. For now I've switched back to OpenVPN since it's the tunnel that's actually been connecting cleanly. Can someone confirm whether the MTU field/setting is supposed to be live yet, and if so what I'm missing?
Chris wrote:
It is live on v1.6.451 — you were sent looking in the wrong place, and that is on us. There is no Advanced section on that page: the row sits on the main Settings page, in the Media Center group, labelled WireGuard MTU. It also appears even though your file has no MTU line, so that grep is not the test — saving the field writes the line for you. If the row really is not there, suspect the update rather than the release. You mentioned the first run left containers sitting in created; sudo sparkbox doctor calls out anything that exists but never started. Staying on OpenVPN meanwhile is sensible. One honest note: this same setting did not come good on another box, so Tom is still digging into it.
johnnyjj wrote:
Hey Chris — followed up on this. Manually set WIREGUARDMTU=1220 in .env (found a duplicate line from an earlier edit, cleaned that up) and ran sudo sparkbox restart media. Gluetun came up healthy immediately, got a real public IP, and every downstream container (qbit, sonarr, radarr, sabnzbd, prowlarr, bazarr, seerr) came up healthy right behind it. No restart-looping since. I didn't see a WireGuard MTU row in Settings/Media Center — went straight to the .env edit. Can check that field specifically if useful for you, but wanted to confirm on my end: this is working now via the manual edit.
Chris wrote:
Best possible outcome — and 1220 wasn't a lucky guess: it's the exact middle rung of the ladder we document (1280, then 1220, then 1160), so that's a supported value, not a workaround. Keep it. Clearing that duplicate probably mattered as much as the number — a second line is exactly the trap the tee -a command you were given sets. On the row you couldn't find: it is on the Settings page in the Media Center group, but it isn't labelled plainly. The label runs on as "WireGuard MTU (lower this if WireGuard cycles on 'TLS handshake: context deadline exceeded')", which is very easy to scan straight past. Yes — please do check, it'd genuinely help. Twice now we've sent you to the wrong place, and Tom should hear that this field is this hard to find.
Chris wrote:
To close out the check you offered to run — you don't need to. You were right: there was no Advanced section. That field has been marked advanced in the module all along, but only the first-run install wizard ever read the flag, so Settings rendered everything flat and our own help text pointed at a heading that existed nowhere. Tom shipped that as v1.6.455 today, off the back of this thread. Run sudo sparkbox upgrade and the row sits under an Advanced heading in the Media Center group — collapsed, but the heading is always showing. Separately, that double-update with apps stuck in Created was a real bug too, fixed in v1.6.453. Leave your 1220 as it is.