| Description |
This article explains the behavior of fragmented packets seen in packet capture on FortiGate. |
| Scope | FortiGate. |
| Solution |
Consider the traffic flow as follows: Client --> Switch --> FortiGate-HW --> Azure Express Route --> FortiGate-VM (Azure) --> Server
The client sends a request to the Server, and below is the packet capture taken on the Switch (connected to FortiGate-HW).
As the packet size is larger than the default MTU (1500 bytes), it is split into two frames. The total frame length is 1518 bytes, which consists of Ethernet header (14 bytes), VLAN ID (4 bytes,) and IP header (20 bytes). The actual data is of 1480 bytes.
Below is the packet capture from FortiGate-HW, which receives the same frame as expected. VLAN ID tag is removed on FortiGate-HW.
After sending the traffic towards FortiGate-VM via Azure Express Route, the fragmented packet gets further fragmented. Azure Express Route doesn't accept packets higher than 1400 bytes.
Frame 21 from FortiGate-HW gets split into three after receiving on FortiGate-VM. The fragment offset field tells the receiver the position of a fragment in the original datagram.
More information in RFC 791
Frame 22 from FortiGate-HW is not seen on FortiGate-VM at all. Hence, the 'Fragment Reassembly Time Exceeded' message in frame 36 indicates that not all of the fragments are received within the allotted time (default: 30 seconds).
Related documents: Technical Tip: How to check if FortiGate is fragmenting the traffic and what is the correct MTU size https://learn.microsoft.com/en-us/azure/expressroute/expressroute-about-virtual-network-gateways https://learn.microsoft.com/en-us/azure/expressroute/expressroute-faqs |
