Why You Should Offload WireGuard VPN from Your Primary Router to a Node

Offloading WireGuard from your primary router (like an AX3000T) to your node router (like an MX4200) delivers significant performance gains for your main network.

When a router handles a WireGuard tunnel, it isn’t just forwarding raw IP packets—it is continuously running cryptographic calculations and handling software-level packet processing. Here is why shifting this responsibility to a secondary node can dramatically improve your network performance.

1. Major Reduction in CPU Usage 🔗

• Crypto Processing Removed: WireGuard relies on modern cryptography (ChaCha20-Poly1305 for encryption/authentication and Curve25519 for key exchange). Encryption and decryption are CPU-heavy operations. By offloading this to the MX4200, the AX3000T’s CPU cores no longer spend clock cycles encrypting and decrypting every byte of VPN traffic.
• Fewer Context Switches & SoftIRQs: Processing high-throughput WireGuard traffic generates frequent software interrupts (SoftIRQs) to handle packet encapsulation/decapsulation in the Linux kernel. Offloading wg0 frees the AX3000T CPU to focus entirely on core routing, NAT, and LAN traffic management.

2. Hardware Offloading (Fast-Path Acceleration) 🔗

• Main Router Flow Offloading: On the AX3000T (MediaTek Filogic architecture), standard IPv4/IPv6 packet forwarding and NAT can be offloaded directly to the hardware PPE (Packet Processing Engine).
• The VPN Bottleneck: WireGuard interfaces (wg0) usually cannot take full advantage of hardware packet offloading because packets must pass through kernel memory for encryption.
• The Gain: Now, the AX3000T simply sees VLAN 9 traffic as standard Layer 2 / Layer 3 packets being switched/routed to the MX4200. This allows the AX3000T to use hardware acceleration for almost all passing local traffic.

3. Improved Overall Network Latency & Jitter 🔗

• Bufferbloat Mitigation: High CPU load caused by concurrent VPN traffic can cause packet queues to back up, increasing bufferbloat and latency spikes (jitter) for non-VPN devices on your main network (like gaming PCs or local streaming devices).
• Load Distribution: High-bandwidth workloads on your VPN (e.g., 4K streaming or large downloads) now consume CPU cycles on the MX4200, leaving the AX3000T cool, responsive, and ready for your primary LAN segment.

Architectural Summary 🔗

                      [ AX3000T - Main Gateway ]
                  (PPPoE WAN / Primary Router / AdGuard)
                                  │
                                  │ Trunk Link (VLAN 1 & VLAN 9)
                                  ▼
                      [ MX4200 - Node Router ]
            (Dedicated WireGuard / DHCP Server 10.10.9.x)
                                  │
               ┌──────────────────┴──────────────────┐
               ▼                                     ▼
      [ SSID: SanJose ]                     [ AX3000T - SanJose ]
  (Bridged to br-wifi-vpn)               (Bridged via br-lan.9)

1. Layer 2 Bridge: VLAN 9 carries all 10.10.9.0/24 broadcast/DHCP traffic seamlessly across both access points (AX3000T and MX4200).
2. Layer 3 Processing: Pure offload achieved. The AX3000T performs standard hardware switching, while the MX4200 handles 100% of the crypto, policy routing (Table 200), and VPN encapsulation.

Performance Summary 🔗

This dynamic separation gives you an optimal setup: your primary router operates purely as a high-speed WAN gateway and switch, while your secondary node acts as a dedicated VPN acceleration appliance. Ultimately, it is much better to spread the workload and responsibility across your network hardware, fully utilizing the secondary node’s CPU power instead of leaving it to run as a really “dumb” WiFi access point.