IKEv2 and IPsec Explained: RFC 7296, ESP and Algorithm Choices

IPsec is the IETF's framework for protecting IP packets at the network layer, and IKEv2 is the protocol that sets it up. IPsec itself encrypts and authenticates packets using the Encapsulating Security Payload (ESP, RFC 4303), while IKEv2 (RFC 7296, October 2014) authenticates the two peers, agrees on algorithms and derives the keys that ESP uses. Together they carry most site to site VPN traffic and many remote access VPNs.

The pieces were standardised in layers, which is why IPsec has a reputation for being hard to configure. Algorithm guidance lives in separate documents (RFC 8221 and RFC 8247, 2017) so it can change faster than the protocol, and post-quantum key exchange arrived through RFC 9370 in May 2023. This post walks through each layer on the wire, the algorithms the IETF keeps and drops, the weakness classes as concepts, and the commands a defender uses to check what their own gateways negotiate. Protocol facts come from the RFCs, IANA, NIST SP 800-77 Revision 1 and the official strongSwan, Libreswan, Linux and Microsoft documentation.

Key takeaways

• IPsec has three parts: an architecture with policy and state databases (RFC 4301), the packet formats ESP (RFC 4303, IP protocol 50) and AH (RFC 4302, IP protocol 51), and a key management protocol, IKEv2 (RFC 7296). RFC 4301 makes ESP mandatory and AH optional.
• IKEv2 sets up an encrypted control channel (the IKE SA) in two round trips, IKE_SA_INIT and IKE_AUTH, and creates the first data channel (a Child SA) at the same time. CREATE_CHILD_SA adds or rekeys SAs; INFORMATIONAL carries deletes, errors and liveness checks.
• IKE uses UDP port 500, and UDP port 4500 once NAT is detected or MOBIKE is used. ESP then travels either directly as protocol 50 or inside UDP 4500 (RFC 3948). RFC 9329 adds TCP port 4500 as a fallback where UDP is blocked.
• IKEv1 is deprecated. RFC 9395 (April 2023) moved RFCs 2407, 2408 and 2409 to Historic and says IKEv1-only systems should be upgraded or replaced.
• For ESP, RFC 8221 makes AES-GCM with a 16 octet ICV and AES-CBC mandatory to implement, recommends ChaCha20-Poly1305, and says encryption without authentication must not be used. For IKEv2, RFC 8247 makes 2048-bit MODP (group 14), AES-CBC, PRF_HMAC_SHA2_256 and HMAC-SHA2-256-128 mandatory, and bans DES, MD5 and the 768-bit group.
• RFC 9370 lets IKEv2 run up to seven additional key exchanges after the classical one, so a hybrid X25519 plus ML-KEM setup becomes possible. IANA has assigned ML-KEM-512, 768 and 1024 the key exchange IDs 35, 36 and 37 from a draft that is in the RFC Editor queue.
• Most real failures are configuration, not cryptography: weak pre-shared keys, IKEv1 left on, loose traffic selectors and old proposals kept "for compatibility".

What IPsec and IKEv2 are for: the layer and the standards

IPsec protects IP traffic between two hosts, two gateways, or a host and a gateway, without changing the applications that generate it. Working at the network layer, it can protect any protocol over IP and whole subnets at once. RFC 4301 describes IPsec as creating "a boundary between unprotected and protected interfaces", with every packet that crosses the boundary either protected, discarded or allowed to bypass protection according to policy.

NIST SP 800-77 Revision 1, "Guide to IPsec VPNs" (June 2020, superseding the 2005 original), notes that IPsec configuration "is usually performed using the Internet Key Exchange (IKE) protocol". IPsec is the packet protection; IKE is the negotiation and key management that feeds it.

Where it sits:

• ESP and AH are network layer protocols. They sit directly on IP with their own protocol numbers: RFC 4303 says the preceding IPv4 Protocol or IPv6 Next Header field "SHALL contain the value 50", and RFC 4302 uses 51 for AH. IPv4 vs IPv6: headers, addressing and security covers those headers.
• IKEv2 is an application layer protocol that runs over UDP, normally port 500 and port 4500. It is usually implemented as a user space daemon that programs the operating system kernel's IPsec engine.

The defining standards, with the dates on rfc-editor.org:

The newest update, RFC 9827 (November 2025), only renames Transform Type 5 from "Extended Sequence Numbers" to "Sequence Numbers". For the bigger picture of one packet travelling through a tunnel, see how does a VPN work: one packet through an IPsec or WireGuard tunnel.

How the pieces fit: RFC 4301, ESP and AH

Security associations and the three databases

The central object in IPsec is the security association (SA): a one way agreement between two peers about how to protect a stream of packets, with its keys, algorithms, sequence counters and lifetime. Because an SA is one way, a bidirectional conversation needs a pair. Each SA is identified on the wire by a 32-bit Security Parameters Index (SPI) chosen by the receiver.

