IPsec Phase 1 and Phase 2 — authentication, key exchange, and lifetimes

A site-to-site IPsec tunnel on OPNsense is two related negotiations stacked together. Phase 1 establishes the IKE Security Association — the encrypted, authenticated channel between the two peers that all subsequent IKE messages travel over. Phase 2 establishes one or more ESP Security Associations — the actual tunnels that carry protected traffic between the protected subnets. The OPNsense UI splits the configuration into a Phase 1 entry and one or more Phase 2 entries under it; understanding what each negotiation carries is the foundation for diagnosing every IPsec failure mode covered later.

What Phase 1 establishes

Phase 1 is the authentication and key exchange step. By the end of a successful Phase 1 exchange, both peers know three things:

1. The remote peer is who it claims to be. Authentication is mutual — each side proves its identity to the other. Without mutual authentication, an attacker could position themselves between the two endpoints and read every packet.
2. The shared keys for the IKE channel. Both sides derive the same keying material from the Diffie-Hellman exchange. The keys encrypt the IKE messages themselves so the negotiated Phase 2 SAs cannot be read off the wire.
3. The proposals both sides agreed on. Encryption algorithm, integrity algorithm, Diffie-Hellman group, and lifetime — these came up during the negotiation and both sides have a copy.

The Phase 1 IKE SA has a lifetime (default 24 hours on OPNsense). At the end of the lifetime, the peers rekey the IKE SA — Phase 1 re-runs without dropping the protected Phase 2 SAs that sit on top of it.

What Phase 1 negotiates

The Phase 1 proposal is a list of algorithms the peer is willing to use. Both sides propose their preferred algorithms; the negotiation picks the highest-preference match. The fields:

In OPNsense the Phase 1 form under VPN → IPsec → Tunnel Configuration → Phase 1 of tunnel X exposes these directly. Modern configurations pick:

• Authentication method: certificates (RSA or ECDSA), with mutual validation against a configured CA.
• Encryption + integrity: AES-256-GCM or ChaCha20-Poly1305 (each is an AEAD mode that bundles encryption + integrity).
• DH group: 14 or higher; never accept DH group 1, 2, or 5 — those groups are deprecated by NIST.

Peer authentication in Phase 1

Three authentication methods are in production use:

Pre-Shared Key (PSK). A symmetric secret both sides agree on out of band. Cheap to set up, awkward to rotate. PSK is appropriate for a small number of tunnels where the operator can manage the secret securely. The PSK is configured under VPN → IPsec → Pre-Shared Keys and is referenced by the Phase 1 entry.

Raw public key. Each side has the other’s public key installed in its configuration. StrongSwan stores raw keys as base64-encoded subjectPublicKeyInfo blobs. Less common than certificates but useful for very small tunnels where a full PKI is overkill.

Certificates. Each side has an X.509 certificate signed by a CA the other side trusts. This is the production answer for any deployment with more than one tunnel or any expectation of certificate rotation. OPNsense integrates with its own PKI (under System → Trust → Certificates); the certificate management lesson covers the PKI side in detail.

The trade-offs:

What Phase 2 establishes

Phase 2 establishes one or more ESP Security Associations. Each ESP SA has its own:

• Traffic selector — the source and destination subnets (or host addresses) that flow through the SA. A typical site-to-site deployment has one Phase 2 entry with local subnet = 10.0.0.0/24 and remote subnet = 10.1.0.0/24. A more complex deployment may have multiple Phase 2 entries — one per protected network pair, or one per traffic class.
• Encryption algorithm — the algorithm used to encrypt the IP payload. AES-256-GCM is the modern default; AES-128-CBC is acceptable where the peer does not support GCM.
• Integrity algorithm — for non-AEAD modes (CBC), the HMAC over the ESP packet. SHA-256 is the modern default.
• Lifetime (in seconds or bytes) — when the SA is torn down and re-keyed. Phase 2 lifetimes are typically shorter than Phase 1 lifetimes (an hour vs a day) so that key rotation happens regularly.

The Phase 2 entries live under each Phase 1 in the OPNsense UI. They can be added, removed, and edited independently; each is a separate SA from strongSwan’s perspective. A Phase 1 entry with no Phase 2 entry is a running tunnel with no traffic selectors — the IKE channel is up, but no traffic is actually encapsulated.

Phase 1: ikev2, AES-256-GCM, SHA-384, DH-20, lifetime 24h
  ├── Phase 2: ESP, AES-256-GCM, SHA-256, lifetime 1h
  │   local 10.0.0.0/24, remote 10.1.0.0/24
  │
  ├── Phase 2: ESP, AES-256-GCM, SHA-256, lifetime 1h
  │   local 10.0.0.0/24, remote 10.2.0.0/24
  │
  └── Phase 2: ESP, AES-256-GCM, SHA-256, lifetime 1h
      local 10.0.0.0/24, remote 10.3.0.0/24

