How to Set Up WireGuard on OPNsense: Road Warrior, Site-to-Site

If you want a fast, low-overhead VPN on your OPNsense firewall, knowing how to set up WireGuard on OPNsense is the single most practical skill in this stack. If you have not settled on WireGuard yet, weigh it against the alternative in WireGuard vs OpenVPN on your firewall. WireGuard has been native to the OPNsense base system since version 24.1 — no plugin required on current releases — and its kernel-level implementation consistently outperforms both OpenVPN and IPsec on the same hardware. This guide covers the road warrior (remote client access) case in full, then addresses site-to-site differences, with notes on firewall rules, MSS clamping, and the gotchas that break handshakes silently.

Prerequisites and Version Notes

Before touching any WireGuard menus, confirm which OPNsense release you are running.

• OPNsense 24.1 and later: WireGuard is included in the base system. Navigate directly to VPN → WireGuard after logging in; no plugin step is needed.
• OPNsense 22.x / 23.x: Install the os-wireguard plugin via System → Firmware → Plugins. Search for wireguard, click the install icon, then refresh the web UI. The VPN → WireGuard menu appears after the refresh.

You will also need:

• A WAN interface with a reachable public IP (or a DDNS hostname that resolves reliably — see the caveat on hostname resolution below).
• UDP port 51820 open inbound on the WAN firewall rule. WireGuard does not use TCP; any TCP-based port forward will have no effect.
• WireGuard client software on the remote device: the official clients cover Windows, macOS, Linux, iOS, and Android.

Road Warrior Setup: Remote Client Access

This is the most common pattern — a phone or laptop connecting to your home or office network from outside.

1. Create the Server Instance

Go to VPN → WireGuard → Instances and press +.

Field	Value
Enable	checked
Name	anything descriptive, e.g. wg0
Listen Port	51820 — you must type this even though it is the default; the field does not auto-populate
Tunnel Address	A private CIDR block not in use elsewhere, e.g. 10.10.10.1/24
MTU	1420 (default); use 1412 if your WAN is PPPoE

Leave the Private Key field empty on first save — the key pair is generated automatically. After saving, the public key appears in the list. Copy it: clients need it. Press Apply.

2. Add Client Peers

Go to VPN → WireGuard → Peers and press + for each remote device.

Field	Value
Enable	checked
Name	descriptive label for the device
Public Key	paste the public key generated on the client device
Allowed IPs	a unique /32 from your tunnel subnet, e.g. 10.10.10.2/32
Keepalive Interval	25 if the client is behind NAT; leave empty otherwise

Link the peer back to the instance by opening the instance again and selecting this peer in the Peers dropdown. Save and Apply.

3. Enable the Service

Go to VPN → WireGuard → General, tick Enable WireGuard, and click Apply. The Status tab will show the interface coming up and handshake timestamps once clients connect.

4. Assign the WireGuard Interface

Assigning a WireGuard group interface in Interfaces → Assignments lets OPNsense generate automatic outbound NAT rules and gives you a named interface for firewall rules. Select the WireGuard group from the dropdown, save, then enable the new interface with a recognizable description (e.g., WIREGUARD).

5. Firewall Rules

Two rules are required:

WAN rule — allows the initial handshake:

• Interface: WAN
• Protocol: UDP
• Destination port: 51820
• Action: Pass

WireGuard interface rule — allows tunnel traffic to reach your LAN:

• Interface: WIREGUARD (the assigned interface)
• Source: WIREGUARD net
• Destination: any (or restrict to specific LAN subnets)
• Action: Pass

MSS clamping — without this, large TCP packets fragment and stall. Go to Firewall → Settings → Normalization and add a rule:

• Interface: WIREGUARD
• Direction: any
• Max MSS: 1380 (IPv4); 1360 (IPv6)

6. Client Configuration

Each client needs a configuration file (or QR code) with:

[Interface]
PrivateKey = <client private key>
Address = 10.10.10.2/32
DNS = 10.10.10.1

[Peer]
PublicKey = <OPNsense instance public key>
Endpoint = <your WAN IP or DDNS hostname>:51820
AllowedIPs = 0.0.0.0/0   # full-tunnel; restrict to 10.10.10.0/24 for split-tunnel
PersistentKeepalive = 25

OPNsense’s peer generator under VPN → WireGuard → Peer Generator can produce this file and a scannable QR code automatically.

Site-to-Site Configuration

Connecting two OPNsense firewalls is structurally the same as road warrior, with three differences:

1. Both sides run an instance. Site A gets 10.2.2.1/24 as its tunnel address; Site B gets 10.2.2.2/24.
2. Allowed IPs on each peer include the remote LAN. If Site B’s LAN is 192.168.1.0/24, Site A’s peer entry for Site B should list both 10.2.2.2/32 and 192.168.1.0/24 as Allowed IPs.
3. Dynamic WAN IP handling. If one site has a dynamic IP, leave its Endpoint Address field empty on the static-IP side. WireGuard on OPNsense resolves hostnames once at startup; if you rely on a DDNS hostname for the dynamic side, you need a cron job or keepalive to refresh the resolution. This is a known limitation documented by OPNsense.

Firewall rules for site-to-site follow the same pattern: WAN allow UDP 51820 inbound, WireGuard interface allow traffic between the two LAN subnets.

Security Hardening

The baseline setup above is functional but leaves two hardening steps on the table.

Pre-shared keys (PSK): WireGuard supports an optional symmetric PSK layered on top of its Curve25519 key exchange. Adding a PSK means that compromising one side’s private key alone is not sufficient to decrypt captured traffic. The equivalent setup on the other platform is covered in WireGuard on OPNsense vs pfSense. Generate one with wg genpsk and add it to both the OPNsense peer entry and the client configuration file. This adds no measurable latency.

Restrict Allowed IPs per peer: Avoid 0.0.0.0/0 in the OPNsense peer’s Allowed IPs field unless you genuinely want that client to reach everything. Restricting to 10.10.10.x/32 limits the blast radius if a client device is compromised.

Key rotation has no built-in scheduler in OPNsense; coordinate it manually or via a configuration management tool. Regenerating keys requires updating both the peer entry on OPNsense and the client configuration file simultaneously, then re-applying the tunnel. Stagger the swap by less than the PersistentKeepalive interval or the tunnel will drop mid-rotation.

Common Failure Modes

• No handshake, ever: Check that the WAN firewall rule exists and allows UDP (not TCP) on 51820. Verify the public keys match exactly — a single character mismatch produces no error, only silence.
• Handshake succeeds but traffic drops: Missing MSS clamping is the most frequent cause. Set Max MSS to 1380 on the WireGuard interface normalization rule.
• “os-wireguard (missing)” error on 24.1+: The standalone plugin is deprecated. Update via System → Firmware → Status and let the native implementation take over. For choosing the box this runs on, see best mini PC for OPNsense.
• Tunnel drops after a few minutes on NAT: Set PersistentKeepalive = 25 on the client side to keep the NAT mapping alive.

Related across the network

• OPNsense Port Forwarding: NAT Rules That Actually Work — opnsenselab.com
• How a Tailscale Mesh VPN Works: Coordination, NAT and ACLs — tailscaleguide.com