RFC 4301 describes three logical databases that every implementation has in some form:

On Linux, the kernel's SPD and SAD are the XFRM framework, shown by the ip xfrm commands later. The PAD lives in the IKE daemon's configuration: identities, certificates and allowed subnets.

ESP: the protocol that does the work

ESP provides confidentiality, data origin authentication, connectionless integrity and an anti-replay service. RFC 4303 lists three service combinations: confidentiality only ("MAY be supported"), integrity only ("MUST be supported") and confidentiality with integrity ("MUST be supported"). In practice every modern deployment uses confidentiality with integrity, usually through a combined mode (AEAD) cipher such as AES-GCM.

AH: integrity for the outer header, rarely needed

AH authenticates the packet including parts of the outer IP header, but never encrypts. RFC 4301 says implementations "MUST support ESP and MAY support AH", explaining that "there are very few contexts in which ESP cannot provide the requisite security services". AH also breaks across NAT, because a NAT device rewrites the very header fields AH protects. RFC 8221 says integrity-only ESP, using ENCR_NULL, is "preferred over AH due to NAT traversal".

Tunnel mode vs transport mode

Every SA has a mode:

RFC 4301 describes transport mode as "typically employed between a pair of hosts". strongSwan's mode option defaults to tunnel, and RFC 4303 notes that traffic flow confidentiality padding is generally effective only in tunnel mode, where the true endpoints are hidden.

How IKEv2 works on the wire

IKEv2 is a request and response protocol. Every exchange is exactly one request and one response, and the initiator retransmits if no response arrives. RFC 7296 states that "all communications using IKE consist of request/response pairs".

Ports and IANA registrations

RFC 7296 section 3.1 says "IKE messages use UDP ports 500 and/or 4500, with one IKE message per UDP datagram." On port 4500, IKE messages are prefixed with four zero octets so a receiver can tell them apart from ESP packets sharing the same port.

The IKE header

Every IKE message starts with a fixed 28 octet header:

After the header comes a chain of payloads, each naming the type of the next. Once keys exist, everything after the header is carried inside a single Encrypted payload (written SK in the RFC), which must be the last payload and must not contain another Encrypted payload.

IKE_SA_INIT and IKE_AUTH: four messages to a working tunnel

The initial exchanges set up the IKE SA and the first Child SA. In the RFC's notation, payloads in square brackets are optional:

Initiator                                   Responder
---------                                   ---------
IKE_SA_INIT request
  HDR, SAi1, KEi, Ni            -------->
                                            IKE_SA_INIT response
                                <--------     HDR, SAr1, KEr, Nr, [CERTREQ]

   (both sides now compute SKEYSEED and derive SK_d, SK_ai/ar, SK_ei/er)

IKE_AUTH request (encrypted)
  HDR, SK { IDi, [CERT,] [CERTREQ,]
            [IDr,] AUTH, SAi2, TSi, TSr }  -->
                                            IKE_AUTH response (encrypted)
                                <--------     HDR, SK { IDr, [CERT,] AUTH,
                                                        SAr2, TSi, TSr }

   (IKE SA established; first Child SA pair installed in the kernel)

What happens in each message:

1. IKE_SA_INIT request. The initiator offers algorithm proposals (SAi1), a Diffie-Hellman public value (KEi) and a nonce (Ni).
2. IKE_SA_INIT response. The responder picks one proposal (SAr1) and sends its own key exchange value (KEr), nonce (Nr) and optionally certificate requests.
3. Key derivation. Both sides compute SKEYSEED and derive separate encryption and integrity keys for each direction, plus SK_d, which seeds Child SA keys.
4. IKE_AUTH request. Now encrypted. The initiator sends its identity (IDi), optional certificates and an AUTH payload, a signature or MAC that binds the identity to the first message. It also proposes the first Child SA (SAi2) and traffic selectors (TSi, TSr): the addresses and ports the SA will carry.
5. IKE_AUTH response. The responder authenticates the same way and returns the Child SA and traffic selectors it accepts, possibly narrowed.

Identities are encrypted against passive observers, but RFC 7296 notes that an active attacker "can nonetheless see the identity of the initiator", which reveals itself first. If the responder prefers another Diffie-Hellman group it replies with INVALID_KE_PAYLOAD; if it is under load it replies with a COOKIE, and the initiator must repeat its first message with the cookie, proving it can receive packets at its address before the responder commits any state (RFC 7296 section 2.6).

CREATE_CHILD_SA: more tunnels and rekeying

Initiator (either peer)                     Responder
HDR, SK { SA, Ni, [KEi], [TSi, TSr] }  -->
                                <--         HDR, SK { SA, Nr, [KEr], [TSi, TSr] }

CREATE_CHILD_SA is one request and response. RFC 7296 says it "is used to create new Child SAs and to rekey both IKE SAs and Child SAs", and that either end may start it once the initial exchanges are done. An SA is rekeyed by creating a new one and then deleting the old one.

