In enterprise networking, multi-site infrastructure engineering, and distributed homelab topologies, establishing secure, high-throughput inter-site connectivity is an essential operational requirement. Connecting branch offices, remote development centers, cloud VPCs, and secondary disaster recovery facilities historically meant deploying legacy VPN technologies: IPsec (IKEv2) or OpenVPN. Yet across thousands of enterprise networks, these legacy tunneling protocols inflict continuous operational friction. IPsec’s labyrinthine multi-phase negotiation rituals, cryptographic phase mismatches, and fragile Network Address Translation Traversal (NAT-T) daemons cause tunnels to stall unpredictably after transient WAN disconnects. OpenVPN, operating as a bloated single-threaded userspace daemon, inflicts severe CPU bottlenecks, struggling to saturate modern gigabit fiber connections while generating massive packet latency. The modern cryptographic antidote that has transformed site-to-site networking is WireGuard. Developed by Jason A. Donenfeld, WireGuard operates as an ultra-lean, opinionated in-kernel tunneling protocol that delivers line-rate throughput with minimal CPU overhead. When implemented on open-source firewall platforms like OPNsense via the native FreeBSD kernel module (wireguard-kmod), WireGuard provides enterprise-grade site-to-site mesh performance. However, migrating site-to-site production traffic to WireGuard on OPNsense frequently traps network engineers in insidious, silent failure modes: mysterious packet loss, frozen SSH sessions, web pages hanging indefinitely at 90% load, and asymmetric routing black holes. These failures stem directly from two critical configuration domains: Maximum Transmission Unit (MTU) / MSS Clamping and Cryptokey Routing (AllowedIPs). Here is Garrison Drake’s forensic SecOps architecture guide to configuring high-throughput WireGuard site-to-site tunnels on OPNsense, resolving MTU fragmentation, implementing TCP MSS clamping, and mastering multi-subnet cryptokey routing.

Garrison Drake’s Perimeter Routing Verdict: WireGuard is hands-down the fastest, most reliable site-to-site VPN protocol available on OPNsense, but it does not forgive sloppy layer-3 planning. Unlike IPsec or OpenVPN, WireGuard does not dynamically negotiate MTU sizes, and its Cryptokey Routing engine binds access control directly to the routing table. If you experience hanging TCP sessions, fragmented packets, or one-way traffic over your OPNsense tunnel, your MTU is improperly sized and your intermediate firewalls are dropping ICMP fragmentation notifications. By deploying the native FreeBSD wireguard-kmod kernel module, clamping TCP Maximum Segment Size (MSS) to exactly 1380 bytes, and assigning dedicated OPNsense interface gateways with explicit AllowedIPs CIDRs, you achieve a wire-speed, zero-maintenance site-to-site tunnel that recovers from WAN drops in under a second.

Why Does WireGuard Outperform IPsec and OpenVPN for Site-to-Site Links?

Direct Answer: WireGuard operates as a lightweight, state-free in-kernel tunnel using modern ChaCha20-Poly1305 cryptography, delivering up to 4x higher throughput and 75% lower CPU overhead than OpenVPN while avoiding the multi-phase IKEv2 negotiation complexity and protocol fragility of IPsec.

To understand why WireGuard has achieved industry dominance in high-performance networking, one must compare the architectural mechanisms of the three primary VPN tunneling protocols:

1. Codebase Minimalism & Attack Surface Reduction: Legacy IPsec implementations (like strongSwan or racoon) and OpenVPN comprise hundreds of thousands of lines of code. They support legacy, compromised cryptographic ciphers (such as DES, 3DES, MD5, and SHA-1) to preserve backward compatibility. Auditing these sprawling codebases is extraordinarily difficult, leading to recurring vulnerabilities in certificate parsing and state management. WireGuard deliberately eliminates cryptographic agility: it mandates a single, modern cryptographic suite—ChaCha20 for symmetric encryption, Poly1305 for authentication, Curve25519 for ECDH key exchange, and BLAKE2s for hashing. The entire WireGuard codebase is under 4,000 lines of code—a 96% reduction compared to OpenVPN—making it completely auditable by human security researchers.

2. In-Kernel Execution (wireguard-kmod vs OpenVPN): In traditional OpenVPN deployments on FreeBSD and Linux, the OpenVPN daemon runs as a userspace process. For every single network packet entering the firewall, the operating system must copy the packet from the network card into kernel memory, context-switch to userspace to allow OpenVPN to encrypt or decrypt the payload, and context-switch back into the kernel to transmit the packet. This constant userspace-to-kernel context switching saturates the CPU, restricting OpenVPN to roughly 150 Mbps to 300 Mbps on typical quad-core firewall hardware. WireGuard on OPNsense operates via wireguard-kmod, a native FreeBSD kernel module. Encryption, decryption, encapsulation, and packet forwarding execute entirely within the kernel’s network stack, effortlessly sustaining multi-gigabit wire speed with minimal CPU utilization.

