IPsec Overhead Calculator
Estimate ESP, NAT-T, GRE, L2TP, MTU, MSS clamp, packet expansion, and throughput impact for site-to-site and remote access VPN tunnels.
| Configuration | Typical Added Headers | 1500 MTU Payload | Best Use |
|---|---|---|---|
| ESP tunnel, IPv4, AES-GCM | Outer IP + ESP + IV + ICV + pad | About 1436-1446 bytes | Modern site-to-site VPN with clean underlay |
| ESP tunnel with NAT-T | IPv4 + UDP 4500 + ESP fields | About 1428-1438 bytes | Home ISP or branch behind NAT |
| GRE over IPsec | Extra IP + GRE + ESP tunnel | About 1412-1424 bytes | Dynamic routing or multicast over VPN |
| L2TP/IPsec remote access | PPP + L2TP + UDP + ESP + outer IP | About 1390-1420 bytes | Legacy clients and compatibility tunnels |
| PPPoE underlay plus NAT-T | 1492 base MTU before IPsec headers | Often 1420 bytes or lower | Residential fiber or DSL handoff |
| Item | Value | Calculation Role | Planning Note |
|---|---|---|---|
| Ethernet payload MTU | 1500 bytes | Common WAN and LAN baseline | Subtract tunnel overhead from this value |
| PPPoE MTU | 1492 bytes | 8 bytes lower than Ethernet MTU | Common cause of IPsec fragmentation |
| IPv4 TCP MSS | MTU minus 40 | 20 byte IPv4 + 20 byte TCP header | Use as baseline clamp for IPv4 TCP |
| IPv6 TCP MSS | MTU minus 60 | 40 byte IPv6 + 20 byte TCP header | Needed when inner traffic is IPv6 |
| ESP trailer | 2 bytes plus pad | Pad length and next header fields | Padding varies with payload size and cipher block |
| VLAN tag | 4 bytes | L2 frame overhead, not IP payload MTU | Include when checking wire frame budget |
| Scenario | Underlay MTU | Recommended MTU | Expected MSS |
|---|---|---|---|
| Small home lab site-to-site | 1500 bytes | 1436-1440 bytes | 1396-1400 bytes |
| ISP router with NAT-T | 1500 bytes | 1428-1432 bytes | 1388-1392 bytes |
| PPPoE fiber gateway | 1492 bytes | 1420-1428 bytes | 1380-1388 bytes |
| GRE routing overlay | 1500 bytes | 1412-1424 bytes | 1372-1384 bytes |
| Jumbo MTU data center VPN | 9000 bytes | 8900+ bytes | 8860+ bytes |
A VPN may work correct for small amount of data. However, when a person try to move a large file through the VPN, the VPN may fail. There is several reasons for this.
One reason might be the maximum transmission unit, or the MTU. The MTU are the maximum size of a data packet. When data moves across a networks, protocols like IPsec add security information to the data packets.
Why VPNs stop working with big files
That information take up more space in the data packet than the original data packet. The network can only recieve data packets of a certain size. If a data packet are larger than the network can handle, the data packet get dropped or fragmented.
Every security choice add extra bytes to the data packet. This is true of encryption method. When a person chooses an encryption method, the method will take up some of the available size of the data packet.
For instance, the AES-GCM encryption method do encryption and authentication in the same step. This saves bytes compared to method like the CBC method. With the CBC method, another tag is create for authentication that takes up part of the data packet size.
Because every byte counts for the data payload being transport, choosing an encryption method that takes up a few bytes of the data packet is a benefit. Another factor are how the data packet traverses networks. Sometimes the VPN’s gateway is behind a router that use NAT.
In that case, IPsec place the data packet in another UDP header. That header is eight byte. Eight bytes might seem like few byte, but each byte that a header use up does not get to be used for data.
Another factor is the internet service provider’s connection. Some internet connections use PPPoE. PPPoE connections use a capped MTU of 1492 byte instead of the standard 1500 bytes.
This means there is less room for data in the data packet. The maximum segment size, or the MSS, are another factor that a person need to understand. The MTU set the limit for the size of the data packet.
However, two TCP endpoints negotiate the MSS. When a person does not clamp the MSS, the TCP endpoints will use full-sized packets. When the VPN receive these full-sized packets, it has to fragment the data packets.
Fragmentation of packets use the CPU cycles on the receiving router to assemble the fragments of the data packets. Fragmentation can create latency in moving the packets and can cause them to get lost in transmission. By clamping the MSS, the system tell the TCP endpoints to use smaller data packets from the beginning.
This will eliminate fragmentation. The last factor is the physical hardware. The hardware use to set up the VPN can have an impact on how the data packets are encrypted.
For instance, a small home firewall might encrypt the data different than a data center appliance. Data center appliances has dedicated instructions to assist with the encryption process. The larger the packets and the higher the packet rate, the more the CPU will be required to handle the encryption.
The higher the CPU requirement, the more the throughput will drop. A person might have a high-speed link to the internet using a gigabit link. However, if the CPU cannot keep up with the data encryption, the data will not reach those speed.
A person should of allow some buffer for the VPN setup. The networking environment can have elements a person does not account for. For instance, a data packet might have to include vendor-specific tags in it, depending on the software or hardware in use.
A person setting up the VPN with the absolute theoretical maximum limit for the size of the data packets will not allow for any errors with these extra data field. A buffer will help to prevent the tunnel from breaking if the internet service provider change a setting on the network. If a person does not take time to calculate the MTU and the MSS, a person is essentially guess at what settings to use for the VPN system.
By calculating how many byte go to each header and providing padding for the data packets, a person can be confident that the VPN will remain stable during data transfers of large file.
