Tell IKEv2 fragmentation from a certificate chain problem

The tunnel worked on the office network and stalls at home, and the log shows the first exchange completing before anything else happens. That pattern points at the authentication exchange, not at credentials: a certificate chain makes that message much larger than the one before it, and a path that dislikes large datagrams will drop it quietly. Two different fragmentation mechanisms are involved, and knowing which one you are looking at decides the fix.

Two fragmentation mechanisms, one symptom

IKEv2 has its own fragmentation extension, defined in RFC 7383, which splits protected IKE messages into smaller IKE messages. The peers negotiate that capability, and a message is reassembled by the IKE implementation rather than by the IP layer.

Ordinary IP fragmentation is a different mechanism with a different failure mode. A router between the peers fragments a large datagram, or drops it and returns an ICMP message that may never reach the sender. Some networks silently discard fragments, and some middleboxes handle the first fragment but not the rest. From the application's point of view all three cases look identical.

NAT traversal adds a third variable, because ESP is then wrapped in UDP and the outer packet gets larger while looking like ordinary UDP traffic on port 4500. A path that passes UDP fine can still fail on a datagram that no longer fits.

Read the exchange that failed

Look for the transition rather than the error. A log that shows the initial exchange sent and answered, followed by nothing, is telling you the next message never completed. Raise the log level temporarily and compare the reported sizes on both peers.

What you want to establish is whether the responder saw the request at all. If the initiator sent something and the responder has no record of it, delivery is the problem. If the responder parsed a request and rejected it, the certificate itself is the problem, and fragmentation is a distraction. That distinction is worth more than a page of timeout messages.

Change the path, not the certificate

Test the same client, same certificate and same configuration from a different network. A mobile hotspot is usually the cheapest second path, and it is genuinely different from the office link rather than nominally different.

If the handshake completes on the second path, the certificate chain is fine and the first path is the variable. If it fails identically on both, stop testing networks and look at the messages themselves. That single comparison removes about half the possible explanations.

Measure the exchange before you edit anything

Get the size of the chain and the size of the path. Both numbers constrain what the handshake can send, and both are cheap to measure:

openssl crl2pkcs7 -nocrl -certfile chain.pem | openssl pkcs7 -print_certs -noout | grep -c subject
ls -l chain.pem
ping -M do -s 1400 198.51.100.7
ip -s link show eth0 | sed -n '1,6p'

The first two give the number of certificates and the file size, which is a reasonable proxy for how large the authentication message will be. The ping probe reports whether a datagram of that size survives the path, and the interface counters show whether fragments were dropped at your end. On Windows, the equivalent probe is a ping with the do-not-fragment flag and an explicit payload size.

Repeat the probe downwards until it succeeds. The largest size that passes is the working budget for that path, and it is more useful than any published default.

Fix the layer that is actually broken

If the path drops large datagrams, enable IKE fragmentation on both peers and confirm the extension was negotiated rather than merely offered. If the path handles fragments badly at the IP level, the fix belongs there or in the MTU of the outer interface, not in the certificate store.

If the chain is unnecessarily long, trim it to the intermediate certificates a peer actually needs. Removing a root that the client already trusts is reasonable housekeeping; removing an intermediate is not, and disabling verification to shrink a message trades a delivery problem for a security one.

Write down which mechanism you changed and what the handshake looked like afterwards. The next occurrence is usually on a different network with the same symptom, and the note is what turns two hours into ten minutes.