Options
Fragmenting ESP traffic
Hi there! My name is Maurice. I work level 3 tech support for SonicWALL. As you may imagine, we do LOTS of VPN troubleshooting. The topic of this thread is regarding fragmentation of outbound IP traffic on an interface of a router/firewall.
Let's say a router receives an inbound IP packet carrying ESP traffic, and the outbound interface has a lower MTU than the inbound interface. I understand that the router will fragment the ESP payload, the destination VPN endpoint will re-assemble the fragmented ESP payload, and calculate a correct checksum against the ESP payload.
This assumes 3 things:
1. That every intermediate router the packet flows through to reach its destination must also fragment packets larger than the outbound interface's MTU.
2. The added router processor overhead of fragmenting packets and accepting fragmented packets is acceptable.
3. The drop in bandwidth efficiency due to increased header overhead of fragmented packets is acceptable.
Now to the point...
My colleagues always jump to the conclusion that fragmentation is the reason why some network technologies don't work correctly. As a result, they set most computer/firewall/VPN concentrator interface MTU's to 1404 bytes. They believe that an MTU of 1404 is a "sweet spot" as it is not too small to cause much of a decrease in bandwidth efficiency, and not too big to ever be fragmented by 99% of router interfaces on the internet.
I would like to get some feedback from the community on IP fragmentation. Specifically, does fragmenting a packet larger than a router's outbound interface MTU cause problems with payloads that must pass checksum validation?
Let's say a router receives an inbound IP packet carrying ESP traffic, and the outbound interface has a lower MTU than the inbound interface. I understand that the router will fragment the ESP payload, the destination VPN endpoint will re-assemble the fragmented ESP payload, and calculate a correct checksum against the ESP payload.
This assumes 3 things:
1. That every intermediate router the packet flows through to reach its destination must also fragment packets larger than the outbound interface's MTU.
2. The added router processor overhead of fragmenting packets and accepting fragmented packets is acceptable.
3. The drop in bandwidth efficiency due to increased header overhead of fragmented packets is acceptable.
Now to the point...
My colleagues always jump to the conclusion that fragmentation is the reason why some network technologies don't work correctly. As a result, they set most computer/firewall/VPN concentrator interface MTU's to 1404 bytes. They believe that an MTU of 1404 is a "sweet spot" as it is not too small to cause much of a decrease in bandwidth efficiency, and not too big to ever be fragmented by 99% of router interfaces on the internet.
I would like to get some feedback from the community on IP fragmentation. Specifically, does fragmenting a packet larger than a router's outbound interface MTU cause problems with payloads that must pass checksum validation?
Comments
-
Options
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Checksums are recomputed before the packets are sent on from each intermediate IP device even without fragmentation. As long as all fragments reach the endpoint intact and within a reasonable time to allow the original packet to be reassembled (based on timeouts and buffer limits) the payload will be unaffected. The main issue is with the load fragmentation will place on any device having to perform fragmentation/defragmentation, for example on most Cisco routers this process is punted to the CPU so all those nice advancements in packet switching get bypassed. Also fragmentation is an effective way to attack most network devices (either directly through the recompiled packet engaging an exploit or simply by using them to attack your device control-plane), and/or evade IDS/IPS systems so it is undesirable regardless (many organizations will filter fragments as part of their security policies). Avoid whenever possible.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?