IPsec overhead: mode, NAT-T and algorithms all change it
A single published overhead figure describes one encapsulation on one path. Add up the headers your tunnel actually negotiates, then measure the path.
Somewhere in a guide there is a number, usually between sixty and eighty bytes, that someone subtracted from 1500 to get an interface MTU. That number describes one specific encapsulation on one specific path. Change the mode, the outer address family, the cipher or the presence of NAT, and the arithmetic no longer applies to your tunnel.
The number came from a different tunnel
Overhead is not a property of IPsec in the abstract. It is a property of the packet that actually gets built: a negotiated mode, an outer header, a protection header, padding, an integrity field and possibly an extra UDP wrapper.
A figure quoted for transport mode with IPv4 and no NAT describes a smaller packet than tunnel mode with IPv6 under NAT traversal. Both are correct for their own case. Copying either into a different deployment is how people end up with an MTU that breaks large transfers. The failure is quiet because small requests keep working.
Add up the layers that are really there
Start from the outer IP header and work inwards. In tunnel mode the original packet is inside, so the outer header is an addition rather than a replacement. RFC 4303 describes the ESP header, the padding and the integrity data that follow it.
| Layer | What it adds | When it applies |
|---|---|---|
| Outer IP header | 20 bytes for IPv4, 40 for IPv6 | Always, and 40 rather than 20 if the outer path is v6 |
| ESP header | 8 bytes of SPI and sequence number | Always |
| Block cipher IV | 8 to 16 bytes depending on the transform | When the negotiated cipher uses one |
| Padding and trailer | Padding to the block size, plus two trailer bytes | Always, and the amount varies with payload length |
| Integrity data | 12 to 16 bytes for common authenticated ciphers | When integrity protection is negotiated |
| UDP encapsulation | 8 bytes | NAT traversal on port 4500, which is common for clients behind NAT |
None of those rows is constant across deployments, and the padding row is not even constant within one deployment. That is the whole reason a single published overhead figure disappoints.
Two sites can disagree about the same tunnel
The protected packet still has to cross the outer path, and the outer path is not the same everywhere. A PPPoE access link carries less than a clean Ethernet segment. A mobile network may shrink further, and a provider that tunnels its own traffic adds another encapsulation nobody mentioned. A tunnel that works on one link and fails on another is describing the second link, not the protocol.
Both directions can differ as well. An asymmetric route can give you a working upload and a stalled download, which reads as an application problem until you look at packet sizes rather than at reachability. A small ping succeeding proves very little about a full-size response.
Measure instead of subtracting
Find the largest datagram that survives the path. Then compare it with the value the interface reports:
ip link show eth0 | grep -o 'mtu [0-9]*' ip xfrm state list ping -M do -s 1400 198.51.100.7 ping -M do -s 1372 198.51.100.7 tcpdump -ni any -c 20 'esp or udp port 4500'
Walk the ping size down until replies arrive, and treat the largest working value as the budget for that path. The xfrm output tells you which mode and which algorithms were negotiated, which is the input to any honest calculation. The capture confirms whether ESP or UDP-encapsulated ESP is on the wire, which settles the NAT question without guessing.
Reserve one value for the control plane as well. IKE handshake packets have a different structure from data packets, so a size derived from a handshake capture is not a data-plane MTU.
Put the number where it belongs
For TCP through a tunnel, an MSS clamp is often the least invasive control, because it reduces what the endpoints send without changing the tunnel itself. For a route-based tunnel, set the tunnel interface MTU deliberately and document why. Doing both at once and then measuring gives you no information about which one helped.
Keep the negotiated mode, outer family, NAT condition and the reproducible symptom together in the ticket. A recorded set of four facts beats a remembered constant, and it is the only version of this that survives the next client upgrade.