OPNsense WireGuard Site to Site Tunnel: Routing Setup

An opnsense wireguard site to site tunnel connects routed networks over encrypted UDP. The goal here: let trusted clients reach a remote NAS while keeping IoT devices isolated and each site’s internet traffic local. WireGuard carries IP packets; it does not extend your Ethernet broadcast domain. WireGuard’s overview explains that distinction.

Topology

Use this example at both sites: OPNsense LAN port → USW-Pro-24-PoE port 1 → AP on port 2. OPNsense WAN → ISP → internet → remote OPNsense WAN.

Ports 1–2 are trunks: native VLAN/PVID 1 for trusted clients and AP management; 802.1Q tag 20 for the IoT SSID. Port 3 is an untagged VLAN 1 access port; port 4 is an untagged VLAN 20 access port. Permit no tagged VLANs on access ports. Ubiquiti documents these port settings.

VLAN plan

These addresses and ports are example design choices. DHCP ranges use each row’s subnet prefix; OPNsense supplies DHCPv4 and the default gateway locally. Renumber overlapping subnets before proceeding.

VLAN ID	Name	CIDR	DHCP range	Gateway IP	Inter-VLAN policy
1	A-trusted	10.10.10.0/24	.100–.199	10.10.10.1	Deny; remote NAS exception
20	A-iot	10.10.20.0/24	.100–.199	10.10.20.1	Deny all
1	B-trusted	10.20.10.0/24	.100–.199	10.20.10.1	Deny; stateful replies
20	B-iot	10.20.20.0/24	.100–.199	10.20.20.1	Deny all

Reserve 10.20.10.20 for the NAS. The transfer network is 10.2.2.0/24, with no DHCP. This walkthrough configures IPv4; dual-stack deployment also needs remote IPv6 prefixes in Allowed IPs and corresponding firewall policy. OPNsense’s site-to-site guide covers that extension.

Configure instances, peers and routes

WireGuard is built into OPNsense following its core inclusion in 24.1. Older plugin-install instructions are unnecessary on current releases. Start with reachable public WAN addresses; the NAT variant follows below.

Under VPN → WireGuard → Instances, create an enabled instance at each site and generate separate keypairs. Keep private keys local. Configure:

Setting	Site A	Site B
Tunnel address	10.2.2.1/24	10.2.2.2/24
Listen port	UDP 51820	UDP 51820
Peer public key	B’s public key	A’s public key
Peer Allowed IPs	10.2.2.2/32, 10.20.10.0/24	10.2.2.1/32, 10.10.10.0/24
Peer endpoint	B’s public address:51820	A’s public address:51820

Create those peers under Peers, select each in its local instance, save/apply, and enable WireGuard globally. Leave Disable routes unchecked: OPNsense installs routes from peer Allowed IPs. No manually configured tunnel gateway is needed for this design. OPNsense’s VPN reference describes these controls.

Allowed IPs selects the outbound peer and validates decrypted source addresses. It does not authorize application ports. Exclude IoT prefixes and avoid 0.0.0.0/0 for this split-routing design. WireGuard calls this cryptokey routing.

Preserve original LAN source addresses across the tunnel. Inspect Firewall → NAT → Outbound for broad rules translating tunnel traffic; ordinary WAN internet NAT stays enabled. OPNsense documents outbound NAT matching.

Firewall rules

Define WAN_A and WAN_B aliases containing the actual public endpoint addresses. Define INTERNALS as all four LAN CIDRs above plus 10.2.2.0/24. Use inbound, IPv4, quick rules; source ports are any. Apply this order within each indicated interface:

WAN, each site: remote WAN alias → local WAN address, UDP destination 51820, pass; otherwise default deny.
B WireGuard group: 10.10.10.0/24 → 10.20.10.20/32, TCP 443, pass; then any → any, block. A WireGuard group: any → any, block for new sessions.
Each trusted/IoT interface: its subnet → its gateway IP, TCP/UDP 53, pass; then its subnet → any, TCP/UDP 53, block.
A trusted only: 10.10.10.0/24 → 10.20.10.20/32, TCP 443, pass, gateway default.
Each trusted/IoT interface: its subnet → INTERNALS, any protocol/port, block. Keep scoped local administration and DHCP permissions above this block; existing internet permissions go below it.

Replies use existing states. Reverse-initiated access needs corresponding B-LAN and A-WireGuard exceptions. Floating rules precede group rules, which precede interface rules; an earlier broad pass can shadow these restrictions. Clear affected states when retesting changed policy. OPNsense explains processing order and states.

DNS and discovery

Give clients their local gateway as DNS. Add an Unbound host override for nas.site-b.example → 10.20.10.20 at both sites; allow local client subnets in Unbound ACLs. Scope DNS blocklists and required vendor-domain exceptions by IoT source subnet. These allow-list exceptions are not a default-deny internet policy. Unbound’s documentation covers overrides, ACLs and source-specific filtering.

Bonjour/mDNS uses link-local multicast, including 224.0.0.251:5353/UDP; ordinary routing will not make discovery cross this tunnel. Keep mDNS reflection off unless explicitly designed and tested. See RFC 6762: Multicast DNS. IGMP snooping controls local multicast forwarding; it does not create cross-site discovery. UniFi’s switch reference separates these functions.

CGNAT, dynamic WANs and MTU

For a NATed site, initiate toward the reachable site and configure Keepalive interval = 25 seconds on the NATed side. WireGuard’s quick start explains why this preserves idle NAT mappings. A receiving firewall behind your own router needs UDP 51820 forwarded to it; keep UPnP off. With an unpredictable initiator address, leave its endpoint blank on the responder and allow any WAN source to UDP 51820; peer keys still authenticate it. OPNsense documents this responder arrangement.

CGNAT shared space includes 100.64.0.0/10, defined by RFC 6598: IANA-Reserved IPv4 Prefix for Shared Address Space. If neither site accepts inbound traffic, arrange a reachable public endpoint or hub; keepalive alone cannot supply one.

For changing endpoint hostnames, schedule Renew DNS for WireGuard on stale connections under System → Settings → Cron. Adjust WAN source restrictions when peer addresses change. Start with MTU 1420, or 1412 for the guide’s PPPoE case; lower values may be necessary. Under Firewall → Settings → Normalization, clamp WireGuard-group IPv4 TCP MSS to at most MTU minus 40: 1380 for MTU 1420. OPNsense’s guide documents both fixes.

Things to test before you call it done

From an A-trusted Linux host, temporarily permit ICMP and TCP 5201 to the NAS on A-LAN, B-WireGuard and its host firewall. Run the server on the NAS:

iperf3 -s -B 10.20.10.20

Then run on the A client:

ping -c 4 10.20.10.20
mtr -n -r -c 10 --tcp --port 443 10.20.10.20
dig @10.10.10.1 nas.site-b.example A +short
iperf3 -c 10.20.10.20 -t 10
iperf3 -c 10.20.10.20 -t 10 -R

Expect the NAS address from DNS; compare throughput in both directions using ESnet’s documented iperf3 modes. Generate traffic and inspect WireGuard Diagnostics: no handshake points to endpoint/key/UDP reachability; a handshake with failed LAN access points to routes, Allowed IPs or filtering. Small packets working while transfers stall warrants the documented MTU/MSS checks.

Repeat the NAS probe from IoT: it must fail. Remove temporary permissions and stop iperf3 afterward. Retest after WAN reconnection and idle periods. Follow Tech Sentinel’s cybersecurity coverage for maintenance context; a successful handshake is not the end of firewall maintenance.