The optional KE payload is where forward secrecy for Child SAs comes from. Without it, new Child SA keys are derived only from SK_d and fresh nonces. RFC 7296's Security Considerations warn that "repeated rekeying using CREATE_CHILD_SA without additional Diffie-Hellman exchanges leaves all SAs vulnerable to cryptanalysis of a single key". Configure a key exchange method in your ESP proposals so each rekey runs a fresh exchange.

The strongSwan documentation adds that the first Child SA's keys are always derived from the IKE SA's key material, so a key exchange in the ESP proposal applies to rekeys and later Child SAs. strongSwan rekeys Child SAs hourly and the IKE SA every four hours by default, minus random jitter.

INFORMATIONAL: deletes, errors and liveness

INFORMATIONAL exchanges carry Notify, Delete and Configuration payloads, and "MUST ONLY occur after the initial exchanges", protected by the IKE SA's keys. An empty INFORMATIONAL request is the standard liveness check, often called dead peer detection: the recipient "MUST send some response", so silence after retransmissions means the peer is gone. strongSwan's dpd_delay option sets how often to probe when no traffic has been received.

The ESP packet

Once the Child SA exists, data flows in ESP packets:

The SPI and sequence number travel in clear but are integrity protected, so observers see which SA a packet belongs to but cannot alter it undetected.

Anti-replay. The receiver keeps a sliding window of recently seen sequence numbers and drops duplicates and packets that are too old. RFC 4303 requires a minimum window of 32 packets with 32-bit sequence numbers and says 64 "SHOULD be employed as the default". strongSwan's replay_window defaults to 32, and a value of 0 disables replay protection. Anti-replay only works when integrity is on.

Extended sequence numbers. strongSwan's documentation notes that 32-bit counters can run out "in a few minutes on a 10 Gb/s link". ESN keeps a 64-bit counter, sends only the low 32 bits and includes the high bits in the integrity check, so both peers must negotiate it (Transform Type 5).

NAT traversal (RFC 3948) and MOBIKE

Raw ESP has no ports, so most NAT devices cannot map it. IKEv2 detects NAT in IKE_SA_INIT with NAT_DETECTION notifications carrying hashes of the addresses and ports each side believes it uses; on a mismatch both sides move to UDP 4500. RFC 3948 puts ESP directly after the UDP header there, while IKE packets on the same port start with a four octet zero "Non-ESP Marker". One octet 0xFF keepalives hold the NAT mapping open.

MOBIKE (RFC 4555, June 2006) lets a client change address, say from Wi-Fi to cellular, without renegotiating. strongSwan enables it by default and notes that IKEv2 then "always floats to UDP port 4500 starting from the second exchange", so firewalls must allow both 500 and 4500.

TCP encapsulation (RFC 9329)

Where UDP is blocked, RFC 9329 carries IKE and ESP over TCP. The stream opens with the six ASCII characters "IKETCP", then each message is prefixed with a 16-bit length. Implementations "MUST support TCP encapsulation on TCP port 4500", configured on both ends in advance, but "SHOULD prefer ESP direct or UDP-encapsulated SAs" because TCP inside TCP costs performance.

Versions and history

RFC 9395 gives the reasons IKEv1 had to go: development "ceased over a decade ago", some IKEv1 systems "will never be patched", IKEv1 can be "abused for packet amplification attacks" (citing CVE-2016-5361), and its negotiations tend to land on "dated or deprecated algorithms". IKEv2 also brings fewer messages, built-in NAT traversal, EAP and an anti-DoS cookie.

IKEv2 is the default in current open source implementations: strongSwan's version defaults to 2, and Libreswan's manual says IKEv1 "has been disabled per default". IKEv1 survives mostly on older appliances and legacy L2TP over IPsec setups.

Which algorithms to use and drop: RFC 8221, RFC 8247 and RFC 9395

IKEv2 negotiates algorithms as transforms. A proposal lists one or more transforms of each type: encryption (type 1), pseudorandom function (type 2, IKE only), integrity (type 3), key exchange method (type 4), and sequence numbers (type 5, ESP and AH only). RFC 9370 added types 6 to 12, "Additional Key Exchange 1" through 7. The responder picks one of each.

The levels below are implementation requirements, but they guide configuration too: nothing marked MUST NOT or SHOULD NOT belongs in a production proposal. "MUST-" marks algorithms expected to be demoted; "SHOULD+" marks ones expected to be promoted.

ESP algorithms (RFC 8221)

Three rules in RFC 8221 matter more than any single row:

• "Encryption without authentication is not effective and MUST NOT be used." Use an AEAD cipher, or a non-AEAD cipher with an integrity algorithm. RFC 8221 lists ESP plus AH as a third option but marks it NOT RECOMMENDED: slowest, largest overhead, and some combinations "have been shown to be insecure".
• AUTH_NONE only with AEAD. With AES-GCM or ChaCha20-Poly1305 the integrity transform is "none" because the cipher authenticates. With anything else, AUTH_NONE is forbidden.
• Manual keying "SHOULD NOT be used, as it is inherently dangerous." Without IKE there is no forward secrecy, no rekeying and no guarantee that counters and nonces are used once. If manual keys are used anyway, counter based modes such as GCM, CCM, CTR and ChaCha20-Poly1305 "MUST NOT be used".

