When tunneling IP packets, there is an inherent MTU and fragmentation issue.

The issue occurs when the server or the client send relatively big packets as they are not aware of the MTU on the path. MTU on the path may be lower (due to the tunnel overhead), than what is configured on their local interfaces (usually client and server will have Ethernet interface with MTU of 1500 bytes).

If the link of the external interface of a Security Gateway - on which the encapsulated packets will be transmitted - would have MTU large enough to compensate for the encapsulation overhead, then the encapsulated big packets will be forwarded, and there would be no fragmentation issues.

However, in practice, the external interface will usually be a regular Ethernet interface supporting up to 1500 bytes MTU (sometimes even less, e.g., PPPoE on the Security Gateway, or on the next hop router).

Therefore, when the Security Gateway receives a packet from an internal Host, which fits the MTU of the external interface, but would exceed that MTU upon encryption, the Security Gateway encapsulates it and fragments the big outer ESP packet in order to fit into the external interface's MTU. The peer Security Gateway reassembles the ESP packets and decrypts them while the inner packet is intact.

Fragmentation and reassembly are considered to cause CPU and bandwidth overhead. While this document focuses on Check Point feature implementation for VPN, more general information can be found at RFC 4459 (and RFC 2923).