> ## 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.

# Initiate and validate the tunnel

> Bring up the IKEv2 CHILD_SA from the initiator, confirm the security associations on both hosts, and prove protected traffic flows through the tunnel.

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 expandable lines wrap title="Shell" theme={null}
sudo swanctl --initiate --child net --debug 2
```

<Check>
  The output ends with `CHILD_SA net{1} established with SPIs ...` and reports `initiate completed successfully`.
</Check>

## Confirm the security associations on both hosts

Run this on the initiator and then on the responder:

```shell expandable lines wrap title="Shell" theme={null}
sudo swanctl --list-sas
```

<Check>
  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
  ```
</Check>

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 expandable lines wrap title="Shell" theme={null}
sudo grep -Ei 'found key on PKCS#11|loaded RSA private key|authentication of' /var/log/charon-debug.log | tail -10
```

<Check>
  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
  ```
</Check>

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 expandable lines wrap title="Shell" theme={null}
ping -c 5 RESPONDER_IP
```

<Check>
  All packets are answered with no loss.
</Check>

Then confirm the counters advanced on both hosts:

```shell expandable lines wrap title="Shell" theme={null}
sudo swanctl --list-sas
```

<Check>
  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
  ```
</Check>

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](/Integrations/CryptoHub/VPN/strongSwan/Troubleshooting).