IKEv2 algorithms (RFC 8247)

RFC 8247 explains that RSA Digital Signature is kept "for interoperability" but "is expected to be downgraded in the future as its signatures are based on the older RSASSA-PKCS1-v1.5". Method 14, the generic Digital Signature from RFC 7427, is the forward path because it can carry RSA-PSS and modern curves. The same RFC says RSA keys shorter than 2048 bits "SHOULD NOT be used".

RFC 7296 itself adds two absolute rules: a PRF with output shorter than 128 bits "MUST NOT be used", and implementations "MUST NOT negotiate NONE as the IKE integrity protection algorithm or ENCR_NULL as the IKE encryption algorithm".

What RFC 9395 changed

RFC 8221 and RFC 8247 left unmentioned old algorithms in an implicit "MAY". RFC 9395 deprecates those and adds a Status column to the IANA Transform Type registries. It also says implementations "SHOULD NOT directly import IKEv1 configurations without updating the cryptographic algorithms used".

A sensible default proposal today

Read together, the RFCs point to a short list for new deployments:

• IKE SA: AES-GCM-16 with 256-bit keys (or ChaCha20-Poly1305), PRF_HMAC_SHA2_256 or SHA2_384, and an elliptic curve key exchange such as Curve25519 (IANA 31) or the 256 or 384-bit random ECP groups (19, 20), with group 14 as the classical MODP fallback only where needed.
• Child SAs: AES-GCM-16 with integrity set to none, plus a key exchange method so rekeys have forward secrecy, and ESN on high speed links.
• Authentication: certificates with ECDSA or RFC 7427 Digital Signature, rather than pre-shared keys.

Post-quantum: RFC 9370, ML-KEM and PPKs

A recorded session protected only by classical Diffie-Hellman could be decrypted later by a large enough quantum computer. RFC 9370 keeps a classical exchange in IKE_SA_INIT, then runs "one or more IKE_INTERMEDIATE exchanges", each with an additional key exchange, before IKE_AUTH. The final secret is post-quantum secure if any component is, and peers without the extension fall back to plain RFC 7296.

IKE_SA_INIT        classical KE (for example Curve25519) + ADDKE proposals
IKE_INTERMEDIATE   additional key exchange 1 (for example ML-KEM-768)
[IKE_INTERMEDIATE  additional key exchanges 2 to 7, if negotiated]
IKE_AUTH           authentication, binding all earlier exchanges

Post-quantum keys are large, and because IKE_INTERMEDIATE is encrypted, IKEv2 fragmentation (RFC 7383) can carry them. Child SA rekeys use a new exchange, IKE_FOLLOWUP_KE.

Which post-quantum algorithm? The IANA "Transform Type 4" registry, last updated 20 October 2026, lists ml-kem-512, ml-kem-768 and ml-kem-1024 as values 35, 36 and 37, referencing draft-ietf-ipsecme-ikev2-mlkem. On 23 October 2026 the IETF datatracker shows that draft at revision 09 in the RFC Editor queue, so the code points are assigned but the document is not yet a published RFC. strongSwan already supports mlkem512, mlkem768 and mlkem1024 and documents the hybrid syntax x25519-ke1_mlkem768.

An older symmetric route is RFC 8784 (June 2020), which mixes a post-quantum preshared key (PPK) into IKEv2 key derivation. RFC 9395 recommends it for systems that relied on IKEv1 PSKs for quantum resistance. strongSwan exposes it as ppk_id.

Where CNSA 2.0 fits

For US national security systems, the NSA's Commercial National Security Algorithm Suite sets the floor. The summary below follows strongSwan's official proposal documentation; confirm details against the NSA's own publication. strongSwan lists CNSA 2.0 as AES-256 (for example aes256gcm16), ML-KEM-1024 for key exchange, which in IKEv2 still needs an initial classical exchange such as ECDH on P-384, SHA-384 or SHA-512 for the PRF and integrity, and ML-DSA-87 for signatures. It describes CNSA 1.0 as AES-256, ECDH P-384 or DH of at least 3072 bits, SHA-384, and ECDSA P-384 or RSA of at least 3072 bits.

Security properties and weakness classes

What IPsec with IKEv2 guarantees

IKEv1 aggressive mode and weak pre-shared keys

IKEv1 Aggressive Mode saved round trips by sending identities and a PSK-derived hash before encryption was up. strongSwan's documentation says Aggressive Mode "is considered less secure because the ID and HASH payloads are exchanged unprotected", which "allows a passive attacker to snoop peer identities and even worse, start dictionary attacks on the Preshared Key". Libreswan's manual adds that it "should especially not be used with XAUTH and group secrets (PSK)". The design flaw is that an offline guessing check becomes possible from captured traffic alone.

