WireGuard Compared to IPsec and OpenVPN: What It Does Differently

The question is whether WireGuard is actually better than IPsec and OpenVPN, or just newer. For most home labs and small offices, it is better, but the reasons are specific, and so are the exceptions.

I have been running a WireGuard tunnel between my house and my sister's for a while now, and I have spent a lot of years around IPsec. Here is how I see the comparison.

Fewer moving parts

IPsec is a framework, not a single protocol. You choose IKEv1 or IKEv2, then an encryption algorithm, a hash, a Diffie-Hellman group, a lifetime for each phase, and a mode. Two vendors can both claim IPsec support and still spend an afternoon failing to agree on proposals. I have lost more than one afternoon that way.

OpenVPN is more approachable, but it still has a long list of options: TLS settings, ciphers, certificate handling, TCP or UDP, and compression you should probably leave off.

WireGuard removes most of that. It does not negotiate ciphers. It uses a fixed set: Curve25519 for key exchange, ChaCha20-Poly1305 for encryption, and BLAKE2s for hashing. If a weakness is found in one of them, the answer is a new version of the protocol, not a settings change. That is a real tradeoff, but it also means there is no misconfigured cipher suite to find at two in the morning.

The code is small enough that one person can read it in a reasonable time. Less code means fewer places for a bug to hide. That is an argument, not a guarantee, but I trust it more than the alternative.

Cryptokey routing

The idea that makes WireGuard easy to reason about is that each peer is identified by its public key, and each public key is tied to a list of allowed IP addresses. That list does two jobs. It is the routing table for outbound traffic, and it is the filter for inbound traffic. A packet arriving from a peer with a source address outside that peer's list is dropped.

Think of it as a patch panel where every port has a label saying which addresses may come out of it. Once you see it that way, most configuration mistakes become obvious.

Quiet and roaming-friendly

WireGuard does not answer packets from peers it cannot authenticate. A port scan sees nothing on that UDP port. It also has no real notion of a session that drops. If a peer's address changes, the next authenticated packet updates the endpoint and traffic carries on. That is why a laptop moving between networks tends to behave well.

A working site-to-site example

Here is the shape of a tunnel between two houses. House A uses 192.168.10.0/24, house B uses 192.168.20.0/24, and the tunnel uses 10.99.0.0/24. Those subnets must not overlap. That is the most common reason a site-to-site VPN fails, and no protocol fixes it.

1. Generate a key pair on each side.

umask 077
wg genkey | tee privatekey | wg pubkey > publickey

2. Write the config on house A, using the public key from house B.

[Interface]
Address = 10.99.0.1/24
ListenPort = 51820
PrivateKey = <house A private key>

[Peer]
PublicKey = <house B public key>
AllowedIPs = 10.99.0.2/32, 192.168.20.0/24
Endpoint = houseb.example.net:51820
PersistentKeepalive = 25

3. Mirror it on house B, with the addresses and keys swapped and house A's LAN in AllowedIPs.

4. Open UDP 51820 on the firewall of any side that has to receive the first packet, and allow traffic on the tunnel interface itself. On OPNsense, WireGuard support is available, but check how your version presents it, because I will not pretend to remember every menu.

5. Bring it up and check it.

wg-quick up wg0
wg show

The field to watch in the output is latest handshake. If it shows a recent time, the keys and the path are good. If it shows nothing, the two sides are not talking at all.

Where it does not win

I would not be doing my job if I stopped at the good news.

• WireGuard runs over UDP only. On a network that blocks UDP, OpenVPN over TCP port 443 will get through where WireGuard will not.
• There is no built-in user authentication, no address assignment, and no directory integration. Peers are static entries in a file. With three or four peers that is pleasant. With fifty, you need tooling, and I have not evaluated the options enough to recommend one.
• IPsec is a standard that nearly every commercial firewall and router speaks. If you need to connect to a vendor's gear or a partner's firewall, IPsec is usually the only option. Environments with compliance requirements around approved algorithms may also rule WireGuard out, since its fixed algorithm set does not match those lists. Check your own requirements before you commit.
• Key distribution is your problem. Nothing revokes a key for you. You remove the peer line and reload.
• A peer's last known endpoint is kept in memory on the server, which matters if you care about what a VPN host can see.

Speed

WireGuard is widely reported to be faster than the alternatives, in part because it runs in the Linux kernel and has a lean design. I am not going to quote a number, because the number depends on your CPU, your link, and your MTU. Measure your own path with iperf3 before and after, and write the result in the binder.

When it does not come up

If the handshake never appears, work from the bottom up. Check the cable and the WAN link first. Then confirm the port forward or firewall rule. Then look at the wire.

tcpdump -ni any udp port 51820

If you see packets leaving but nothing returning, the problem is upstream of you. If you see packets arriving but no handshake, suspect a wrong public key. If the tunnel is up but large transfers stall while pings work, suspect MTU. The wg-quick default is 1420, and a path with extra overhead may need less.

My summary is that WireGuard is better when you control both ends and want something small and boring that keeps working. It is not better when you need interoperability, TCP fallback, or per-user management. Pick the tool for the job.

Set up one tunnel between two machines you control, break it on purpose by changing an AllowedIPs entry, and read what wg show and the capture tell you. Report back.