I spent several years building and maintaining a StrongSwan-based VPN solution on embedded cellular gateways. It worked. Customers used it. But it was a constant source of complexity — in the codebase, in debugging, in customer support calls, and in the sheer amount of configuration needed to get a tunnel up and running.
When WireGuard came along, I was skeptical in the way you get skeptical after years of dealing with VPN implementations. “Simple and fast” is what every VPN claims to be. But after working with WireGuard on embedded devices, I am convinced it is genuinely different, and it is particularly well-suited for the constraints embedded systems deal with.
The IPsec Reality on Embedded#
To understand why WireGuard matters for embedded, it helps to understand what IPsec actually looks like when you deploy it on a small device.
StrongSwan is a solid IPsec implementation. It is well-maintained, standards-compliant, and supports a huge range of configurations. That last part is both its strength and its problem on embedded devices.
An IPsec VPN involves IKE negotiation (with its own state machine and multiple exchanges), Security Associations, SPIs, rekeying, dead peer detection, NAT traversal, and a dizzying number of cipher suite combinations. The configuration for even a basic site-to-site tunnel involves specifying connection parameters, authentication methods, traffic selectors, lifetime values, and DPD settings. On the embedded gateway I worked on, we had a C++ application that interfaced with StrongSwan through the Davici API, translating user-friendly web UI settings into the correct StrongSwan configuration. That translation layer alone was a meaningful piece of code to maintain.
Debugging was painful. When a tunnel would not come up — which happened regularly due to mismatched configurations between endpoints — you were looking at IKE logs full of proposal negotiations, SA state transitions, and retransmissions. Figuring out whether the problem was an authentication issue, a proposal mismatch, or a NAT traversal failure required experience and patience.
Then there were the edge cases. Rekeying under packet loss. DPD timers interacting poorly with cellular networks that have variable latency. NAT devices in the path that handle ESP packets differently. Each of these generated support cases and required careful handling in code.
None of this means StrongSwan is bad. It implements a complex protocol correctly. The problem is that the protocol itself carries a lot of weight, and on an embedded device with limited resources and a need for reliability, that weight matters.
What Makes WireGuard Different#
WireGuard takes a fundamentally different approach, and almost every design decision turns out to be the right one for embedded.
~4,000 Lines of Kernel Code#
The entire WireGuard implementation is roughly 4,000 lines of code in the Linux kernel. For context, the IPsec stack in the kernel — not counting userspace tools like StrongSwan — is an order of magnitude larger.
On an embedded device, this matters for several reasons. A smaller codebase means fewer bugs, a smaller attack surface, and easier auditing. When you are shipping firmware to devices that might be deployed for years in hard-to-reach locations, the probability of security vulnerabilities in your VPN stack is directly related to the amount of code in that stack.
It also means the kernel module is small enough to actually read and understand. I have read the WireGuard source. I have not read the IPsec kernel implementation. One of those is feasible for an embedded developer who wants to understand what their device is doing. The other is not.
Configuration That Fits on a Napkin#
A WireGuard configuration for a site-to-site tunnel is a few lines:
[Interface]
PrivateKey = <key>
Address = 10.0.0.2/24
[Peer]
PublicKey = <key>
Endpoint = 203.0.113.1:51820
AllowedIPs = 10.0.0.0/24
PersistentKeepalive = 25That is the whole thing. There is no proposal negotiation because WireGuard uses a fixed cryptographic construction (Noise protocol framework with Curve25519, ChaCha20, Poly1305, BLAKE2s). There is no cipher suite selection because there are no options to select. There are no lifetime values to tune because WireGuard handles rekeying internally on a fixed schedule.
For embedded devices, this simplicity translates directly into reliability. There is no configuration mismatch to debug because there is barely any configuration to mismatch. The most common IPsec support issue — “why won’t my tunnel come up” caused by proposal or authentication disagreements — essentially does not exist with WireGuard.
Performance on Constrained Hardware#
WireGuard runs in kernel space and uses modern cryptographic primitives that are fast on the kinds of ARM processors found in embedded devices. ChaCha20 in particular was designed to perform well on processors without hardware AES acceleration, which is common on lower-cost embedded hardware.
In practice, the throughput and latency differences between WireGuard and IPsec on embedded hardware are noticeable. The handshake is a single round trip (1-RTT), compared to IKEv2 which requires multiple exchanges. On a cellular connection with 50-100ms latency, the difference between a 1-RTT handshake and a multi-round IKE negotiation is significant, especially when roaming or reconnecting after a network change.
Roaming Just Works#
This is the feature that matters most on cellular-connected embedded devices. WireGuard is designed to handle endpoint changes gracefully. If a device moves between cell towers, gets a new IP address, or switches between network interfaces, WireGuard handles it transparently. The tunnel stays up because WireGuard associates peers with their cryptographic identity, not their network address.
With IPsec, a source IP change typically means renegotiating the SA. Depending on DPD timers and configuration, this can take seconds to minutes. On a cellular gateway that might change IP addresses regularly, this creates gaps in connectivity that can be a real problem for applications relying on the tunnel.
WireGuard just updates the endpoint when it sees a valid packet from a known peer at a new address. No renegotiation, no delay, no dropped traffic beyond what the network change itself causes.
What You Give Up#
WireGuard is not a drop-in replacement for IPsec in every scenario. There are trade-offs.
No standards compliance. IPsec is an IETF standard. WireGuard is not. If your customers or deployment requires compliance with specific standards or interoperability with third-party IPsec devices, WireGuard is not an option.
No certificate-based authentication. WireGuard uses static public keys. There is no PKI, no certificate chains, no revocation. For large deployments, managing and distributing keys requires building your own infrastructure around it.
Limited configurability. The lack of options is usually a feature, but sometimes you genuinely need to control cipher selection, lifetime parameters, or traffic selectors. WireGuard does not give you those knobs.
Fewer enterprise integrations. IPsec works with RADIUS, EAP, and various enterprise authentication backends. WireGuard has none of that built in.
For embedded IoT and gateway devices connecting back to your own infrastructure, these trade-offs are usually acceptable. You control both ends, you do not need standards compliance for interop, and you can manage keys through your device provisioning system. But for products that need to connect to arbitrary customer VPN concentrators, IPsec is still probably necessary.
The Embedded Sweet Spot#
Where WireGuard really shines is the pattern that is increasingly common in IoT and telematics: a fleet of devices in the field that need a secure tunnel back to a central server or cloud endpoint.
In this scenario, you control both sides. You can bake the WireGuard configuration into the firmware. Key distribution happens during device provisioning. The central endpoint runs a WireGuard server that accepts connections from the fleet. Every device has a persistent, low-overhead, encrypted tunnel that survives network changes and reconnects instantly.
Compare this to deploying IPsec across a fleet: configuring StrongSwan on every device, managing certificates or PSKs, tuning DPD timers for cellular networks, handling the inevitable support cases from tunnel establishment failures. The operational difference is significant.
Looking Forward#
WireGuard has been in the Linux kernel mainline since 5.6. It is no longer experimental or niche. For new embedded Linux projects that need VPN connectivity, I think WireGuard should be the default choice unless you have a specific reason to need IPsec.
Having worked with both extensively, the difference in operational complexity alone is worth the switch. Add in the performance improvements, the roaming behavior, and the reduced attack surface, and it is hard to make a case for IPsec in scenarios where WireGuard is applicable.
The best VPN for an embedded device is the one that works reliably, requires minimal configuration, and stays out of your way. After years of fighting with IPsec to achieve those goals, WireGuard just does it.