IKEv2 has no Aggressive Mode, but weak PSKs still hurt. RFC 7296 says a PSK should "contain as much randomness as the strongest key being negotiated" and that deriving one from "a password, name, or other low-entropy source is not secure". A memorable PSK shared across many sites is a common, avoidable weakness.

Weak groups and downgrade

The key exchange group sets the ceiling on the strength of every key that follows. RFC 7296's own Security Considerations describe group 1 as "for historic purposes only". RFC 8247 bans group 1 outright and marks groups 2 and 5 SHOULD NOT. If a gateway offers a weak group alongside strong ones, the protection depends on which side's preference wins and on whether an attacker can influence the choice. IKEv2 authenticates the whole IKE_SA_INIT exchange in IKE_AUTH, which defeats silent tampering with the offer, but it cannot protect you from a weak option that both peers are configured to accept. The defence is to not offer what you would not want chosen.

The same logic applies to Child SAs without a key exchange. RFC 7296 warns that many rekeys without fresh Diffie-Hellman leave all those SAs dependent on one key, and asks implementers to "set a limit on CREATE_CHILD_SA exchanges between exponentiations".

Misconfigured traffic selectors and the PAD

Authentication proves who a peer is. It does not by itself say which addresses that peer may speak for. RFC 7296 section 5.1 is explicit: the PAD must link each authenticated identity to the addresses it may use in traffic selectors, because otherwise an authenticated peer could create Child SAs for addresses that belong to someone else. RFC 4301 puts it as preventing "an authenticated peer from spoofing IDs associated with other, legitimate peers".

In configuration terms, this weakness appears as wildcard or overly wide remote traffic selectors on a responder that serves many peers, as a shared certificate authority or PSK that lets any branch authenticate as any other branch, or as "any to any" policies added during troubleshooting and never removed. The RFC also notes that when a gateway hands out a virtual IP through Configuration payloads, it should create a matching temporary authorization so the client can only use the address it was given.

Unauthenticated ESP and ESP-NULL

ESP with encryption and no integrity is legal in RFC 4303 (confidentiality only "MAY be supported") but RFC 8221 says it "MUST NOT be used". Without integrity, the receiver cannot detect modified ciphertext and cannot run anti-replay, since RFC 4303 only allows anti-replay when integrity is selected. The opposite case, ESP with ENCR_NULL, gives integrity without confidentiality. It is legitimate where traffic must be inspectable by intermediate devices, but it is a frequent surprise in audits: the tunnel is "up" and authenticated, yet everything inside is plaintext. Libreswan's manual says null encryption "should only be used for testing or benchmarking purposes".

Unauthenticated denial of service and fragmentation

RFC 7296 says IKE_SA_INIT and IKE_AUTH "happen before the initiator has been authenticated", so unauthenticated peers can reach the implementation's parsing and state handling, and EAP adds an unlimited number of messages before authentication completes. Large IKE messages that need IP fragmentation can be stalled by exhausting reassembly buffers, which is one reason RFC 7383's IKE level fragmentation exists. RFC 9395 notes that IKEv1 also lacked the anti-amplification protections IKEv2 has.

EAP and reused authentication

RFC 7296 warns that EAP methods that do not generate a shared key can be relayed from another place the same method is used, so they "SHOULD be avoided where possible", and the gateway must authenticate to the client with a public key before EAP begins. It also advises separate trust anchors for IKE peers rather than those used for public web servers.

Leaks by design and implementation bugs

RFC 7296 lists unavoidable disclosures: anyone can learn that a host speaks IKE and which algorithms it supports, and NAT detection hashes can be brute forced to recover an internal address, so designers "should therefore not assume that use of IKE will not leak internal address information". Beyond the design, most real IPsec vulnerabilities sit in code that parses optional payloads before the peer is authenticated. Keep the IKE daemon, its crypto library and any embedded IPsec stack current, and treat an end of life IKEv1-only appliance as RFC 9395 does: a candidate for replacement.

Secure configuration, with defender-side check commands

Only run these commands against systems you own or are authorised to test. They read local configuration and state; none of them probe other people's gateways.

A checklist that maps to the RFCs

• Run IKEv2 only. Set the IKE version explicitly and refuse IKEv1 packets.
• Prune proposals. Remove everything that is MUST NOT or SHOULD NOT in RFC 8221 and RFC 8247: DES, 3DES, MD5, SHA-1 where both sides support SHA-2, groups 1, 2, 5, 22, 23 and 24, and ENCR_NULL unless integrity-only ESP is an explicit requirement.
• Prefer AEAD. AES-GCM-16 or ChaCha20-Poly1305 for both IKE and ESP.
• Add a key exchange to ESP proposals so Child SA rekeys have forward secrecy.
• Use certificates. If you must use PSKs, generate them randomly with at least as many bits as your strongest key, and use one per peer pair.
• Pin identities to traffic selectors. Each remote identity should only be allowed the subnets it owns.
• Plan post-quantum. Test RFC 9370 hybrids such as X25519 plus ML-KEM-768 with your peers, or RFC 8784 PPKs where both ends support them.
• Expose only what is needed. UDP 500 and 4500, plus ESP (protocol 50) if NAT traversal is not always used; TCP 4500 only if you deliberately enable RFC 9329.
• Keep replay protection on. Do not set the replay window to zero.

