Initiate and validate the tunnel - Futurex Documentation

Bring up the tunnel and confirm that the IKE authentication was performed by the key inside the CryptoHub.

Initiate the CHILD_SA from the initiator

Shell

sudo swanctl --initiate --child net --debug 2

The output ends with CHILD_SA net{1} established with SPIs ... and reports initiate completed successfully.

Confirm the security associations on both hosts

Run this on the initiator and then on the responder:

Shell

sudo swanctl --list-sas

Each host reports ESTABLISHED, IKEv2 with a child SA marked INSTALLED, TUNNEL. The responder’s local identity is CN=StrongSwan, the identity bound to the CryptoHub-resident key:

responder: #1, ESTABLISHED, IKEv2, ..._i ..._r*
  local  'CN=StrongSwan' @ RESPONDER_IP[4500]
  remote 'CN=Peer' @ INITIATOR_IP[4500]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
  net: #2, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128
    local  RESPONDER_IP/32
    remote INITIATOR_IP/32

The two hosts must mirror each other: the initiator’s local is the responder’s remote, and the SPI values match with the inbound and outbound roles swapped.

Confirm the CryptoHub performed the authentication

On the responder:

Shell

sudo grep -Ei 'found key on PKCS#11|loaded RSA private key|authentication of' /var/log/charon-debug.log | tail -10

The log shows charon loading the key from the token, then authenticating both identities:

found key on PKCS#11 token 'futurex':0
loaded RSA private key from token
authentication of 'CN=Peer' with RSA_EMSA_PKCS1_SHA2_256 successful
authentication of 'CN=StrongSwan' (myself) with RSA_EMSA_PKCS1_SHA2_256 successful

The second line is the proof: charon authenticated itself with a signature it could only have obtained from the CryptoHub, because no private key for CN=StrongSwan exists on the host.

Validate protected traffic

From the initiator, send traffic into the tunnel:

Shell

ping -c 5 RESPONDER_IP

All packets are answered with no loss.

Then confirm the counters advanced on both hosts:

Shell

sudo swanctl --list-sas

The child SA reports non-zero, matching byte and packet counts in each direction, and the counters are mirrored between the two hosts:

in  <spi-in>,    420 bytes,     5 packets,    2s ago
out <spi-out>,   420 bytes,     5 packets,    2s ago

Matching counters in both directions confirm the ESP tunnel is carrying the traffic rather than the packets taking an unprotected path. If any check on this page fails, see Troubleshooting.

​Initiate the CHILD_SA from the initiator

​Confirm the security associations on both hosts

​Confirm the CryptoHub performed the authentication

​Validate protected traffic

Initiate the CHILD_SA from the initiator

Confirm the security associations on both hosts

Confirm the CryptoHub performed the authentication

Validate protected traffic