At SafeLogic, we help software that already does its job well clear the last hurdle to regulated deployment: validated cryptography. This post explains how we deliver FIPS 140-3 compliance for one of the most widely deployed open-source IPsec implementations, strongSwan, by pairing it with CryptoComply Core, SafeLogic's FIPS 140-3 validated cryptographic software. The goal is a strongSwan deployment that keeps its speed, portability, and IKEv2 feature set while performing only cryptography that a NIST-validated module is approved to perform.
strongSwan is an IPsec-based VPN solution built around a user-space IKE daemon with full support for IKEv1 and IKEv2. It handles peer authentication, key exchange, and the negotiation of Security Associations, then hands packet-level ESP processing to the kernel. Running the keying engine in user space, rather than confining it to the kernel, is a big part of strongSwan's appeal: it's portable, it runs across common Linux distributions and CPU architectures, and it's straightforward to containerize.
To do its job, strongSwan draws on a familiar set of cryptographic primitives, each playing a specific role. These are visible in the project's open source and its public cipher-suite documentation:
Several of those primitives are perfectly reasonable engineering choices. ChaCha20-Poly1305, for instance, is fast, constant-time by design, and an excellent default on hardware without AES acceleration. The issue isn't that these algorithms are weak, it's that they aren't all FIPS-approved, and approval, not merely strength, is what regulated environments require.
So, is strongSwan FIPS validated out of the box? No. A default build will happily negotiate ChaCha20-Poly1305, hash with MD5, authenticate with HMAC-MD5, encrypt with DES, or generate an undersized RSA key, none of which are acceptable under FIPS 140-3. A stock build also performs its cryptography in general-purpose code that sits outside any validated cryptographic boundary. For anyone deploying into government, defense, healthcare, or finance, that combination is a hard blocker.
The fix has two parts. First, constrain strongSwan so it uses only FIPS-approved counterparts to the primitives above. Second, make sure those approved algorithms come from a validated module rather than general-purpose implementations.
At the algorithm level, these are the standard, publicly defined substitutions any FIPS effort makes:
The elegant part is that you don't have to police this by hand. When cryptography runs inside a validated module operating in FIPS mode, the non-approved primitives simply aren't available; requests for them fail closed, and negotiation settles on an approved suite. Compliance becomes a property the module enforces, not a checklist an operator has to remember.
The approved algorithms are supplied by CryptoComply Core, SafeLogic's drop-in replacement for OpenSSL. Because it is designed for API and ABI compatibility with OpenSSL, strongSwan's existing OpenSSL crypto backend can be pointed at CryptoComply Core, so that cryptographic operations flow through its FIPS 140-3 validated boundary instead of general-purpose code.
It's worth understanding that FIPS compliance in this kind of integration is a build-time property, not a runtime switch. There's no configuration flag that flips an arbitrary strongSwan install into "FIPS mode" on its own. The cryptography has to be routed through the validated module and the module's FIPS provider has to be the one doing the work, which means the software is built and linked against that module rather than reconfigured after the fact. If you're looking at how to enable FIPS 140-3 in strongSwan, the mental model to start from is a validated rebuild, not a checkbox. Delivering that build consistently while keeping it reproducible across platforms is the work SafeLogic delivers for customers.
The gap we close is narrow but effective: strongSwan's default cryptography includes primitives that regulated environments can't accept, and its stock crypto doesn't run inside a validated boundary. We close it by swapping each non-approved primitive for its FIPS-approved counterpart — ChaCha20-Poly1305 to AES-GCM, MD5 to SHA-2, HMAC-MD5 to HMAC-SHA-2, DES to AES, undersized RSA to 2048-bit-and-above — and by sourcing all of it from CryptoComply Core through strongSwan's OpenSSL backend. What doesn't change is everything that made strongSwan worth choosing in the first place: a fast, portable, user-space IKEv2 engine that now also satisfies FIPS 140-3, so your VPN can move into regulated networks without giving up the design that made it a favorite.