Configuration is intent. The SA is the result.
A VPN tunnel is a negotiated agreement. What each side is willing to accept lives in its configuration. What the two sides agreed lives in the established security association. These are different objects, and only one of them is evidence.
The gap between them is not theoretical. The most common outcome of an unverified post-quantum migration is a tunnel that:
- has the new proposal configured on the local side,
- negotiated the old classical-only option because the peer did not offer the new one,
- established successfully,
- passes every health check,
- and is recorded in the change system as migrated.
Nothing in a normal monitoring stack distinguishes that tunnel from a correctly migrated one. Both are up. Both pass traffic. The difference is only visible in the negotiated SA.
What to capture
For each migrated tunnel, capture from both peers where both are reachable:
| Evidence item | Why |
|---|---|
| Negotiated key exchange method on the IKE SA | The primary finding. This is the claim being evidenced |
| Negotiated encryption and integrity algorithms | Confirms nothing else changed unintentionally |
| Authentication method in use | Confirms the unchanged property is genuinely unchanged |
| IKE version | Guards against a tunnel having silently fallen back |
| SA establishment timestamp | Ties the evidence to the change window |
| Device identity and running software version | The evidence is only meaningful against a known device state |
| Child SA state and selectors | Confirms the data plane came up as expected |
Where the peer belongs to another organisation and cannot be inspected, record that explicitly. "Peer-side evidence unavailable; counterparty confirmed by email on this date" is an honest evidence record. Silence is not.
Verify after failover, not only after the change
A high-availability pair has two members and they can differ — different software releases, different configuration state, different history. A tunnel verified on the active member tells you about the active member.
Force a failover during the change window, verify again on the newly active member, and fail back. If the change process does not permit a failover test, record that as a limitation of the evidence rather than assuming symmetry.
Verify after a rekey
RFC 9370 defines a separate exchange, IKE_FOLLOWUP_KE, used when the IKE SA is rekeyed or when additional Child SAs are created. Establishment and rekey are different code paths, and a tunnel can succeed at the first and fail at the second.
The practical technique: set a deliberately short rekey interval on the canary tunnel so at least one rekey occurs inside the observation window, verify the SA again afterwards, then restore the production interval. Discovering a rekey failure on a canary costs an hour. Discovering it across a completed wave costs a weekend.
Verify the things around the tunnel
A tunnel that negotiated correctly and broke the network around it is not a successful migration. Confirm:
- Routing. Where the tunnel carries dynamic routes, confirm the sessions re-established and the expected prefixes are present. A BGP session that came back with a different path selection is a change, not a non-event.
- Failover. Confirm the redundant path still takes over. Renegotiation can change timers in ways that affect convergence.
- Traffic. Confirm the applications the tunnel exists for are actually working, from the far side. A tunnel that is up and carrying nothing is a common and easily missed outcome.
- Untouched tunnels on the same device. Where the change involved a software upgrade rather than a configuration edit, every other tunnel on that device was also changed. Verify a sample of them.
Building an evidence record that survives
Store, per wave: the pre-change SA state, the configuration diff as reviewed and approved, the post-change SA state from both peers, the routing and failover confirmations, the timestamps, and the named engineer who performed each verification.
Two properties make this record useful a year later rather than merely present:
- Raw output, not a summary. A screenshot of a tick-box in a change ticket evidences that someone ticked a box. The device's own output evidences what the device said.
- Both peers, or an explicit note of why not. A one-sided view cannot prove what two parties agreed.
Common mistakes
- Verifying by reading configuration. The most common error, and the one this entire guide exists to prevent.
- Verifying only the active HA member. Half the pair is unverified.
- Verifying only at establishment. Rekey is a separate code path.
- Accepting a green health check as evidence. Health checks confirm the tunnel is up, which is exactly what a silently downgraded tunnel also is.
- Summarising away the raw output. The summary is the claim; the output is the evidence.
Limitations
What a device reports about a negotiated SA, and how you retrieve it, differs by platform. This guide describes what to look for and why; the per-platform commands and API calls belong in the runbook for that platform. It also assumes both peers are IKEv2 and that the migration used a negotiated mechanism — verification of an RFC 8784 preshared key deployment is a different exercise, centred on key provenance and rotation records rather than on the negotiated proposal.