OPNsense VPN: WireGuard vs OpenVPN vs IPsec

OPNsense ships all three mainstream VPN technologies, which means the decision is never about what the platform supports. It is about which set of tradeoffs matches the tunnel you are actually building. A phone connecting from a hotel, a permanent link to a branch office, and an interconnect with a vendor’s appliance are three different problems, and the protocol that is best at one of them is often the worst at another.

The short version

	WireGuard	OpenVPN	IPsec
Transport	UDP only	UDP or TCP	UDP 500 for IKE, IP protocol 50 for ESP, UDP 4500 once NAT traversal engages
Cipher choice	Fixed, no negotiation	Negotiated, TLS-based	Negotiated, IKE proposals
Configuration surface	Very small	Large	Large
Roaming clients	Excellent	Good	Good with MOBIKE
Per-user credentials	Keys only	Certificates, users, revocation	Certificates or pre-shared keys, EAP
Third-party interop	WireGuard peers only	OpenVPN peers only	Standards-based, broad
Benefits from AES-NI	No	Yes	Yes
Typical failure mode	Silence, no handshake	Verbose but readable logs	Phase mismatch, hard to read

WireGuard: small on purpose

WireGuard’s defining property is that it does not negotiate its cryptography. The protocol fixes a single suite: Curve25519 for key exchange, ChaCha20 with Poly1305 for authenticated encryption, BLAKE2s for hashing, and the Noise_IK handshake. There is no cipher list, no downgrade to a weaker option, and no configuration that can accidentally select something obsolete. The published design goal was an implementation small enough to be reviewed in full, in the low thousands of lines rather than the hundreds of thousands that a TLS-based stack pulls in.

That decision cascades into everything else. A peer is a public key plus a set of allowed addresses. There is no user database, no certificate authority, no revocation list. Removing access means deleting a peer entry, which is fast but also means WireGuard on its own has no concept of an account, an expiry date, or a per-user policy beyond what its allowed addresses express.

It is UDP only, and it stays quiet unless there is traffic to send, which is why a tunnel that is misconfigured produces no error at all. It simply never completes a handshake. The upside of the same behaviour is roaming: a peer’s endpoint address is learned from its most recent authenticated packet, so a client that moves from a mobile network to a wireless network keeps working without renegotiating anything.

The configuration model in OPNsense has two halves. An instance is the local end: keys, listen port, tunnel address, MTU. A peer is a remote end: its public key and the allowed addresses. The documented road warrior flow also recommends assigning the WireGuard device as a real interface, because that generates a usable alias for firewall rules and adds an IPv4 outbound NAT rule automatically.

Choose WireGuard when the endpoints are all under your control, when you want the smallest possible thing to reason about, and when clients roam between networks. It is the default answer for a phone or laptop that needs to reach a home or lab network.

OpenVPN: flexible, and the only one that hides well

OpenVPN is built on TLS, and that inheritance is its entire personality. It has a certificate authority, per-user certificates, revocation, optional username and password authentication on top of certificates, and a long list of tunable parameters. Where WireGuard has one way to do things, OpenVPN has several, which is a liability when you want simplicity and an asset when you have a requirement that does not fit a simpler model.

Two capabilities keep OpenVPN relevant even where WireGuard would otherwise win.

The first is transport flexibility. OpenVPN runs over UDP or TCP, and a TCP tunnel on port 443 is very hard to distinguish from ordinary web traffic at a network boundary. On a restrictive guest network, a captive hotel connection, or anywhere UDP is blocked outright, that is the difference between a working tunnel and no tunnel. WireGuard has no equivalent, because UDP is not optional for it.

The second is identity. If access needs to be granted and withdrawn per person, tied to a certificate with an expiry, audited, or integrated with a directory, OpenVPN models that natively. Revoking one user’s certificate is a first-class operation. OPNsense added tls-crypt v2 in the 26.4 business release, and the 26.7 community release ships it as part of OpenVPN 2.7. It gives each client its own wrapping key for the control channel, so a single leaked key does not expose the control channel of every other client.

