Sign in Subscribe
4 min read Networking

How to Stick to 5GHz Wi-Fi on a Home Server (When a Secure Tunnel Is Routing You Through the Wrong Gateway)

How to Stick to 5GHz Wi-Fi on a Home Server (When a Secure Tunnel Is Routing You Through the Wrong Gateway)

I run a small self-hosted setup at home: a Linux server on my local network, connected to a cloud VPS via WireGuard so I can securely expose a couple of personal services to the internet without needing a public IP from my ISP.

One day I ran a routine speed test on that machine and got a result that made no sense.

The symptom

Testing from [cloud provider network]...
Hosted by [ISP] (a city ~2,300 km away): 51.871 ms
Download: 57.89 Mbit/s
Upload: 162.05 Mbit/s

I'm nowhere near that city. My ISP plan is 1 Gbps. I was sitting about 20cm from a 5GHz-capable router. None of this matched a distant, slow result.

Ruling out the obvious stuff

First instinct: bad Wi-Fi. Checked the link:

signal: -40 dBm
rx bitrate: 866.6 MBit/s
tx bitrate: 780.0 MBit/s

That's a strong, fast link. Not the problem.

Second instinct: wrong speedtest tool, or a geolocation glitch in the server picker. Checked my actual public IP:

$ curl -s https://ipinfo.io
{
  "ip": "[redacted]",
  "city": "[my actual metro area]",
  "org": "[cloud provider]"
}

My public IP genuinely resolved to my correct metro area — but it belonged to my cloud VPS provider, not my home ISP. That was the real clue. My server's traffic wasn't leaving through my home connection at all; it was leaving through a datacenter, then getting matched to a "best" test server based on network routing, not geography.

Finding the actual path

A traceroute made it obvious:

$ traceroute -n 8.8.8.8
 1  10.x.x.1      26.266 ms
 2  10.x.x.x      27.250 ms
 3  10.x.x.x      27.225 ms
 4  10.x.x.x      27.132 ms
 5  [public IP]   27.158 ms   <- first public hop, cloud provider range

Hop 1 at 26ms is the tell. A real LAN gateway responds in under a millisecond. A 26ms first hop means the "gateway" is already on the other side of an encrypted tunnel.

The actual cause

I run WireGuard on this box specifically so a remote cloud server can reverse-proxy traffic in to my self-hosted services. Checking the tunnel:

$ sudo wg show
interface: wg0
peer: [redacted]
  endpoint: [redacted]
  allowed ips: 0.0.0.0/0

There it was. AllowedIPs = 0.0.0.0/0 tells WireGuard "route everything through this tunnel" — not just traffic meant for the reverse proxy. That's the correct setting for a full VPN (e.g., "route my whole laptop through a VPN for privacy"). It's the wrong setting for a reverse-tunnel-only setup, where you only want traffic destined for the tunnel's own subnet to go through it.

Every outbound request from this server — DNS lookups, speed tests, everything — was quietly detouring through the remote datacenter and then out to the wider internet from there, which is why the speedtest's server-selection logic (based on network path, not physical distance) landed on a server thousands of kilometers away.

The fix

Narrowed the scope of the tunnel to just its own point-to-point subnet:

# Before
AllowedIPs = 0.0.0.0/0

# After
AllowedIPs = 10.x.x.0/24

sudo wg-quick down wg0
sudo wg-quick up wg0

Immediately, traceroute hop 1 dropped from 26ms to under 1ms — confirming outbound traffic was now going straight out my real ISP connection instead of tunneling through the remote server first.

A DNS side effect

The WireGuard config also had a custom DNS server pushed by wg-quick — previously fine under full-tunnel routing, but after narrowing AllowedIPs, DNS queries to that server had no route out (since it wasn't inside the newly narrowed subnet). Removing that line from the config fixed resolution.

One more gremlin: Wi-Fi band flapping

While debugging, I also noticed the machine occasionally dropped from 5GHz to 2.4GHz despite sitting right next to the router. This turned out to be unrelated to WireGuard — my mesh Wi-Fi system's client steering feature was actively trying to manage band selection, and combined with the laptop's own roaming logic, it occasionally picked 2.4GHz for no obvious reason. Turning off client steering in the mesh system's app stabilized the connection on 5GHz.

The result

$ speedtest
   Server: [local ISP server]
      ISP: [my actual ISP]
Download:   502.48 Mbps
  Upload:   579.73 Mbps

Same hardware, same Wi-Fi, same ISP plan. The only thing that changed was a single line in a config file written months earlier and forgotten was still wide open.

Takeaways

  • A "best server" pick based on ping isn't the same as a geographically close server. Network routing can make a distant server look "closer" in latency than one nearby.
  • AllowedIPs = 0.0.0.0/0 means "route everything," not "allow everything to reach this peer." For reverse-tunnel-only setups, scope it to the tunnel's own subnet.
  • Standard routing tools won't always show WireGuard's routing if it uses fwmark-based policy routing. Use ip route show table all and ip rule show to see the full picture, or just check wg show directly.
  • When a number looks wrong, trace the actual path the traffic takes — traceroute, curl ipinfo.io, and wg show told the whole story faster than staring at the speedtest output ever would have.
  • If your device won't stick to 5GHz even right next to the router, check your mesh system's client/band steering settings before assuming it's a hardware or signal issue.

Published by:

Yafes D.

Member discussion