strongSwan (swanctl)

strongSwan's current configuration interface is swanctl with swanctl.conf. A minimal site to site connection using only options from the official swanctl.conf reference:

connections {
    site-b {
        version = 2
        remote_addrs = 203.0.113.10
        proposals = aes256gcm16-prfsha384-x25519-ke1_mlkem768
        dpd_delay = 30s
        local {
            auth = pubkey
            certs = gw-a.pem
            id = gw-a.example.com
        }
        remote {
            auth = pubkey
            id = gw-b.example.com
        }
        children {
            net-b {
                local_ts = 10.1.0.0/16
                remote_ts = 10.2.0.0/16
                esp_proposals = aes256gcm16-x25519-ke1_mlkem768
                mode = tunnel
                start_action = trap
            }
        }
    }
}

Notes from the documentation:

• version = 2 is already the default; writing it makes intent visible. A value of 0 would accept IKEv1 as a responder.
• Without proposals, strongSwan's IKEv2 default keeps 3DES, SHA-1 and PRF SHA-1 "for interoperability with legacy systems". An explicit list removes them.
• The ke1_ prefix configures an RFC 9370 additional key exchange. This example requires the peer to support ML-KEM-768; a peer that does not will fail to negotiate rather than silently drop to classical only. Add a second proposal without ke1_ only if you accept that fallback.
• The key exchange method in esp_proposals applies to rekeys and later Child SAs, not to the first Child SA created with the IKE SA.

Check what is loaded and what is negotiated:

# Loaded connection definitions, including proposals and traffic selectors
swanctl --list-conns

# Active IKE SAs and Child SAs, with the algorithms actually selected
swanctl --list-sas

# Installed IPsec policies
swanctl --list-pols

# Algorithms available from loaded plugins and their implementations
swanctl --list-algs

# Daemon information and statistics
swanctl --stats

In an audit, read the list-sas output: it shows the negotiated algorithms for each IKE SA and Child SA, the traffic selectors and rekey timers. A MODP 1024 group or 3DES there means a proposal list is too wide.

Libreswan

Libreswan configures connections in ipsec.conf. Relevant options from the official ipsec.conf(5) manual:

• keyexchange=ikev2 is the default; keyexchange=ikev1 enables the deprecated protocol.
• ikev1-policy=drop (the default) silently drops IKEv1 packets; with drop or reject, loading an IKEv1 connection fails.
• ike= and esp= set proposals, for example ike=aes_gcm256;sha2_256 or esp=aes_gcm. The manual recommends against the 8 and 12 octet ICV variants of GCM and CCM because RFC 8247 only mandates the 16 octet version, and notes that 1DES and modp768 have been removed and modp1024 disabled at compile time.
• aggressive=no is the default and has no effect with IKEv2.

Status commands from the official ipsec(8) manual:

ipsec status             # connections and their current state
ipsec trafficstatus      # established tunnels and traffic counters
ipsec briefstatus        # condensed status
ipsec checkconfig        # validate the configuration
ipsec fipsstatus         # FIPS mode status
ipsec version            # installed Libreswan version

Linux kernel state (iproute2)

Both strongSwan and Libreswan program the kernel's XFRM framework on Linux. The ip-xfrm(8) manual documents read-only commands to see what the kernel actually holds:

# Security associations, without printing key material
sudo ip xfrm state list nokeys

# Security policies (the kernel's SPD)
sudo ip xfrm policy list

# Quick counts
sudo ip xfrm state count
sudo ip xfrm policy count

The nokeys option matters: without it, ip xfrm state prints the session keys. Do not paste unredacted output into tickets or chat.

Windows VPN client

Microsoft Learn documents Get-VpnConnection in the VpnClient module. It lists configured VPN profiles with their TunnelType (for example Ikev2), AuthenticationMethod (for example MachineCertificate) and EncryptionLevel:

Get-VpnConnection
Get-VpnConnection -AllUserConnection

To pin an IKEv2 profile to specific algorithms instead of the built-in defaults, Microsoft documents Set-VpnConnectionIPsecConfiguration. Its accepted values include ECP256, ECP384 and Group14 for -DHGroup, GCMAES256 and AES256 for -CipherTransformConstants and -EncryptionMethod, and SHA256 and SHA384 for -IntegrityCheckMethod. Older values such as Group1, Group2, DES, DES3 and MD5 are still accepted by the cmdlet, so check that none of them are in use. The documented example for an IKEv2 profile:

