Big packets vanish over IPsec while small pings still work

Remote shells stay responsive, small probes answer, and then a file copy crawls and stalls with no error anyone can point at. Ping with a larger payload reproduces it instantly, and the same transfer works from the local network. Nothing about the encryption is slow; certain packets never arrive. Two different splits can produce that signature, and they leave different evidence.

Two places a packet can be divided

Before encryption, the router can split an oversized inner packet and protect each piece separately. After encryption, the finished outer packet is what gets divided, and the far end has to reassemble it before it can decrypt anything. Same symptom, different work for the receiver and different knobs for you.

The distinction matters because a fix aimed at the wrong side changes a number without moving the failure. A packet refused at the interface never becomes an outer packet at all, so no outer-side setting can rescue it.

Where the size decision is really made

A tunnel interface carries an IP MTU, and that value can reject an oversized inner packet long before the IPsec stage sees it. Setting a bit on the outer header does not revisit that earlier decision, because the packet was already refused. This is why raising the inner MTU sometimes makes things worse rather than better. Read the interface value and the outer behaviour before changing either, because the cheaper edit is usually the one that explains the symptom.

Check the interface value first, then the outer behaviour. Two numbers, two stages, and only one of them is usually responsible.

The outer budget is not the inner budget

Every encapsulation spends bytes on headers, and the amount depends on the transport, the address family and whether NAT traversal is in play. An inner packet that fits the local link can still produce an outer packet that does not fit the path beyond it. Measure the overhead rather than assuming it, since every optional header adds to the bill. A tunnel with NAT traversal pays more than a bare one, and the difference is enough to break a transfer that worked yesterday.

Where the outer packet carries a do-not-fragment bit, a hop that cannot forward it drops it and should return an ICMP message. If that message is filtered somewhere, the sender keeps retrying and the user sees a stall with no explanation. That silent drop is the usual reason a size problem gets reported as a speed problem.

IPv6 removes one of the options

IPv6 routers do not fragment in transit, so the outer packet either fits or disappears with a Packet Too Big message. That message becomes the only feedback channel, and blocking it breaks path discovery for every large transfer that follows. IPv4 routers may fragment a large packet when the bit is clear, which hides the fault until something else sets that bit.

On a mixed stack, the same tunnel can behave differently for the two families, which is why one test over IPv4 does not settle an IPv6 complaint. A check that exercises one family leaves half the answer unmeasured.

TCP segment policy is not a general answer

Clamping the maximum segment size helps TCP flows, and it is a legitimate control when the problem is confined to them. It has no effect on UDP, which carries DNS, some voice protocols and a growing share of web traffic.

Apply it, then test the workload that failed. If the UDP case still fails, the segment policy was never the answer and the interface budget still needs attention. Identify the failing workload's protocol first, then pick the control that belongs to it.

The order to work in

Record the largest payload that survives, then the interface MTU, then whether the outer packet carries the do-not-fragment bit, and finally whether ICMP feedback reaches the sender. That sequence narrows the fault without guessing. Keep each observation with a timestamp and an endpoint, because all four numbers move when the path changes.

Change one value, retest the original transfer, and keep the result. A tunnel that passes a large probe but still stalls on the application has moved to a different problem, which is progress worth writing down. The next person would rather have the numbers than the conclusion.