Carry a Fixed 1,500-Byte Inner Packet Across a VPN

You have a requirement that does not bend: the far side must receive the same 1,500-byte IP packet the sender emits, headers included. A tunnel cannot wrap that packet plus its own framing inside a second 1,500-byte IP packet, so something in the design has to give. The order below is the one I use in a change window: write the byte budget, prove what the underlay can actually carry, then pick exactly one carriage mechanism and confirm the inner packet on the far side.

Write the byte budget before editing a profile

Encapsulation adds bytes at several layers, and the total is a property of your profile rather than a constant you can look up. Address family, cipher choice, transport protocol and any compression or framing option all move the number, which is why a subtraction copied from another deployment is worthless as a budget. Start from the inner requirement, add the measured per-packet overhead of your own configuration, and write the resulting outer size on the change ticket before anyone edits a file.

Two numbers decide the design: the largest outer packet the path carries without fragmentation, and the extra bytes your encapsulation needs. When the first is smaller than the second plus 1,500, one of them has to change. The choice is then narrow rather than creative, which is why I write both numbers down before discussing options. Nothing at the tunnel layer compresses those bytes away, and no single MTU integer removes the requirement you were given.

Probe the underlay with do-not-fragment pings

Measure the path rather than trusting the interface MTU, because the smallest link in the outer path is the one that matters. On Linux, -M do sets the do-not-fragment bit and -s takes the ICMP payload, so a 1,500-byte frame answers at 1,472 bytes of payload once the 20-byte IP header and 8-byte ICMP header are subtracted. Walk the payload upward until the probe fails, then jump to a jumbo size to see whether the path carries it at all.

ping -M do -s 1472 -c 2 198.51.100.10
ping -M do -s 8972 -c 2 198.51.100.10
tracepath -n 198.51.100.10

A path that passes 1,472 and fails 8,972 cannot carry a 1,500-byte inner packet plus overhead in a single outer packet. That is the answer you needed before opening the VPN configuration. It also decides which of the next two sections applies to you, so keep the two probe results next to the ticket. Guessing here costs a maintenance window, because a tunnel that reports itself up tells you nothing about the largest packet the path will accept.

Raise the path MTU only where every hop agrees

Jumbo frames are an end-to-end property, not a setting you enable on the two endpoints you happen to control. Every switch, router and provider hand-off on the outer path must agree on the larger size, and a single 1,500-byte hop will silently discard the packet you just made bigger. Raising the local interface alone is the classic half-change that makes the tunnel look broken while the underlay quietly drops.

ip link set dev eth1 mtu 9000
ip link show dev eth1
ping -M do -s 8972 -c 2 198.51.100.10

Change the interface, then re-probe the same path before you change anything else. If the probe still fails, revert with ip link set dev eth1 mtu 1500 and move to fragmentation instead of arguing with a provider about a link you do not own.

Use tunnel fragmentation when the underlay cannot grow

A supported fragmentation mechanism below the inner packet lets several outer packets carry one inner packet, and the far tunnel endpoint reassembles them before handing the original up the stack. Community OpenVPN's UDP fragment option is one implementation of that idea, and it is not the same thing as ordinary IP fragmentation of the outer packet. Both peers must run a version that supports the format, and the data path must be the one you think it is: OpenVPN 3 clients and kernel-accelerated data channels have different limits, so a profile that works on one client can fail on another.

openvpn --config client.ovpn --tun-mtu 1500 --fragment 1400 --verb 4

Ordinary outer fragmentation is the other option, and it is the weaker one. IPv6 routers do not fragment a forwarded packet at all, so an oversized outer packet simply dies and the sender learns about it only if the relevant ICMPv6 message survives the path. Fragments also invite filtering and loss amplification, which is why I treat this as a fallback rather than a plan.

A stream-based outer carrier sidesteps the size question by segmenting its own byte stream, and the reconstructed inner packet can still be 1,500 bytes. That is a transport decision with its own cost, including the well-known behaviour of TCP inside TCP, so make it deliberately rather than as a side effect of an MTU argument.

Confirm the inner packet arrives unchanged

Verification is not a successful handshake. Capture on the tunnel interface at both ends and compare the size and content of the packet the application actually sent with the one the far side received.

ip link show dev tun0
ping -M do -s 1472 -c 2 10.8.0.1
tcpdump -ni tun0 -c 5 'icmp and greater 1000'

If the capture shows the full-size inner packet at the far end, the carriage choice works and the remaining task is to record it. If it shows nothing while the tunnel reports itself up, the outer packet is being dropped somewhere between the endpoints, which sends you back to the probe rather than to the cipher settings.

Record three things in the change ticket before you close it: the measured outer budget, the mechanism you chose, and the command that proved the inner packet survived. The next person to touch this tunnel will need all three, and none of them can be reconstructed from the configuration file alone.