Tired of your WireGuard disconnecting and the on-calls not knowing what to do about it? Well, the settings they gave us during training are labeled as "NEVER DO THIS" on the wireguard official documentation, so... no shit your connection is failing every couple minutes.

But fear not! I will share with you the best practices from the official wireguard docs.

WireGuard: Three Config Settings That Break Your Tunnel (Silently)#

WireGuard tunnels can fail without any error message — the connection just stops working and you have no idea why. These three settings are the most common causes. Fix them once and forget about them.

---

1. Open the editor#

You have to go to your station and press edit on wireguard.

From there you are going to make the next changes...

2. Set PersistentKeepalive = 15 (or lower)#

The rule: Keep this value at 15 seconds or below.

Routers — especially cheap ones and mobile carrier networks — forget about your tunnel after 20–30 seconds of silence. WireGuard fixes this by sending a tiny "I'm still here" packet every N seconds. Set N to 15 and you stay safely under even the most aggressive routers.

If you set it higher (25–60s): the router forgets the tunnel before the next packet arrives. The tunnel dies with no error on either side — it only breaks when you actually try to send data.

---

3. Set MTU = 1280#

The rule: Don't go above 1280.

WireGuard wraps every packet in its own encryption layer, adding ~60 bytes of overhead. If your packets are already at the network's size limit (typically 1500 bytes), those 60 extra bytes push them over — and they get silently dropped or broken apart, degrading your connection.

1280 bytes is the universal safe size: it works on all networks including mobile, and leaves plenty of room for WireGuard's overhead.

Only raise MTU above 1280 if you've explicitly tested your full network path with path MTU discovery — otherwise you're guessing.

---

4. Delete DNS in your WireGuard config#

The rule: Leave the DNS field empty.

Despite its name, the DNS field doesn't actually manage DNS — it just injects a server address into the OS when the tunnel starts. This creates two traps:

• DNS leaks: If the DNS server isn't reachable through the tunnel, queries quietly bypass it and go out unencrypted — defeating the whole point.
• Silent breakage: If DNS is forced through the tunnel but can't be reached, everything fails. And it looks like a generic network error, not a DNS problem, making it very hard to debug.

What to do instead: Configure DNS at the OS level, or use systemd-resolved or dnsmasq for proper split-DNS control.

---

Quick reference#

Setting	Value	Why
PersistentKeepalive	15	Prevents NAT tables from dropping the session
MTU	1280	Avoids fragmentation from WireGuard's ~60-byte overhead
DNS	DELETE!	Prevents leaks and silent resolution failures

---

The common thread: all three failures are silent. No logs, no errors — just a tunnel that stops working or leaks data without telling you.

So it should look something like this...