The cost is per-packet overhead and a larger configuration surface. Recent OpenVPN releases add a kernel data-channel offload path that removes much of the historical user-space penalty, but the protocol is still doing more work per packet than WireGuard is, and AES-based ciphers are the usual choice, which is why AES-NI matters here.

Choose OpenVPN when you need per-user credentials and revocation, or when the client network is hostile enough that only TCP on a common port will get through.

IPsec: the one everyone else also speaks

IPsec is not a single design so much as a standardised family, and its value is precisely that it is standardised. If the other end of the tunnel is a firewall from a different vendor, a cloud provider’s VPN gateway, or a device someone else administers, IPsec is usually the only option all parties implement. Neither WireGuard nor OpenVPN interoperates with anything that is not itself WireGuard or OpenVPN.

Modern deployments use IKEv2, which is substantially cleaner than IKEv1, supports MOBIKE for clients that change address, and is what mobile operating systems implement natively. That native support matters: an IPsec IKEv2 profile can often be installed on a phone or laptop without a third-party application, which is not true of the other two.

IPsec also maps well onto hardware acceleration. AES-GCM proposals run through AES-NI on any modern x86 CPU, so a well-configured IPsec tunnel is frequently the fastest of the three on the same box.

The drawback is diagnostic difficulty. A tunnel that fails because phase 1 proposals do not overlap, or because phase 2 selectors are asymmetric, produces logs that require knowing the protocol to interpret. Route-based tunnels using virtual tunnel interfaces have improved this considerably by making the tunnel look like an interface that ordinary routing and firewall rules apply to, but IPsec remains the option with the steepest debugging curve.

Choose IPsec for site-to-site links with equipment you do not control, for interconnects with cloud providers, and where a client must connect using only its operating system’s built-in VPN support.

What does not change between them

Three things are constant regardless of which protocol you pick, and all three are where tunnels actually break.

Firewall rules are still evaluated per interface, on the way in. Every one of these protocols needs a rule on the WAN interface permitting the inbound connection, and a separate rule governing what the connected client is then allowed to reach. Those are two different rules on two different interfaces, and creating only the first is the most common cause of a tunnel that establishes but carries nothing. The model is covered in how OPNsense firewall rules, NAT and interfaces actually work.

Outbound NAT is still separate from filtering. A client that reaches your local network but not the internet through the tunnel is almost always missing translation for the tunnel subnet, not a filter rule.

And packet size still matters. Every one of these protocols adds encapsulation overhead, so the usable payload inside the tunnel is smaller than the one outside it. When large transfers hang while pings succeed, the cause is nearly always maximum segment size clamping rather than anything protocol-specific.

Hardware implications

The protocol choice feeds back into the box. IPsec and OpenVPN with AES ciphers get direct benefit from AES-NI. WireGuard’s fixed ChaCha20-Poly1305 construction does not use those instructions, so its throughput tracks raw single-core speed instead. Several simultaneous tunnels spread across cores; one large transfer through one tunnel generally does not. Those constraints are worked through in OPNsense hardware requirements, and the state table and bandwidth sizer on this site takes a tunnel count as an input.

A decision shortcut

Personal devices reaching a network you own, roaming between connections, minimal moving parts: WireGuard.

Users who need individual credentials that can be revoked, or clients stuck behind networks that only pass TCP on common ports: OpenVPN.

A link to equipment administered by someone else, a cloud provider gateway, or a client that must use its operating system’s built-in VPN: IPsec.

Running more than one of these at the same time is normal and supported. A WireGuard instance for your own devices and an IPsec tunnel to a partner site is a common combination, and they do not interfere with each other. If the WireGuard side is the one that will not come up, OPNsense WireGuard not connecting covers the failure causes in the order they usually occur.