| Description |
The article explains the behavior change in the FortiGate towards the replies to the ICMP packets originating from the Traceroute.
Note: This behavior never impacted the actual traffic flow. This only displays the incorrect Traceroute results. |
| Scope | FortiGate. |
| Solution |
In earlier FortiOS versions, where SD-WAN is deployed and ECMP routes are common, FortiGate would ignore ifIndex when checking the routing table. As a result, the route look-up will always return the first match, which may not be the best choice. It appears to the users as if the ICMP packet is sent from one interface, but ICMP_TIME_EXCEEDED packets are received from different Interfaces, which results in wrong Traceroute results.
The following image explains the behavior in previous versions:
The Sniffer output on FortiGate1:
2024-01-08 11:14:23.567254 VPN-4 out 10.103.192.125 -> 10.102.83.253: icmp: echo request
It can be seen above that the reply for the Traceroute is received from a different Interface.
The Sniffer output on FortiGate2:
2024-01-08 11:14:23.593790 HUB1-VPN4 in 10.103.192.125 -> 10.102.83.253: icmp: echo request
The ICMP_TIME_EXCEEDED Packet is received from a different Interface than of request packet.
Routing Table on FortiGate2 :
Routing table for VRF=0
This behavior is changed in FortiOS 7.0.16, 7.2.9, 7.4.4 and 7.6.0. Moving forward, ICMP_TIME_EXCEEDED packets will follow the same Interface as the original ICMP packet, meaning the correct Traceroute results will be seen. |
