VPN, IPsec & IKE
Most important commands to remember
swanctl --list-conns— inspect connection definitions loaded in the daemon.swanctl --list-sas— inspect negotiated security associations.
Commands and flags
| Command or option | Meaning |
|---|---|
sudo |
Use administrator privileges to access the local strongSwan control interface. |
--list-conns |
List loaded configuration, not necessarily active tunnels. |
--list-sas |
List active IKE and child security associations, including traffic counters. |
No tunnel is initiated, terminated, or rekeyed by these commands.
The concepts that matter
1. A VPN carries private traffic through another network
A VPN provides a logical connection across an underlying network. In an IPsec tunnel, an inner packet is carried inside an outer protected packet. The outer addresses reach the VPN peers; the inner addresses describe the application endpoints.
These are separate routing questions. The public path must reach the peer, while private routes must direct intended application traffic into the tunnel. A tunnel does not eliminate the need for either path.
2. IKE negotiates and authenticates
IKE, the Internet Key Exchange protocol, authenticates peers and negotiates cryptographic material and parameters. Modern deployments commonly use IKEv2. The resulting IKE security association protects the control conversation.
Successful peer authentication does not mean every private address is reachable. Identity, traffic selectors, routing, and firewall policy can still disagree. The peer identity also need not be the same textual value as its current network address.
3. IPsec protects selected data traffic
A child security association provides the parameters for protected data traffic, commonly using ESP. IPsec SAs are directional; tools often present inbound and outbound associations together as one child.
Traffic selectors describe which inner traffic belongs to the negotiated protection. Rekeying replaces keys before their lifetime ends. When NAT is present, ESP may be encapsulated in UDP so it can cross translating devices. Additional encapsulation consumes packet space.
4. Established control state is not application success
An established IKE association can exist without an installed usable child, and an installed child can exist without matching data traffic. Check inbound and outbound counters alongside routes and intended selectors.
Increasing bytes in one direction only can suggest a return-path or peer-side problem, but does not identify its cause by itself. Tunnel encryption protects the VPN segment, not necessarily every segment before and after it. Application authentication and authorization remain necessary.
One small example
Optional: inspect an existing strongSwan lab gateway. This example assumes its daemon and VICI control socket are already available.
sudo swanctl --list-conns
sudo swanctl --list-sasCompare loaded definitions with active associations. No active SAs can simply mean no tunnel has been negotiated. A control-socket connection error means swanctl could not query the daemon; it is not an IKE rejection from the remote peer.
In active output, distinguish IKE ESTABLISHED from child INSTALLED, then read local/remote traffic selectors, algorithms, and directional packet/byte counts. Lifetimes or rekey values express time, not throughput. Identifiers and counters vary with negotiation and traffic.
Do not infer successful private application access merely from these states. The commands do not change the deployment, and no cleanup is needed.
Keep this idea: IKE establishes trust and keys; IPsec protects selected traffic; routes and return paths make the tunnel useful.