Interconnecting distributed homelabs, remote offices, and sovereign cloud environments historically required configuring complex, fragile IPsec tunnels or bloated OpenVPN daemon stacks. While IPsec provides robust encryption, its sprawling cipher negotiation suites and NAT traversal issues routinely create synchronization headaches. WireGuard has revolutionized site-to-site networking by stripping away legacy protocol bloat, delivering state-of-the-art ChaCha20-Poly1305 cryptography, and operating directly inside the kernel with blazing throughput and near-zero latency.

WireGuard Cryptokey Routing: How Site-to-Site Actually Works

To configure WireGuard successfully in OPNsense, you must understand its foundational networking concept: Cryptokey Routing. WireGuard associates public encryption keys directly with authorized IP address ranges (`AllowedIPs`):

• Outbound Routing Filter: When an OPNsense firewall evaluates an outbound packet destined for a remote subnet, it consults the peer’s `AllowedIPs` list. If the destination IP matches, the packet is encrypted using that peer’s public key and encapsulated in a UDP datagram.
• Inbound Cryptographic Verification: When an encrypted packet arrives on the UDP listening port (default 51820), WireGuard decrypts the payload. If the decrypted inner packet source IP does not match the `AllowedIPs` associated with the transmitting peer’s public key, the packet is immediately dropped. This prevents IP spoofing by design.
• Stateless UDP Simplicity: Unlike IPsec or OpenVPN, WireGuard has no concept of a “connection.” Peers simply exchange authenticated UDP packets. If a dynamic WAN IP changes on one side, sending a single packet updates the peer’s endpoint automatically.
• Kernel-Space Execution: In FreeBSD 14 and OPNsense, WireGuard executes as an in-kernel network driver (`if_wg`). Packet encryption occurs directly in the network stack, avoiding expensive context switching between kernel space and user space that slows down OpenVPN.
• Cryptographic Cookie Handshakes: Under high-volume Distributed Denial of Service (DDoS) flood attacks, WireGuard responds with encrypted cryptographic cookies rather than stateful handshakes, protecting firewall CPU and RAM from exhaustion.
• Noise Protocol Framework Security: WireGuard is built on the Noise Protocol Framework using 1-RTT handshakes with Curve25519 for key exchange, ChaCha20 for authenticated encryption, and Poly1305 for message authentication codes, guaranteeing forward secrecy.

Network Topology Architecture: Site A vs Site B

Consider two remote sites that need seamless, bidirectional inter-VLAN routing:

Step-by-Step Configuration Guide in OPNsense

Follow these architectural steps to bring up the site-to-site link cleanly:

1. Install WireGuard Plugin: In OPNsense, go to System > Firmware > Plugins and install `os-wireguard`. This deploys the official high-speed FreeBSD in-kernel WireGuard driver.
2. Generate Keypairs and Instances: Navigate to VPN > WireGuard > Instances. Create an instance named `WG_S2S` with Tunnel Address `10.10.0.1/30` on Site A. Generate the private and public keys. Repeat on Site B with `10.10.0.2/30`.
3. Define Peer Relationships: In VPN > WireGuard > Peers, add Site B’s public key on Site A. Set Endpoint to Site B’s WAN IP/DDNS and critically set **AllowedIPs** to `10.10.0.2/32, 192.168.20.0/24`. Set **Keepalive to 25 seconds** to ensure NAT states across consumer firewalls remain permanently open.
4. Assign Interface and Gateway: Go to Interfaces > Assignments and assign the new `wg0` device to an interface (e.g. `OPT1_WG`). Navigate to System > Gateways > Configuration and create a static gateway pointing to the remote peer’s tunnel IP (`10.10.0.2`).
5. Add Static Route: Go to System > Routes > Configuration and create a static route for the remote subnet (`192.168.20.0/24`) utilizing your new WireGuard gateway.
6. Configure Firewall Rules: On WAN, add a rule allowing UDP port 51820. On the newly assigned WireGuard interface, create an allow rule permitting ICMP and IP traffic between the two LAN subnets.
7. Configure Outbound NAT Bypass: Under Firewall > NAT > Outbound, ensure hybrid or manual mode is active and that traffic routed across the WireGuard tunnel interface is exempted from NAT translation, preserving original client IP addresses for auditing.

Dynamic Routing Alternatives: BGP over WireGuard

In complex multi-site networks where routes change dynamically, maintaining static route tables becomes fragile. By installing the `os-frr` plugin in OPNsense, engineers can run the Border Gateway Protocol (BGP) across the WireGuard tunnel interface. Each site announces local subnets dynamically, enabling automatic failover to backup tunnels without manual administrator intervention.

MTU Clamping and MSS Optimization

Because WireGuard encapsulates IP packets inside UDP datagrams, it adds 60 to 80 bytes of overhead. If standard 1500-byte packets are sent across the tunnel, packets will fragment, causing catastrophic throughput drops and broken HTTPS web sessions.

To eliminate fragmentation, set the WireGuard interface MTU to 1420 bytes. Furthermore, enable **MSS Clamping** in OPNsense under Interfaces > [WireGuard Interface] with an MSS clamp value of 1380. This forces TCP handshakes to limit packet size automatically, ensuring smooth multi-gigabit transfers.