Set-VpnConnectionIPsecConfiguration -ConnectionName "Contoso" `
  -AuthenticationTransformConstants None -CipherTransformConstants AES256 `
  -EncryptionMethod AES256 -IntegrityCheckMethod SHA384 `
  -PfsGroup None -DHGroup ECP384 -PassThru -Force

That example sets -PfsGroup None. If your gateway supports it, choose a PFS group such as ECP384 instead so Child SA rekeys get a fresh key exchange.

Logging

Log every IKE SA establishment, rekey and failure with the peer identity and the negotiated algorithms, and alert on authentication failures and on negotiations that select algorithms outside your policy. RFC 4303 lists anti-replay failures, integrity check failures and sequence number overflow as auditable events; make sure your implementation's counters for them are collected.

Where IPsec code lives in your software

When people say "our VPN", they usually mean a gateway appliance or a pair of servers. In a modern estate, IPsec and IKE code also sits in container base images that ship strongswan or libreswan packages for cloud interconnects, in container networking components that program the kernel's IPsec engine, in IoT and edge firmware, and in crypto libraries that the IKE daemon links against. Each has its own release history and its own fixes for parsing bugs in pre-authentication code.

This is where Safeguard fits, within what it actually does. Its software composition analysis, generally available, builds a full transitive dependency inventory of repositories and container images, so an IKE daemon or crypto library inside a networking image shows up with its version. SBOM generation and analysis in SPDX and CycloneDX, also generally available, give you a record you can query when the next IPsec advisory lands. Vulnerability management with EPSS and CISA KEV enrichment and reachability analysis, both generally available, help decide which findings to fix first. Container scanning, part of the generally available ESSCM platform, covers the OS packages baked into images. Safeguard does not inspect, filter or terminate IPsec traffic, is not a VPN and does not audit your gateway's proposal lists; the commands above remain your job.

When to use IPsec vs WireGuard vs OpenVPN vs TLS VPNs

For a deeper comparison of the operational trade-offs, see IPsec vs OpenVPN, IPsec vs SSL VPN and WireGuard vs OpenVPN. For how the field got here, see the history of VPN, from tunnels to WireGuard. NIST SP 800-77 Revision 1 also describes alternatives to IPsec and when each may be appropriate.

Common mistakes

• Leaving IKEv1 enabled "just in case". RFC 9395 deprecated it. If one old peer needs it, isolate that connection and plan its replacement rather than accepting IKEv1 globally.
• Using a short, memorable or shared PSK. RFC 7296 says low entropy secrets are "not secure". Use certificates, or long random PSKs that are unique per peer pair.
• Importing an IKEv1 configuration into IKEv2 unchanged. RFC 9395 specifically warns against this; the old proposals usually carry SHA-1 and group 2.
• Relying on default proposals without reading them. Some defaults keep 3DES and SHA-1 for compatibility. Write an explicit list and check list-sas output for what is actually negotiated.
• No key exchange in ESP proposals. Child SA rekeys then derive keys from SK_d only, with no fresh forward secrecy.
• Wide or wildcard traffic selectors. Authentication does not limit which subnets a peer may claim. Restrict each identity to its own networks.
• Encryption without integrity. Never configure a non-AEAD cipher with AUTH_NONE. With GCM or ChaCha20-Poly1305, "none" for integrity is correct.
• Disabling replay protection to fix packet reordering. Raise the window instead of setting it to zero.
• Patching the gateway but not the images. IKE daemons and crypto libraries also ship inside container images and appliances that nobody configures by hand.

FAQ

What port does IKEv2 use?

IKEv2 uses UDP port 500, and UDP port 4500 once NAT is detected or when MOBIKE is in use. RFC 9329 also defines TCP port 4500 as a fallback where UDP is blocked. ESP data travels as IP protocol 50 directly, or inside UDP 4500 when NAT traversal is active.

Is IPsec encrypted?

ESP is encrypted when configured with an encryption algorithm, which is the normal case. AH never encrypts, and ESP with ENCR_NULL only provides integrity. RFC 8221 requires that encryption always be paired with authentication, either through an AEAD cipher like AES-GCM or a separate integrity algorithm.

What is the difference between IKEv1 and IKEv2?

IKEv2 (RFC 4306 in 2005, now RFC 7296) replaced IKEv1's three documents with one protocol, fewer messages, built-in NAT traversal, EAP authentication and an anti-DoS cookie. The two are not compatible. RFC 9395 deprecated IKEv1 in April 2023 and says IKEv1-only systems should be upgraded or replaced.

What is the difference between ESP and AH?

ESP (IP protocol 50) can encrypt and authenticate the payload. AH (IP protocol 51) only authenticates, but covers parts of the outer IP header. RFC 4301 makes ESP mandatory and AH optional, and RFC 8221 prefers integrity-only ESP over AH because AH does not survive NAT.

What is the difference between tunnel mode and transport mode?

Transport mode protects the payload of the original packet and keeps its IP header, which suits host to host use. Tunnel mode wraps the whole original packet in a new IP header between the two IPsec endpoints, hiding inner addresses, which suits gateway to gateway and remote access VPNs.

Which encryption should I use for IPsec?

For ESP, AES-GCM with a 16 octet ICV, which RFC 8221 makes mandatory to implement, or ChaCha20-Poly1305. For IKEv2, AES-GCM or ChaCha20-Poly1305 with a SHA-2 PRF and an elliptic curve or 2048-bit or larger key exchange. Remove DES, 3DES, MD5 and Diffie-Hellman groups 1, 2 and 5.

Is IPsec quantum safe?

Not by default. RFC 9370 (May 2023) lets IKEv2 add post-quantum key exchanges such as ML-KEM after the classical one, and RFC 8784 offers post-quantum preshared keys.

What are traffic selectors in IKEv2?

Traffic selectors (TSi and TSr) list the address ranges, protocols and ports a Child SA will carry. They are proposed in IKE_AUTH and CREATE_CHILD_SA and can be narrowed by the responder. The responder must also check, through its Peer Authorization Database, that the authenticated peer is allowed to use those addresses.

What is NAT traversal in IPsec?

NAT traversal (RFC 3948) wraps ESP in UDP port 4500 so NAT devices can map it. IKEv2 detects NAT automatically with hashed address notifications in IKE_SA_INIT and switches ports. Small 0xFF keepalive packets keep the NAT mapping open.

IPsec vs WireGuard: which is better?

Neither is better in general. IPsec interoperates with almost every operating system, router and cloud gateway. WireGuard has a small fixed set of modern primitives and fewer options to get wrong, but both ends must run it.

Fix it without waiting for upstream

IPsec weaknesses that reach production usually live in an implementation rather than in RFC 7296: an IKE daemon in a container image, a crypto library it links, or an embedded IPsec stack in a networking component. Those are dependencies you can find, upgrade and gate like any other.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

These demos show dependency, image and SBOM workflows. They do not monitor IPsec tunnels or check gateway proposals. You can download Safeguard and follow the CLI docs to try them on your own projects.

This demo sets up the Safeguard runner on your own machine, approves it with its device code and then scans from the terminal. Pointed at a networking or interconnect container image, the same scan lists the IKE daemon and crypto library packages inside it with their versions and any known vulnerabilities.

Click through it at your own pace, or open it full screen.

This demo is a real CLI session: install, open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, move lodash to 4.17.21, run npm install and npm test with approval, and print a summary without pushing anything. The same approve each step flow applies when the component to bump is a crypto or networking library pinned in your manifest or base image.

Click through it at your own pace, or open it full screen.

This demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude can use. Once connected, you can ask in plain language which of your projects or images include a particular IKE daemon or crypto library version after an advisory, and get the answer from your own scan data.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• RFC 4301: Security Architecture for the Internet Protocol
• RFC 4302: IP Authentication Header
• RFC 4303: IP Encapsulating Security Payload (ESP)
• RFC 7296: Internet Key Exchange Protocol Version 2 (IKEv2)
• RFC 8221: Cryptographic Algorithm Implementation Requirements and Usage Guidance for ESP and AH
• RFC 8247: Algorithm Implementation Requirements and Usage Guidance for IKEv2
• RFC 9370: Multiple Key Exchanges in IKEv2
• RFC 9395: Deprecation of the IKEv1 Protocol and Obsoleted Algorithms
• RFC 3948: UDP Encapsulation of IPsec ESP Packets
• RFC 9329: TCP Encapsulation of IKE and IPsec Packets
• RFC 7427: Signature Authentication in IKEv2
• RFC 8784: Mixing Preshared Keys in IKEv2 for Post-quantum Security
• RFC 9827: Renaming the Extended Sequence Numbers Transform Type in IKEv2
• RFC Editor metadata for RFC 7383, 9242, 4555, 6023, 5996, 4306 and 2409
• IETF datatracker: draft-ietf-ipsecme-ikev2-mlkem
• IANA: Internet Key Exchange Version 2 (IKEv2) Parameters
• IANA: Service Name and Transport Protocol Port Number Registry
• NIST SP 800-77 Rev. 1: Guide to IPsec VPNs (June 2020)
• strongSwan documentation: swanctl
• strongSwan documentation: swanctl.conf
• strongSwan documentation: IKE and ESP proposals
• Libreswan manual: ipsec.conf(5)
• Libreswan manual: ipsec(8)
• Linux manual: ip-xfrm(8)
• Microsoft Learn: Get-VpnConnection
• Microsoft Learn: Set-VpnConnectionIPsecConfiguration
• WireGuard: Protocol and Cryptography

Last reviewed: 23 October 2026. Algorithm requirements and the ML-KEM draft are moving; check the RFC Editor and IANA registries for the latest status.