> ## Documentation Index > Fetch the complete documentation index at: https://docs.futurex.com/llms.txt > Use this file to discover all available pages before exploring further. # strongSwan > Conceptual overview of strongSwan and its integration benefits with CryptoHub via PKCS #11. strongSwan is an open-source IPsec implementation for Linux that builds IKEv2 and IKEv1 VPN tunnels between gateways, servers, and mobile clients. Its charon daemon handles IKE negotiation and peer authentication, and the swanctl command-line tool loads connection definitions, certificates, and credentials at runtime. strongSwan authenticates IKEv2 peers with certificates, which means each gateway needs a private key it can sign with during the IKE\_AUTH exchange. Through the Futurex PKCS #11 (FXPKCS11) module, charon reaches that key inside the CryptoHub instead of reading it from a file on disk. strongSwan sends the authentication payload to the appliance for signing and receives the signature back, so the private key never exists on the VPN gateway. The same CryptoHub-resident key can also act as a certificate authority, letting `ipsec pki` issue peer certificates without an on-disk CA key. ## Key features This integration has the following features: * **HSM-backed IKEv2 authentication**: charon signs the IKE\_AUTH payload with a CryptoHub-resident private key, so gateway authentication does not depend on a key file the host can leak. * **CryptoHub-resident certificate authority**: Generate a CA key in the appliance and issue both the gateway and peer certificates with `ipsec pki --issue --cakeyid`, keeping the CA private key in hardware. * **Standard PKCS #11 token access**: charon's `pkcs11` plugin loads the key as a token object by module name and object handle, with no strongSwan patches and no vendor plugin. * **Runtime credential loading**: `swanctl --load-creds` attaches the token credential to a running daemon, so key rotation does not require rebuilding the configuration. * **Full IPsec tunnel protection**: Established CHILD\_SAs carry ESP-protected traffic with AES and SHA-2, authenticated by the hardware-held key. * **Site-to-site and remote-access topologies**: The same HSM-backed responder configuration serves gateway-to-gateway tunnels and roaming initiators. ## Benefits of CryptoHub integration through PKCS #11 Integrating with CryptoHub provides the following benefits: * **Enhanced security**: The IKE authentication key and the CA key are generated inside the CryptoHub as token objects, so neither can be copied off the appliance or read from a compromised VPN gateway. * **Efficient cryptographic operations**: Futurex HSMs perform the signing operations efficiently, so IKE negotiation and rekeying add minimal latency to tunnel establishment. * **Compliance readiness**: Holding VPN authentication and CA keys in a CryptoHub helps you meet requirements, such as FIPS 140-2, that mandate hardware protection for private keys. * **Operational resilience**: CryptoHub high-availability and failover features keep signing available so tunnels can rekey during a system failure. * **Streamlined key management**: CryptoHub provides a centralized repository for VPN and CA keys, which simplifies rotation, access review, and auditing across many gateways. * **Standards-based integration**: The PKCS #11 interface connects strongSwan to CryptoHub with no custom development. ## Architecture This guide builds a tunnel between two Linux hosts that play deliberately different roles. The **responder** is the HSM-backed gateway. It holds the CryptoHub client endpoint, and both its charon daemon and its `ipsec pki` tool load `libfxpkcs11.so` from `/usr/local/lib/fxpkcs11`. The module opens a mutual TLS session to the CryptoHub Host API on TCP port 2001 and carries every signing request. Two RSA 3072-bit keys live on the appliance as token objects: | Purpose | Label | ID | | ------------------------------------------------------------------- | -------------- | ---- | | Certificate authority key, which issues both peer certificates | `strongSwanCA` | `01` | | Responder IKE authentication key, which signs the IKE\_AUTH payload | `StrongSwan` | `02` | The **initiator** authenticates with an ordinary key file on disk. Both peer certificates chain to the same CryptoHub-resident CA, so the tunnel establishes normally, but only one side exercises the hardware path. The initiator is deliberately not HSM-backed. Keeping one side file-based isolates the CryptoHub path, so an authentication failure points at the HSM-backed responder rather than at either peer. Once the tunnel is established, you can deploy a second endpoint and repeat the responder procedure on the initiator to make both sides hardware-backed. ## Out of scope This guide documents a single IKEv2 tunnel between two gateways, authenticated by a CryptoHub-resident key. The following topics are not covered: * **SELinux policy.** The AppArmor step in this guide is specific to Ubuntu and other AppArmor distributions. On an SELinux distribution you must grant charon equivalent access to the Futurex library, configuration, and log paths yourself; no SELinux policy is provided or validated here. * **RHEL-family package names.** The package list is validated on Ubuntu 24.04 only. The strongSwan packaging split described in [Before you start](/Integrations/CryptoHub/VPN/strongSwan/Before_you_start) differs on RHEL-family distributions. * High-availability or failover gateway pairs. * Remote-access address pools, split tunneling, and EAP or XAuth user authentication. * Certificate revocation through CRL or OCSP. * Key and certificate rotation. * Running charon under anything other than the `strongswan-starter` service unit. * IKEv1. For those topics, refer to the strongSwan documentation after you complete this integration.