Reference architecture — VPN and remote access

The reference architecture assumes two kinds of VPN:

• Site-to-site: between OPNsense estates at different physical sites, for branch-to-datacentre and datacentre-to-cloud traffic.
• Remote access: between travelling administrators or remote users and the corporate estate.

WireGuard is the default for both. IPsec is used when a partner mandates it or when integrating with a legacy device.

Site-to-site with WireGuard

Topology:

Site A (HQ)                                  Site B (Branch)
OPNsense-A                                     OPNsense-B
  WAN: 203.0.113.2/29                           WAN: 198.51.100.2/29
  LAN: 10.0.0.0/16                              LAN: 10.50.0.0/24
    |                                              |
    +-- WireGuard tun_wg0: 10.99.0.1/30 ---------+
                Allowed IPs:
                  A → B: 10.50.0.0/24
                  B → A: 10.0.0.0/16

Each side has a WireGuard instance with a single peer (the other site). The interface tun_wg0 has a /30 from the 10.99.0.0/16 tunnel range. The Allowed IPs are the LANs of each site.

Configuration steps:

1. Generate a key pair on each OPNsense.
2. Create a WireGuard instance on each, bound to its WAN interface, listening on UDP 51820.
3. Add the remote peer with the remote’s public key, Allowed IPs covering the remote LAN and the WireGuard tunnel, and the remote’s WAN endpoint.
4. Assign the WireGuard interface to OPNsense and give it a /30 address from the tunnel range.
5. Add a firewall rule on the WireGuard group allowing the tunnel traffic to reach the LAN.
6. Add a static route for the remote LAN via the WireGuard tunnel.

$ wg show wg0

interface: wg0
public key: <pubkey-a>
private key: (hidden)
listening port: 51820

peer: <pubkey-b>
endpoint: 198.51.100.2:51820
allowed ips: 10.99.0.0/30, 10.50.0.0/24
latest handshake: 12 seconds ago
transfer: 1.42 MiB received, 824.31 KiB sent
persistent keepalive: every 25 seconds

Remote access with WireGuard

Remote access uses a slightly different pattern:

• A dedicated WireGuard instance on a separate tunnel address range (e.g. 10.99.1.0/24).
• Each remote user is a peer, with their public key and a unique /32 IP from the tunnel range.
• Allowed IPs on the remote-access instance are 10.99.1.0/24 on the firewall side and 10.0.0.0/16 on the user side (the corporate network).
• Firewall rules on the WireGuard group restrict what remote users can reach (usually: only the corporate network, not the DMZ, not the management VLAN).

The remote user installs the WireGuard client on their laptop or phone. The configuration file is generated by the OPNsense WireGuard plugin and includes the client’s private key, the firewall’s public key, the endpoint, and the Allowed IPs.

The remote user’s traffic appears on the firewall as coming from tun_wg_remote (the remote-access interface). The firewall rules on that interface determine what they can do.

IPsec when required

Some partners require IPsec for site-to-site. The reference architecture supports IPsec via the strongSwan plugin, but treats it as the second option after WireGuard.

Common IPsec configurations:

• IKEv2 with AES-256-GCM and SHA-384.
• Pre-shared key for small deployments; certificates for larger.
• NAT-T for traffic behind NAT.
• Routing: policy-based (the IPsec tunnel terminates on a specific subnet pair) or route-based (the IPsec tunnel is a virtual interface that participates in the routing table).

The reference architecture uses route-based IPsec with the tunnel as a gif interface. This integrates with the existing routing and firewall rule infrastructure, rather than requiring a separate IPsec-specific firewall rule logic.

Firewall rules for VPN traffic

The WireGuard and IPsec interfaces each have their own group of firewall rules. The rules should follow the same default-deny model as the LAN interfaces:

WireGuard site-to-site group:
  Pass: WireGuard net → LAN subnet (specific services)
  Block: WireGuard net → any other VLAN
  Block: WireGuard net → DMZ
  Block: WireGuard net → firewall

WireGuard remote-access group:
  Pass: Remote users → specific corporate services
  Block: Remote users → DMZ
  Block: Remote users → management
  Block: Remote users → guest / IoT

The pattern: remote users can reach the services they need, nothing else. A compromised remote-access credential cannot reach the DMZ or the management plane.