Does Hardware NAT Offload Break Your VPN Routing Rules?

Turning on hardware NAT acceleration can make a VPN setup faster, and it can also make a routing policy stop applying to some packets without any error at all. Which of those happens depends on what the fast path skips, and that differs between firmware, kernel version and the kind of acceleration in use. The settings menu rarely tells you which one you just enabled.

Two claims deserve separating before the accelerator gets blamed: that a rule stopped being enforced, and that a counter stopped being updated. They are not the same observation.

Three Different Accelerations Get Blended Together

Forwarding offload, cryptographic acceleration and tunnel data-channel offload are separate mechanisms that often share a single switch. Forwarding offload lets established flows skip part of the normal stack, cryptographic acceleration makes cipher work cheaper, and tunnel offload moves encapsulation into hardware. A router accelerating ordinary routed traffic may leave tunnel traffic on the slow path entirely, which is a performance outcome rather than a policy change. The reverse also exists, where tunnel traffic is offloaded while the surrounding policy still evaluates.

Linux flowtables are the documented case most worth reading, since established flows can be handed to a fast path. Their accounting and state handling then differ from classic forwarding, which is why the counters start to look strange.

A Counter That Stops Moving Proves Little

Rule counters count the packets that pass through the rule, and an offloaded flow may never pass through it again after the first packet. That produces a counter which freezes while traffic continues, and it looks exactly like a bypass if you trust the number. Watching the counter is still useful as a hint that the flow left the counted path. The rest of the diagnosis has to come from where the packets actually go.

The opposite inference fails just as badly. A fast download does not show that your exception rules and failure handling still apply, because it exercises one flow and not the policy.

Three Conditions Decide Whether Offload Breaks Policy

The first condition is whether the fast path consults the hook your policy depends on, since a policy expressed as marks and routes survives more often than one built from per-packet filtering. The second is whether the firmware permits the combination at all, because some builds disable offload automatically when a tunnel or a firewall feature is active. The third is whether the traffic is eligible, since acceleration is usually keyed to established flows and may exclude fragmented or unusual packets. Where all three favour acceleration the policy still applies, and where the first one fails no amount of tuning restores it.

Read the vendor documentation for the combination you are running rather than for the router model in general. Firmware versions change these answers quietly.

Test the Policy, Not the Throughput

Measure what the policy is supposed to guarantee before measuring how fast it goes. The commands below show whether a flowtable is installed, what connection tracking sees, and which address the client exits from. Compare a new connection after the change, since an established one may keep its old path.

nft list flowtables
conntrack -L | head -n 20
curl -sS --max-time 8 https://api.ipify.org; echo
ping -c 3 192.168.50.20

A flowtable entry covering the tunnel traffic tells you the fast path is in play, and the connection table shows whether the flow is tracked the way you expect. The address check confirms the exit when the policy concerns internet egress, while the ping confirms a private destination that should remain reachable. Run the same set with acceleration off and then on, and compare the results rather than the timings.

Record the previous setting so the experiment stays reversible. A generic instruction to disable offload everywhere counts as a workaround, not as a finding.