3. Connectionless Stealth & Instant Recovery: IPsec and OpenVPN are chatty, stateful protocols. They maintain active sessions via continuous keepalives and renegotiate security associations (SAs) periodically. When a WAN connection experiences a brief drop or IP address change, IPsec tunnels frequently lock up in a “half-open” state, requiring manual restarts. WireGuard is completely connectionless and silent. When no data is traversing the tunnel, WireGuard transmits zero packets; to an external network scanner, the UDP port appears completely closed. When data arrives, WireGuard performs a single round-trip handshake in under 5 milliseconds. If a WAN link drops and recovers, or if a dynamic WAN IP changes, WireGuard seamlessly resumes packet flow instantaneously with zero dropped sessions.

Architecture Comparison: WireGuard vs IPsec vs OpenVPN on OPNsense

Tunneling Feature Vector WireGuard (kmod) IPsec (IKEv2 / strongSwan) OpenVPN (DCO Enabled)
Cryptographic Suite Fixed: ChaCha20-Poly1305, Curve25519, BLAKE2s Negotiable: AES-GCM, AES-CBC, SHA-2, DH Groups Negotiable: AES-256-GCM, ChaCha20-Poly1305, TLS CA
Codebase Size & Complexity ~4,000 Lines (Ultra-lean, easily auditable) 100,000+ Lines (Massive multi-daemon stack) 70,000+ Lines (Sprawling OpenSSL dependency)
Kernel Integration (OPNsense) Native FreeBSD Kernel Module (wireguard-kmod) Native Kernel IPsec Stack with Hardware AES-NI Userspace Daemon (or DCO kernel acceleration)
Gigabit Throughput Scalability Line Rate (950+ Mbps on quad-core Celeron/N100) High (800+ Mbps with AES-NI hardware offload) Moderate (250-450 Mbps; CPU bottlenecked)
Roaming & Reconnection Latency Sub-second (< 5 ms handshake on reconnect) Sluggish (5 to 30 seconds for IKE re-authentication) Sluggish (10 to 45 seconds for TLS renegotiation)
Routing Paradigm Cryptokey Routing via AllowedIPs binding Policy-Based (SPD) or Routed (VTI / GRE over IPsec) Routed TUN/TAP with server push-route directives
MTU / Header Encapsulation 60 to 80 Bytes fixed overhead (Requires MSS clamp) Variable overhead depending on ESP cipher/padding 60 to 80 Bytes overhead + HMAC tag padding
Configuration Simplicity Public/Private key pairs; minimal parameters Complex: Phase 1 & 2 proposals, identifiers, NAT-T Moderate: PKI management, client certificates, CAs

The MTU and MSS Clamping Mathematical Teardown

The single most destructive issue plaguing WireGuard site-to-site deployments on OPNsense is Packet Fragmentation and Path MTU Black Holes. Network administrators frequently report that after establishing an OPNsense WireGuard tunnel, simple commands like ping or traceroute work flawlessly, but web browsing hangs indefinitely, large file copies fail instantly, and interactive SSH sessions freeze the moment a user executes ls -la or cat on a large file.

This failure is governed by the mathematics of IP packet encapsulation:

  • Standard Ethernet Frame MTU: Standard physical local area networks enforce a Maximum Transmission Unit (MTU) of 1,500 bytes. When a host on your LAN transmits data, it expects to send full 1,500-byte packets.
  • WireGuard IPv4 Encapsulation Overhead: To transmit a packet across the internet securely, WireGuard encapsulates the original packet inside an outer UDP packet. The encapsulation overhead consists of:
    • Standard IPv4 Outer Header: 20 bytes
    • UDP Transport Header: 8 bytes
    • WireGuard Header & Poly1305 Authentication Tag: 32 bytes
    • Total IPv4 WireGuard Overhead = 60 bytes
    Therefore, the maximum internal payload size that can fit inside a 1,500-byte outer Ethernet frame is 1500 - 60 = 1440 bytes.
  • WireGuard IPv6 Encapsulation Overhead: If your WAN connection utilizes IPv6, the outer IPv6 header is 40 bytes (instead of 20 bytes). The total overhead increases to 40 + 8 + 32 = 80 bytes, reducing the allowable internal payload to 1500 - 80 = 1420 bytes.
  • The PPPoE WAN Compounding Trap: Many fiber-to-the-home (FTTH) and DSL internet service providers utilize PPPoE authentication on the WAN. PPPoE consumes an additional 8 bytes of encapsulation, reducing your physical WAN MTU from 1,500 to 1,492 bytes. In an IPv6 PPPoE environment, the allowable WireGuard payload drops to 1492 - 80 = 1412 bytes!

