March 18, 2026

I Blamed My ISP For Three Months. It Was My Router.

I blamed my ISP for months. The problem was my router.

The Upgrade

I was running an AX12 as my main router. Fine for what it was, but I’d upgraded from gigabit to 2.5Gbps fiber and wanted more: VLANs, WireGuard for backups, proper policy-based routing. So I picked up a UniFi Express 7. Prosumer hardware, clean UI, should handle 2.5Gbps without breaking a sweat.

Set it up with a basic config: WireGuard client, to route backup traffic through the tunnel, a couple VLANs. Everything else goes straight out the WAN. Should be straightforward, right?

Wrong. This thing decided that routing some traffic through a VPN is a feature you can have, but only if you accept a broken implementation that actively makes your connection worse.

Something Was Wrong

After the switch, things felt off. Slower browsing, packet loss to Discord and games, occasional stutters. Speeds nowhere near what I’d expect on a 2.5Gbps line.

Bahnhof routes everything through Sweden before it hits Danish peering. That’s legitimately a thing that adds some latency. I figured that was it. The network had always been a little Sweden-shaped, so I didn’t immediately look at the router.

I Filed a Support Ticket

After a few weeks of it not clearing up, I opened a ticket with Bahnhof. They ran their tests and . No issues on their end. Pointed at a Hetzner/Netnod peering problem at hop 9 for the Hetzner-specific spikes.

They weren’t wrong exactly. The Sweden routing is just how Bahnhof is built. And there was a real Hetzner peering issue. Look at this . Hop 9 hits Netnod and explodes. 304ms, then 322ms, 376ms into core-backbone. By the time it reaches Hetzner we’re at 319ms.

And it wasn’t just me. Look at this . Anders gets 33ms to that same 168.119.98.204. I get 319ms. Same server, different ISPs, 10x the latency.

So the Hetzner peering issue was real. But here’s the thing: Discord doesn’t route through Hetzner. CS2 doesn’t route through Hetzner. Those were still dropping packets and stuttering while the Hetzner traceroute was clean to other destinations.

I ran traceroutes to Danish destinations:

tracert ookla.kviknet.dk
7   5ms  mmo1-er1.se.as8473.net   ← Sweden
8   6ms  dix.ip.ip.nianet.net     ← Danish IX, normal latency

For good measure, here’s . 7ms to Denmark, totally clean.

Everything looked normal. 5-7ms through Sweden, expected latency at the Danish IX. Nothing broken in the path. Which meant whatever was causing the Discord packet loss and game stutters wasn’t out there. It was before the first hop. At my router.

It Was My Network

Here’s the embarrassing part. The traceroutes looked fine because the problem was happening before the traffic even left my apartment.

I finally ran a proper Waveform bufferbloat test. . Download at 369 Mbps on a 2.5Gbps line. Latency spiking to +113ms under load. Jitter at 171ms. Audio calls, video conferencing, low latency gaming all getting warning icons.

That’s a local problem. That’s the router.

And to make it worse, a fresh UniFi install with zero config only manages out of the box. I’d been adding the PBR rule on top of hardware that was already underperforming.

The Config

Let me be clear about what I was asking this thing to do. My is as plain as possible: DHCP, no VLAN tag, no PPPoE, DNS at 1.1.1.1. The shows Smart Queues off, IGMP off, UPnP off.

Security: , , . No IDS/IPS. No deep packet inspection. Just route packets and NAT them.

The is a wall of auto-generated rules with truncated “Multiple zones” and ”…” descriptions everywhere. You can’t see what any of it actually does without clicking into each rule one by one. Try debugging a routing issue in that mess.

I’m not asking this thing to do deep packet inspection or IDS/IPS while also doing VPN routing. It’s literally: route packets, NAT them, and for one destination send remote backup traffic through a WireGuard tunnel. That’s it. And it still manages to tank performance for the entire network.

The Speedtest History

Here’s my , provider Bahnhof. None of this traffic goes through the VPN. All of it is regular WAN traffic:

Date	Ping (ms)	Download	Upload	Notes
02/26/2026 11:38 PM	457ms	777 Mbps	498 Mbps	UniFi, PBR on.
02/26/2026 11:41 PM	695ms	639 Mbps	474 Mbps	UniFi, PBR on. 695ms ping.
03/07/2026 8:48 PM	7ms	374 Mbps	558 Mbps	UniFi, PBR on.
03/17/2026 11:30 PM	6ms	2,103 Mbps	2,372 Mbps	OPNsense, first test.
03/17/2026 11:41 PM	6ms	2,141 Mbps	2,372 Mbps	OPNsense again.
03/18/2026 12:19 AM	47ms	814 Mbps	1,908 Mbps	UniFi for comparison.

That 695ms ping on 2.5Gbps fiber. Not through the VPN, just from having a PBR rule in the routing table.

The 03/17 to 03/18 gap is the clearest comparison. Same fiber, same night, same test server. OPNsense at 11:30 PM: 2,103 Mbps, 6ms. UniFi at 12:19 AM: 814 Mbps, 47ms. Not even close.

Switching to OPNsense

Tonight I needed a new router ASAP. The only PC I had lying around? My old gaming rig. i5-13500, RTX 2080, 64GB RAM. Added two 2.5Gb NICs and now it’s a firewall. My router has better specs than most people’s desktops.

I left hardware offloads : no checksum offload, no TCP segmentation, no large receive offload. Same WireGuard PBR config that was destroying UniFi.

immediately. , 6ms ping. All use cases green. Life is good.

So to recap: a “prosumer” UniFi Express 7 gets spanked by a retired gaming PC that probably still has RGB RAM in it. OPNsense with hardware offloads disabled delivers 5x the download speed and a letter grade better latency than UniFi with everything stripped back. The same test that gives me a C on UniFi gives me an A on OPNsense. Same fiber. Same WireGuard PBR config. Different router.

Why This Happens (Probably)

Ubiquiti’s docs are clear about QoS: Enabling QoS rules disables hardware offloading on the gateway and may reduce throughput for all clients and networks, not just those affected by the rule. They give a 24–45% drop for traffic over 1 Gbps. The PBR docs say nothing about offload or performance. So either PBR is different, or they just don’t document it.

User reports line up with the second option. People see one traffic or routing rule cut throughput in half for the whole network, not just the rule’s target. My numbers match: one PBR rule, full network degradation. So the exact conclusion: when you enable PBR (or likely any policy-based feature), UniFi probably turns off hardware offload for all traffic, same as with QoS. Every packet goes through the CPU. The fast path is gone.

OPNsense with the same PBR config keeps full line rate and good bufferbloat. So either it keeps a fast path for non-matching traffic or the software path is just fast enough. Either way, the same workload doesn’t tank the network.

The UniFi UI doesn’t expose whether offloads are active or how the packet processor is handling traffic. What you see is what the web UI shows.

The Takeaway

I spent months convinced my ISP was partly to blame. To be fair, the Sweden routing is real, and there was a genuine Hetzner peering issue for a while. But neither of those was causing the Discord drops and the game stutters. That was me running a router that couldn’t handle its own config.

Fresh UniFi install: Grade B. Add one PBR rule: Grade C, 369 Mbps on a 2.5Gbps line, jitter that makes games unplayable. OPNsense on a retired gaming rig with an RTX 2080: Grade A, full line rate, first try.

My old AX12, 269 DKK, about 40 EUR, had better Wi-Fi range than the UniFi Express 7. Didn’t have VLANs or WireGuard, but at least it wasn’t quietly breaking things while I blamed my ISP.

If you need VPN routing, don’t trust UniFi to handle it. Use a real firewall. And if your network feels wrong, check the router before you open a support ticket.

Update: I messed up the subnet—said 192.168.1.1 when everything (including my Proxmox servers) lived on 192.168.0.x. Had to go back to the Express 7 so the apartment would work again. Currently on Express 7 with WireGuard disabled until I fix the OPNsense config. So maybe it’s also just expectations.

Marius, on OPNsense now (well, Express 7 for now)