This single Phase 1 + multiple Phase 2 entries pattern is the normal production shape. A multi-peer hub-and-spoke deployment has one Phase 1 per spoke (each spoke has its own authentication and DH parameters), each with one or more Phase 2 entries for the protected networks.

How Phase 2 negotiates

Phase 2 is much faster than Phase 1 because the IKE SA from Phase 1 already exists:

• In IKEv1, Phase 2 is “quick mode” — 3 messages, all encrypted under the Phase 1 keys.
• In IKEv2, Phase 2 is the CREATE_CHILD_SA exchange — 2 messages, also encrypted under the Phase 1 keys.

Both phases look for a matching proposal pair the same way: each side sends its list, the responder picks the first one that matches the initiator’s list. The same algorithm-order rules apply.

Rekeying

Both Phase 1 and Phase 2 have lifetimes. When the lifetime expires:

• Phase 2 rekeying: a new ESP SA is negotiated before the old one expires. The IKE SA from Phase 1 carries the new SA; traffic flips from the old SA to the new SA without dropping the tunnel. StrongSwan performs this rekey automatically a few minutes before the configured expiry.
• Phase 1 rekeying: a new IKE SA is negotiated; the old IKE SA continues to operate until all Phase 2 SAs have been rekeyed under the new IKE SA. The transition is seamless.

The lifetimes the operator configures affect how often rekeying happens. Short lifetimes (a few hours or even minutes) increase the rotation cadence but add CPU load; long lifetimes (days) reduce the load but extend the window if a key is compromised. Production defaults — 24 hours for Phase 1, 1 hour for Phase 2 — are reasonable; high-security deployments reduce both.

Reading the Phase 1 / Phase 2 status

StrongSwan’s status output shows every SA in the active tunnel:

$ swanctl --list-sas

home-edge: #1, ESTABLISHED 24 minutes ago, 198.51.100.1[edson@example.com] ... 203.0.113.1[gateway@partner.example]
AES-256-GCM/PRF-HMAC-SHA2-384/ECP-384
IKEv2 SPIs: 8a3b1c2d9e0f1234 i 1c2d9e0f12348a3b
StrongSwan 5.9.x
local  'edson@example.com'
remote 'gateway@partner.example'
1 alive, 0 rekeying
child: #2, reqid 1, ESTABLISHED 24 minutes ago, rekeying in 35 minutes
  10.0.0.0/24 === 10.1.0.0/24
  ESP spi:0xc1d2e3f4 (0xc1d2e3f4) spi:0xa1b2c3d4 (0xa1b2c3d4)
  AES-256-GCM-16/ESN
  bytes_i (4.6 GiB) bytes_o (12.3 GiB)
  rekeying in 35 minutes
  extend_by 0

The output names every active SA, the algorithms negotiated, the traffic selectors, the lifetime remaining, and the byte counters. The line “IKEv2 SPIs: …” is the Security Parameter Index the strongSwan database uses internally; an operator looking at the same line on both peers confirms they negotiated the same IKE SA.

Configuring Phase 1 and Phase 2 on OPNsense

The practical workflow:

1. Phase 1: VPN → IPsec → Tunnel Configuration → Add Phase 1. Pick IKEv2, set Authentication to either pre-shared key or certificate, pick a strong proposal (AES-256-GCM with SHA-384 and DH group 20 is a strong default), set Lifetime to 24h.
2. Phase 2: with the tunnel selected, Add Phase 2. Pick ESP, choose the same encryption algorithm (or a compatible one), set Lifetime to 1h, set Local subnet and Remote subnet to the protected networks.
3. Apply by clicking the save button at the top of the IPsec page; OPNsense regenerates the strongSwan configuration and signals charon to reload.
4. Verify by running swanctl --list-sas from the console or the IPsec status page in the GUI.

$ swanctl --list-conns

home-edge: IKEv2
local  '198.51.100.1'
remote '203.0.113.1'
local-{}, remote-{}
version: 2
reauth_time: 86400s
rekey_time: 86400s
over_time: 1200s
proposals: AES-256-GCM/PRF-HMAC-SHA2-384/ECP_384
child: home-edge-1
  rekey_time: 3600s
  over_time: 600s
  local-ts: 10.0.0.0/24
  remote-ts: 10.1.0.0/24
  proposals: AES-256-GCM/ESN
  ESP spi:0xc1d2e3f4

Summary

• Phase 1 establishes the IKE SA — the encrypted, authenticated channel for negotiation.
• Phase 2 establishes the ESP SAs that carry protected traffic, one per traffic selector pair.
• Peer authentication uses PSK, raw keys, or certificates; PSK is simple, certificates are the production answer at scale.
• Proposals match on both sides; algorithm order matters during negotiation.
• IKE rekeying keeps long-lived tunnels stable by overlapping SAs.
• OPNsense’s GUI directly maps to the strongSwan configuration model; the operator reads swanctl --list-sas to confirm the live state.