How to Set Up OPNsense as a VPN Server: WireGuard, OpenVPN

If you’re asking how to set up OPNsense as a VPN server, the answer is WireGuard: create an instance under VPN → WireGuard → Instances with its own tunnel subnet, add one peer per device, enable the service, pass UDP 51820 on WAN, and allow the tunnel net to the LANs it should reach. Fall back to OpenVPN or IPsec IKEv2 only when a client can’t run WireGuard.

Two prerequisites decide whether any of this works. Your WAN needs a public IPv4 address that accepts unsolicited inbound UDP; behind ISP CGNAT, a listening VPN server is dead on arrival. Clients also need a stable endpoint: without a static IP, install os-ddclient and publish a hostname under Services → Dynamic DNS (OPNsense Dynamic DNS docs).

Which VPN should OPNsense run: WireGuard, OpenVPN or IPsec?

Run WireGuard for remote access from phones and laptops you control. The OPNsense VPN overview notes that, in the OPNsense team’s experience, IPsec is the fastest option for site-to-site connections while WireGuard is the simplest to set up. The other two exist for authentication and client constraints.

WireGuard’s trade-off is identity. A peer is a key, not a user, so there is no password or second factor in front of the tunnel. If that breaks your threat model, use OpenVPN with TOTP. Either way, a VPN listener is internet-facing, so keep OPNsense updated.

Step-by-step: the WireGuard server

Values follow the OPNsense WireGuard road-warrior how-to. For deeper client-side routing detail, see our WireGuard road warrior guide; FirewallCompare also has a WireGuard on OPNsense setup walkthrough.

1. Create the instance

VPN → WireGuard → Instances → +:

• Name: HomeWireGuard
• Public/Private key: generate with the cogwheel, then copy the public key
• Listen port: 51820
• Tunnel address: 10.10.10.1/24, an RFC 1918 subnet used nowhere else
• MTU: 1420, or 1412 on PPPoE

Leave the advanced-mode DNS Server field blank. Filling it makes WireGuard overwrite OPNsense’s own DNS configuration.

Choose subnets with roaming in mind. If your home LAN is 192.168.1.0/24, so is plenty of hotel Wi-Fi, and a split-tunnel client there can’t tell your NAS from their printer. Renumbering the LAN (say, 10.44.20.0/24) fixes it permanently.

2. Add one peer per device

VPN → WireGuard → Peers → +, or use VPN → WireGuard → Peer generator, which also builds the client config and QR code. Per peer: a name (phone-01), the client’s public key, and Allowed IPs 10.10.10.2/32. Save, then open the instance and add the peer to its Peers list.

Server-side Allowed IPs is the peer’s single tunnel address. Putting your LAN subnet here is the classic mistake.

3. Enable and assign the interface

VPN → WireGuard → General → enable → Apply. Then Interfaces → Assignments, add the wg1 device, open it, tick Enable and Lock, and set IPv4 and IPv6 Configuration Type to None. The docs call assignment optional but recommended: it gives you a dedicated rules tab and automatic IPv4 outbound NAT.

4. Firewall rules, in apply order

Firewall → Rules → WAN
1. Pass  UDP      src any                dst WAN address    port 51820  "WireGuard in"

Firewall → Rules → HomeWireGuard
1. Pass  TCP/UDP  src HomeWireGuard net  dst This Firewall  port 53     "DNS to Unbound"
2. Pass  any      src HomeWireGuard net  dst LAN net                    "peers to LAN"
   (default deny covers IoT, guest, management and the web GUI)

Shadowing risk: OPNsense evaluates floating rules, then interface-group rules, then interface rules, first match wins (firewall docs). WireGuard also creates a WireGuard group, so one broad pass rule on that tab silently overrides your assigned-interface rules. Keep all tunnel rules on one tab.

LAN net is exactly one subnet. On a segmented network, add each VLAN peers should reach, or an alias. Field-by-field logic is in OPNsense firewall rules explained.

5. Outbound NAT, full tunnel only

Needed only if clients send internet traffic through home. With the interface assigned, automatic outbound NAT already handles IPv4. If you skipped assignment or use IPv6 ULAs in the tunnel, set Firewall → NAT → Outbound to hybrid mode and add: interface WAN, source HomeWireGuard net, translation Interface address. Bonus: full-tunnel clients keep your Unbound DNS blocklists on hotel Wi-Fi.

6. MSS clamping

Firewall → Settings → Normalization → +: interface WireGuard (Group), max MSS 1380 for IPv4, which is 40 bytes under the 1420 MTU (1372 on PPPoE). Add a second rule at 1360 for IPv6. Without it: handshake up, ping fine, TLS sites hanging mid-load.

7. Client config

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

[Peer]
PublicKey = <HomeWireGuard public key>
Endpoint = vpn.example.net:51820
AllowedIPs = 10.10.10.0/24, 192.168.1.0/24
PersistentKeepalive = 25

That is split tunnel. For full tunnel, set AllowedIPs = 0.0.0.0/0, ::/0. If Unbound listens on all interfaces, reload it after the WireGuard interface appears so DNS = 10.10.10.1 answers. PersistentKeepalive holds the carrier NAT mapping open on mobile.

When should you use OpenVPN instead?