The Path MTU Discovery (PMTUD) Black Hole: Under standard Internet Protocol specifications, when a router receives a packet larger than its outgoing interface MTU, it drops the packet and transmits an ICMP Type 3, Code 4 (“Destination Unreachable, Fragmentation Needed and DF Set”) packet back to the sender, instructing it to reduce its packet size. However, across the public internet, thousands of misconfigured firewalls and ISP middleboxes drop all ICMP packets unconditionally as a misguided “security” measure. As a result, the sending server never receives the PMTUD notification. The sender continuously retransmits full 1,500-byte packets, the OPNsense firewall is forced to drop them, and the TCP connection stalls indefinitely in an unrecoverable Black Hole.

The Definitive SecOps Solution: TCP MSS Clamping: Rather than attempting to reconfigure the MTU on hundreds of individual client workstations and servers across your enterprise, OPNsense can rewrite the TCP handshake parameters dynamically using TCP Maximum Segment Size (MSS) Clamping. During the initial TCP three-way handshake, client and server exchange SYN packets containing the MSS option, defining the largest segment they can accept. In OPNsense, clamping MSS inspects every SYN packet traversing the WireGuard interface and rewrites the MSS value to a safe, unfragmentable ceiling. For IPv4, the mathematical standard is WireGuard MTU - 40 bytes (TCP + IP headers). With a conservative WireGuard MTU of 1420, clamping the TCP MSS to 1380 bytes eliminates packet fragmentation and black-hole stalls forever.

Cryptokey Routing and the AllowedIPs Configuration Trap

The second most frequent engineering trap on OPNsense is misunderstanding WireGuard’s Cryptokey Routing table. In traditional IPsec, access control and routing are decoupled: IPsec policies define encryption, while the kernel routing table directs traffic. In WireGuard, AllowedIPs performs both functions simultaneously.

The AllowedIPs setting on an OPNsense peer defines two immutable rules:

  1. Egress Routing (Outbound): When OPNsense forwards a packet into the WireGuard interface, it searches the AllowedIPs lists across all configured peers. The packet is encrypted with the public key of the peer whose AllowedIPs matches the packet’s destination IP (longest prefix match). If the destination IP is not explicitly covered by a peer’s AllowedIPs, OPNsense drops the packet immediately.
  2. Ingress Filtering (Inbound): When OPNsense decrypts a packet received from a peer, it checks the packet’s source IP against that peer’s AllowedIPs. If the source IP does not match the AllowedIPs configured for that cryptographic key, WireGuard silently discards the packet. This prevents IP spoofing across the mesh.

The Disaster of 0.0.0.0/0 in Site-to-Site Peers: In road-warrior client setups, setting AllowedIPs = 0.0.0.0/0 directs all client traffic through the VPN. However, in a site-to-site configuration connecting two OPNsense firewalls, setting AllowedIPs = 0.0.0.0/0 on the peer definition instructs OPNsense that the remote peer owns the entire internet. This can overwrite default gateway routes, hijack local management interfaces, and create routing loops. For site-to-site tunnels, AllowedIPs must contain strictly the remote tunnel IP and the specific remote LAN/VLAN subnets (e.g., 10.100.0.2/32, 192.168.20.0/24, 10.50.0.0/16).

Actionable SecOps Playbook: OPNsense Site-to-Site WireGuard Setup

Follow this exact step-by-step engineering roadmap to deploy a production, high-availability site-to-site WireGuard tunnel between two OPNsense firewalls (Site A and Site B).

