Inner and outer packets in a VPN capture: why sizes differ

You capture 1400-byte packets on the tunnel interface, capture again on the physical one, and the numbers refuse to line up. The addresses differ, the sizes differ, and the second file looks like a different conversation. Nothing is broken. Two different packets are sitting at two different layers, and the gap between them is what the tunnel does to your traffic. Read both views before you blame the MTU.

Two vantage points, and the packet each one shows

A capture taken on the tunnel interface shows the inner packet: the application's payload carrying its original source and destination, before any protection is applied. A capture on the physical interface shows the outer packet: an IP header, a transport header, the encapsulation, and then the encrypted inner packet as payload. Same conversation, different objects. Once you name which one the file contains, the mismatch stops being a mystery.

The size difference is overhead, and the address difference is design. Turn that around and the confusion becomes predictable: people compare an inner 1400-byte packet with an outer 1450-byte packet, decide something is wrong, and start changing MTU settings that were never at fault. Label the file with the interface and the layer, because that label is the first thing a reader needs and the first thing people omit.

Decide the layer before you start the capture

Decide which layer answers your question before the first packet is written. An MTU question usually needs the outer view, because that is where headers accumulate and where the path's limit shows up. An application question usually needs the inner view, because that is where the payload you care about still exists. Capturing both without a plan produces two files and no conclusion.

Use a harmless, authorised test and filter on the source, destination and time you care about. Read the capture tool's interface and filter options before collecting, since metadata is usually enough and is far easier to share than payload. Treat the inner capture as sensitive by default, because it holds unencrypted application data that only becomes protected further along the path.

What the size difference actually contains

The outer packet carries extra headers and protection material, and how much it carries depends on the protocol and its options. Fragmenting, aggregating or reordering along the path can break the apparent one-to-one relationship between an inner packet and the outer packets that carry it, so a size-by-size comparison is not always available. For a suspected MTU fault, look for size feedback and the point where traffic stops, then compare that with what the application reports. A retransmission pattern with no reply is a different signal from an ICMP error carrying a next-hop size.

A single packet that leaves the host proves nothing about whether the far end received it. If your capture ends at your own interface, you have shown that the kernel emitted something, which is the weakest evidence available about the path. Combine the capture with a repeatable symptom: same destination, same operation, same size, run twice with one variable changed.

Reading offload into the numbers

Host-side segmentation and other offload add a second distortion, and it is the one that makes local captures disagree with the wire. A local capture can show buffers that the adapter later splits, so the frames on the link are smaller and more numerous than the file suggests. That is why a large buffer in the capture file does not prove that an oversized frame crossed every link. If the sizes matter to your conclusion, record where the capture was taken and whether offload was active on that interface.

Otherwise you are measuring the host's convenience rather than the path's behaviour. Two files labelled with their interface and offload state settle most of these arguments in a minute.

Where the capture stops being evidence

Seeing encrypted outer packets shows that a protection boundary exists under these test conditions, and it says nothing about other applications on the device, the operator's handling, or the endpoint's own state. Seeing plaintext inside the tunnel does not mean the tunnel is broken either; it means you captured above the encryption point, which is a legitimate place to look. A capture is evidence about a place, not a verdict about a system, and the ticket should describe it that way. Keep the scope sentence in the report, because it is what stops a single observation from becoming an audit claim.

Name each file with its interface, filter and timestamp, and delete it when the investigation ends. The tcpdump manual documents the interface and filter flags used here, including the ones that keep a capture small.

If you must share evidence, share sizes, timestamps and flags rather than payload. The question was about packet size, and the answer rarely needs anyone's data.