Use OpenVPN when you need per-user authentication: a certificate from your own CA plus a local username and password, optionally with TOTP. Since 23.7 it lives under VPN → OpenVPN → Instances; the old Servers and Clients pages are legacy, so don’t start a new build there (OPNsense VPN docs).

The SSL VPN road-warrior how-to boils down to:

1. System → Trust → Authorities: create a CA.
2. System → Trust → Certificates: a Server cert (CN = firewall FQDN) and a Client cert per user, CN matching the username.
3. VPN → OpenVPN → Instances → Static Keys: generate a key in Auth mode.
4. Instance: Role Server, UDP, port 1194, Server (IPv4) 10.10.20.0/24, server cert, static key, Authentication Local Database, Strict User/CN Matching on, Local Network 192.168.1.0/24.
5. Pass UDP 1194 on WAN and add a pass rule on the OpenVPN tab.
6. VPN → OpenVPN → Client Export: set Hostname to your DDNS name and export per user.

The trap: rules on an assigned road-warrior interface get reply-to by default, so replies never reach the client. The OpenVPN troubleshooting page recommends disabling the auto-created gateways under System → Gateways → Configuration. Avoid the global reply-to switch if you run multi-WAN gateway groups; the docs warn it can break them.

When is IPsec IKEv2 the right choice?

Choose IKEv2 when the client has to be the VPN built into the operating system. The IKEv2 EAP-MSCHAPv2 how-to covers native clients on iOS, Android and Windows 10/11; its macOS example uses a third-party client.

Under VPN → IPsec → Connections you build a Pool (172.16.203.0/24 in the docs) that pushes your LAN IP as DNS, EAP users under Pre-Shared Keys, and an IKEv2 connection: proposal aes256-sha256-modp2048, local auth by a server certificate matching the hostname clients dial, remote auth EAP-MSCHAPv2, child selector 0.0.0.0/0. Use rekey time 86400 for Windows clients, 2400 otherwise.

On WAN, pass UDP 500 and UDP 4500. Per RFC 7296, Internet Key Exchange Protocol Version 2 (IKEv2), IKE moves to 4500 with UDP-encapsulated ESP when either end sits behind NAT, which for a phone is the normal case.

How do you verify the VPN server works?

Confirm a fresh handshake on the firewall, then test reachability, path, DNS, MTU and throughput from a client on someone else’s network, such as a phone hotspot. Your own LAN doesn’t exercise the WAN path.

# On OPNsense (SSH or console shell)
wg show                                   # recent "latest handshake", rx/tx climbing

# From a Linux client on a phone hotspot
ping -c 4 10.10.10.1                      # tunnel address
ping -c 4 192.168.1.1                     # LAN side of the firewall
mtr -rwc 20 192.168.1.20                  # LAN host, no loss through the tunnel
nslookup docs.opnsense.org 10.10.10.1     # Unbound answering over the tunnel
ping -M do -s 1392 -c 3 192.168.1.1       # 1392 + 28 = 1420, must pass unfragmented
iperf3 -c 192.168.1.20 -t 20              # client to home
iperf3 -c 192.168.1.20 -t 20 -R           # home to client
curl -s https://ifconfig.me               # full tunnel: prints your home WAN IP

No handshake means the inbound path: the WAN rule, CGNAT, or a wrong Endpoint. Watch Firewall → Log Files → Live View for UDP 51820 while the client retries. Low iperf3 numbers point at your WAN upload or the firewall CPU; see our OPNsense hardware guide.

FAQ

Does OPNsense have a built-in VPN server?

Yes. OPNsense includes WireGuard, OpenVPN and IPsec under its VPN menu at no cost, and plugins add OpenConnect, Tinc, ZeroTier and Stunnel. For remote access to a home network, WireGuard is the simplest to configure and the right default; OpenVPN and IPsec cover the client and authentication needs it doesn’t.

What port does OPNsense WireGuard use?

WireGuard on OPNsense listens on UDP 51820 by default, set in the instance’s Listen Port field. You can pick any unused higher port, but the WAN pass rule and every client’s Endpoint line must match it. OpenVPN defaults to UDP 1194, and IPsec IKEv2 needs UDP 500 and UDP 4500 open on WAN. To link two sites instead of remote devices, see the OPNsense WireGuard site-to-site tunnel guide on OPNsenseRouter.

Can I run an OPNsense VPN server behind CGNAT?

Not as a listening server. Behind CGNAT your firewall has no public address of its own, so a client’s connection attempt never reaches your WAN and no rule or port forward on OPNsense can accept it. Ask the ISP for a public IPv4 address, use IPv6 end to end, or run an outbound-initiated overlay such as ZeroTier.

Why does my OPNsense WireGuard connect but not pass traffic?

A handshake with no traffic is a routing or rules problem, not a key problem. Check that the server-side peer’s Allowed IPs holds only its /32 tunnel address, the client’s AllowedIPs includes your LAN subnet, and the tunnel interface has a pass rule to that LAN. If only large pages stall, add the MSS clamp.

Related across the network

• How to Set Up WireGuard VPN on pfSense: Step-by-Step Guide — pfsenselab.com
• OPNsense WireGuard Setup Problems: Handshake, NAT, MTU — opnsenserouter.com