I blamed my ISP for three months. It was my router.

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

Update: October 2, 2026

I’d just lived with it for a while, but finally spent another hour debugging the Express 7. Hardware acceleration was disabled in my default configuration, even after a factory reset. Enabling it and restarting the router fixed the issue.

So the conclusion below is probably wrong. I blamed PBR without ever actually proving it was the cause. For me, the fix was turning on hardware acceleration and rebooting. I’m leaving the original troubleshooting here anyway, since it’s how I got there.

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, one PBR rule (policy-based routing) 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 came back clean. No issues on their end. They 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 traceroute to a Hetzner server. 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 comparison. 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 Discord doesn’t route through Hetzner. CS2 doesn’t route through Hetzner. Those were still dropping packets and stuttering, and traceroutes to everything else looked clean.

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 Østednettet. 7ms to Denmark, totally clean.

Everything looked normal. 5-7ms through Sweden, expected latency at the Danish IX, nothing broken in the path. So 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

I finally ran a proper Waveform bufferbloat test. Grade C. 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 Grade B out of the box. I’d been adding the PBR rule on top of hardware that was already underperforming.

The Config

My WAN setup is as plain as possible: DHCP, no VLAN tag, no PPPoE, DNS at 1.1.1.1. The network overview shows Smart Queues off, IGMP off, UPnP off.

Security: basic content filter, everything else disabled, logging off. No IDS/IPS. No deep packet inspection. Just route packets and NAT them.

The firewall rule table 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 full speedtest history, provider Bahnhof. None of this traffic goes through the VPN. All of it is regular WAN traffic:

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 intentionally disabled: no checksum offload, no TCP segmentation, no large receive offload. Same WireGuard PBR config that was destroying UniFi.

Grade A immediately. 2,103 down / 2,372 up, 6ms ping. All use cases green. Life is good.

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 gets 5x the download speed and a full letter grade better on bufferbloat than UniFi with everything stripped back. Same fiber, same WireGuard PBR config, C on one router and A on the other.

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.[1] 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 point to the second option. People see a single traffic or routing rule cut throughput in half for the whole network, not just the traffic the rule targets. My numbers match that: one PBR rule, whole network slower. My guess is that enabling PBR (and probably any policy-based feature) makes UniFi turn off hardware offload for all traffic, same as QoS, so every packet goes through the CPU.

OPNsense with the same PBR config keeps full line rate and good bufferbloat. Either it keeps a fast path for traffic that doesn’t match the rule, or the software path is just fast enough. Either way, it doesn’t tank the network.

The UniFi UI doesn’t expose whether offloads are active or how the packet processor is handling traffic.

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. I set 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)