Enable Futurex traffic logging first
Symptom: A CryptoHub operation is refused and no local log explains why. Cause: Endpoint bundles ship with Futurex traffic logging disabled, so the module records that a request failed but not what the appliance said about it. Solution: Enable both settings in/etc/fxpkcs11.cfg:
fxpkcs11.cfg
LOG-FILE:
Shell
AOERRO line rather than stopping at the first failure token. The line names the exact missing permission, for example:
load-token reports success=no
Symptom:swanctl --load-creds --raw returns load-token reply {success=no errmsg=loading private key from token failed}.
Cause: charon reached the Futurex module but could not use the key. One of four things is wrong.
Solution: Work through these in order:
- AppArmor. Check
sudo dmesg | grep -i 'apparmor.*DENIED'. This is the most common cause, and it produces no other symptom. Confirm/etc/apparmor.d/local/usr.lib.ipsec.charonis not empty — an empty file parses and reloads cleanly while still denying charon. See Configure AppArmor for charon. - Wrong handle. Confirm the object ID matches the responder key:
pkcs11-tool --list-objects --type privkey --id 02 -v. - Wrong PIN. Confirm the
pinvalue inswanctl.confmatchesCRYPTO-OPR-PASSinfxpkcs11.cfg. - Module name mismatch. The
modulevalue inswanctl.confmust match the module name instrongswan.conf, which isfuturexin this guide.
CKR_TEMPLATE_INCONSISTENT during key generation
Symptom:pkcs11-tool --keypairgen fails with CKR_TEMPLATE_INCONSISTENT. The message names no permission and no attribute.
Cause: The endpoint role is missing CertManage:Add. On CryptoHub 7.0.3.x, asymmetric key creation is authorized under the CertManage permission family, not under Keys. Keys:Add authorizes symmetric key creation only, so a role with Keys:Add and no CertManage:Add looks correct but cannot create an RSA key pair.
Solution: Grant CertManage:Add to the endpoint role in Identity and Access > Roles, then retry. The error is generated client-side, so it does not reflect what the appliance reported; enable traffic logging as described above to see the appliance’s own INSUFFICIENT PERMISSIONS response.
pkcs11-tool —list-objects returns no output
Symptom:pkcs11-tool --list-objects prints nothing at all. No error, no empty-list message, exit status zero. It looks as though the key was never created.
Cause: The role is missing CertManage:Export, CertManage:Export Private Key, or both. The key exists on the appliance; the client cannot enumerate it.
Solution: Grant both permissions to the endpoint role, then retry. No private key material is exported by either permission — the module needs them to list token objects.
unknown command ‘pki’
Symptom:ipsec pki reports /usr/sbin/ipsec: unknown command 'pki', even though ipsec --help lists pki among its subcommands.
Cause: The strongswan-pki package is not installed. The help text is generated from a static list rather than from the installed subcommands, so it advertises a command that is not present.
Solution: Install it:
Shell
charon cannot load the Futurex module at all
Symptom: charon starts normally but noloaded PKCS#11 or futurex line ever appears in the log, and swanctl --load-creds cannot find the token.
Cause: The libstrongswan-pkcs11.so plugin is absent. It ships only in the libstrongswan-extra-plugins package, not in the base strongswan package.
Solution: Confirm the plugin is missing, then install the package:
Shell
/var/log/charon-debug.log: No such file or directory
Symptom: Agrep command in this guide fails because /var/log/charon-debug.log does not exist.
Cause: charon does not write that file by default. The charon.filelog stanza was never added, so there is no log to read. This reads as a failure of the integration when it is only an absent log file.
Solution: Add the logging stanza described in Configure strongSwan to load the Futurex PKCS #11 module, then restart strongSwan and reproduce the step you were verifying.
configTest or PKCS11Manager reports permission denied
Symptom: RunningconfigTest or PKCS11Manager returns Permission denied.
Cause: The test utilities are not executable after the endpoint zip is extracted.
Solution: Add the execute bit:
Shell
swanctl reports connection refused
Symptom:swanctl returns a connection refused error for /var/run/charon.vici.
Cause: charon has not finished starting, so the VICI socket does not exist yet.
Solution: Inspect the service state:
Shell
Shell
CHILD_SA config not found
Symptom: Initiating reports that the CHILD_SAnet was not found.
Cause: The connection did not load, or the child name does not match.
Solution: Reload and compare the names:
Shell
--initiate --child.
HSM key ID not found
Symptom:ipsec pki cannot locate the HSM key.
Cause: Either the object does not exist, the role cannot enumerate it, or the command is missing --type priv.
Solution: Confirm the object exists:
Shell
CertManage:Export and CertManage:Export Private Key.
Then confirm pki can read the public key through the module:
Shell
pki --self fails, confirm you passed --type priv.
Authentication fails during IKE_AUTH
Symptom: The IKE_SA reaches IKE_AUTH and then fails authentication. Cause: The identities do not agree between the two peers or between anid and its certificate.
Solution: Confirm the identities agree. Each host’s local id must equal the other host’s remote id, and each id must match the subject DN of the corresponding certificate. Print the certificates with ipsec pki --print --in <file> and compare.
Old certificates and keys loading
Symptom: The logs reference certificates or keys you no longer use. Cause: strongSwan loads every file in/etc/swanctl/x509, /etc/swanctl/x509ca, and /etc/swanctl/private.
Solution: Leftover test files do not necessarily block the tunnel, but they make the logs hard to read. Remove unused files, then reload with --clear so charon drops what it already holds:
Shell