Network Topology Example:
Site A LAN: 192.168.10.0/24 | Site A Tunnel IP: 10.100.0.1/30 | Public IP: 203.0.113.10
Site B LAN: 192.168.20.0/24 | Site B Tunnel IP: 10.100.0.2/30 | Public IP: 198.51.100.20

  1. Verify wireguard-kmod Kernel Package: In OPNsense, navigate to System > Firmware > Plugins. Ensure os-wireguard is installed. In modern OPNsense releases (24.x+), the high-performance wireguard-kmod kernel module is active by default. Verify in the OPNsense shell: 
    kldstat | grep if_wg
  2. Configure Site A Local Instance: Navigate to VPN > WireGuard > Instances. Click + to add a new instance:
    • Name: WG_SITE2SITE
    • Listen Port: 51820
    • Tunnel Address: 10.100.0.1/30
    • MTU: 1420
    • Click Generate Keypair. Copy the generated Public Key (send to Site B admin).
  3. Configure Site A Endpoint (Peer Definition for Site B): Navigate to VPN > WireGuard > Endpoints. Click +:
    • Name: PEER_SITE_B
    • Public Key: [Paste Site B’s Public Key]
    • Endpoint Address: 198.51.100.20 (or dynamic FQDN)
    • Endpoint Port: 51820
    • Allowed IPs: 10.100.0.2/32, 192.168.20.0/24
    • Keepalive Interval: 25 (Maintains state through upstream NAT routers)
    Return to the Instance tab, edit WG_SITE2SITE, and select PEER_SITE_B under Peers. Apply changes.
  4. Configure Site B (Mirror Topology): On Site B, repeat the process with mirrored values:
    • Tunnel Address: 10.100.0.2/30 | MTU: 1420
    • Endpoint Peer Address: 203.0.113.10:51820
    • Allowed IPs: 10.100.0.1/32, 192.168.10.0/24
    • Keepalive Interval: 25
  5. Create Interface Assignment & Gateway on OPNsense: To enable advanced firewall filtering and static routing, assign WireGuard as a managed interface:
    • Navigate to Interfaces > Assignments. Assign wg0 to a new interface (e.g., OPT_WG). Enable the interface, leaving IPv4/IPv6 configuration type as None.
    • Navigate to System > Gateways > Configuration. Add a new Gateway on interface OPT_WG with IP 10.100.0.2 (the remote tunnel IP).
    • Navigate to System > Routes > Configuration. Add a static route for destination network 192.168.20.0/24 pointing to the OPT_WG gateway.
  6. Enforce TCP MSS Clamping on the WireGuard Interface: To eradicate hanging TCP connections and packet black holes forever:
    • Navigate to Interfaces > [OPT_WG].
    • Under MSS, enter 1380.
    • Alternatively, navigate to Firewall > Settings > Normalization. Create a Scrub rule: Interface OPT_WG, Protocol TCP, Max MSS: 1380. Apply settings.
  7. Open Firewall WAN Rules and Allow Inter-Site Traffic:
    • On the WAN interface, add a firewall rule passing incoming IPv4 UDP traffic on destination port 51820.
    • On the OPT_WG interface, create an allow rule passing traffic from source 192.168.20.0/24 to destination 192.168.10.0/24.
  8. Forensic Verification & Throughput Validation: In the OPNsense shell, verify active tunnel handshake status: 
    wg show
    Verify that the output displays an active handshake within the last 25 seconds and non-zero transfer bytes. Test MTU size without fragmentation across the tunnel: 
    ping -D -s 1392 10.100.0.2
    Run iperf3 between LAN hosts across sites to confirm sustained line-rate gigabit throughput with zero CPU starvation.
Garrison Drake’s Operational Check: If SSH sessions freeze or SMB file transfers stall at 99%, execute a packet capture on the WireGuard interface while reproducing the issue. If you see repeated TCP retransmissions with packet lengths hovering around 1460 to 1500 bytes, your MSS clamping rule is not firing. Enforcing MSS 1380 guarantees smooth, wire-speed packet delivery across any underlying ISP transport.
Enterprise Intrusion Prevention Architecture:

Before synchronizing multi-site tunnel networks, deploy collaborative host-level defense across your endpoints with CrowdSec vs Fail2ban: Multi-Server Threat Intel Mesh.

Enterprise Intrusion Prevention Architecture:

Before synchronizing multi-site tunnel networks, deploy collaborative host-level defense across your endpoints with CrowdSec vs Fail2ban: Multi-Server Threat Intel Mesh.

High-Availability Tunnel Resilience:

Pair redundant site-to-site WireGuard gateways with high-availability firewall failover using our masterclass on OPNsense HA Cluster: CARP Failover & XMLRPC Sync Guide.

Core Operating System Hardening:

Secure the underlying host operating system running your WireGuard tunnels with our complete guide to Linux Kernel Hardening: Sysctl Parameters & BPF-LSM Guide.

Zero-Trust Identity Federation:

Enforce unified multi-factor authentication across your internal WireGuard endpoints with our comparison of Authentik vs Keycloak: Self-Hosted OIDC & SAML SSO TCO.

Deep Network Telemetry & Threat Hunting:

Gain full visibility into packet anomalies traversing your cross-datacenter tunnels with our forensic breakdown of Zeek vs Suricata: Network Metadata vs Signature Detection.