How to Inspect IPsec State Without Publishing Its Keys

An IPsec state dump is not a status report, and treating it as one is how key material ends up in a public issue tracker. Some kernel inspection output includes the traffic keys the kernel is using, alongside addresses, selectors and counters that are genuinely useful. The safe habit is to collect the summary first and reach for the raw state only when the summary cannot answer the question. If you must look at the raw state, look locally and share something narrower.

Check 1: can this artefact leave the machine at all

A configuration file, a private key, an unrestricted packet capture and a raw state dump are all secrets until proven otherwise. A command that prints keys is not made safe by the fact that you ran it for diagnostics.

The rule is simple enough to state in a sentence: share the observation that answers the question, not the machine state that produced it.

Check 2: pick the summary command, not the state dump

For strongSwan, swanctl --list-sas shows the association summary: identities, installed children, states and counters. It does not require the raw key dump, and it is the first thing to paste into a ticket. On the kernel side, iproute2 supports ip xfrm state list nokeys on versions that document the option, which suppresses key material while keeping the association fields.

Confirm the syntax in the local manual before you rely on it, because the option is not present on every release and a generic state listing without it is a different command with different output. Running ip xfrm state on an old build to see whether the flag exists is exactly the mistake this checklist is about.

Check 3: record only what the investigation needs

Association status, algorithms, selectors, timestamps, direction and the relevant counters are usually enough. Account identities, public addresses and internal topology often are not, and they can be redacted without losing diagnostic value.

Redact by default and add back on request. The person reading your ticket can ask for one more field; they cannot un-see a pasted key.

There is a middle ground worth knowing: a summary can still be sensitive. Identities, peer addresses and child names describe your topology, and in some organisations that is itself restricted information. Decide who the audience is before you paste, and prefer a channel with the right access control over a public issue. A safe command is not the same as a safe destination.

Check 4: correlate one attempt across both ends

Capture the client and the gateway for the same connection attempt, at the same time, and make sure the association you are describing is the one that attempt produced. Mixing a stale child from an earlier attempt with a fresh route snapshot produces a report that is internally consistent and completely misleading.

Identify the association by its unique identifiers rather than by the tunnel, and note the direction of the failure. If the symptom is no traffic in one direction, say which direction and include a harmless test destination, so the reader can reason about the path instead of guessing. A counter that is zero in one direction and rising in the other localises the problem far better than any key dump. Keep the timestamps in one time zone and say which one.

Check 5: what to do if material was already exposed

Deleting the attachment does not establish that nobody retained it, and a public paste is copied quickly.

Treat that as an incident and use the operator's replacement process: rotate the affected keys or credentials, check whether the exposure implies a wider compromise, and follow whatever notification path applies. The technical cleanup is the easy part; the assumption that nobody read it is the hard part.

The durable practice is a small template you fill in before pasting: which end, which association identifier, which direction, which counter, and what was already ruled out. The swanctl list-sas documentation describes the summary fields, which is what most tickets actually need. Everything else is available on request to someone who needs it. A diagnostic report should contain evidence, not access.