Technical Tip: FortiGate using 4.x kernel sending out ICMP TTL exceeded packet without checking Firewall Policies (Known Issue)
| Description | This article describes a known issue where the FortiGate always transmits ICMP 'Time to Live exceeded in transit' messages in response to incoming packets with a TTL of 1, even when Firewall Policies exist that should deny this traffic (and thus prevent the ICMP response from occurring). This issue notably affects the FortiGate-VM, but also applies to newer FortiGates like NP7-based models. |
| Scope | FortiGate, ICMP. |
| Solution | When receiving incoming packets with an IPv4 time-to-live (TTL) of 1, the expected behavior as defined by RFC 1812 is for the network device to drop the packet and send an ICMP TTL exceeded packet back towards the source. On the FortiGate, this behavior is further controlled by Firewall Policies, where the expected behavior is based on the action of the matching Firewall Policy:
While this behavior is true for older FortiGate models running the older 3.x Linux kernel (such as the FortiGate-601E and 1500D, as well as the desktop SOC4 units like the FortiGate-60F), it was observed that FortiGates running the newer 4.x kernel (such as FortiGate-VMs and NP7 FortiGates) were not checking the Firewall Policies and were always replying with ICMP TTL exceeded packets after receiving packets with TTL=1. To check the current Linux kernel version of the FortiGate, use the command fnsysctl cat /proc/version.
This issue is being tracked as part of Issue #1171392 and will be fixed in FortiOS v7.4.10, v7.6.4, and the upcoming v8.0. The fix will align the behavior to how it was for the earlier 3.x kernel, where the FortiGate only sends an ICMP TTL exceeded response if the traffic would normally match a policy with the allow action. Below are examples of the observed issue:
Example 1: In this example, a FortiGate-601E has been configured with a Firewall Policy to deny all traffic, and traceroute is used here with the -T flag to send twenty TCP SYN-based probes from the client through the FortiGate. When the FortiGate receives the TCP SYN with TTL=1, it receives and drops the incoming SYN packet but does not reply to the client with 'icmp: time exceeded in-transit' (this is the expected behavior).
Example 2: On the same FortiGate-601E, the policy has been modified to allow this TCP traffic through. The FortiGate drops the first TCP traceroute since the TTL has expired, and it does respond to the source with 'icmp: time exceeded in-transit'.
Example 3: This example is similar to Example 1, but the FortiGate-601E has been replaced with a FortiGate-VM (which uses the newer 4.x kernel) running FortiOS 7.4.8. Despite having a deny-all policy present, the FortiGate-VM drops the incoming packet with TTL=1 and does respond with an 'icmp: time exceeded in-transit' message:
|