FortiGate
FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.
wdeloraine_FTNT
Article Id 378479
Description This article describes how are processed the ICMP error messages received on a chassis-based FortiGate.
Scope FortiGate-6000F, 7000E and 7000F series.
Solution

Prerequisites:

  • ICMP error messages are generated by either a host or a router that is not able to process a legit application packet such as UDP or TCP.
  • Those messages can be type 3 code 0, destination network unreachable; type 3 code 1, destination host unreachable; type 3 code 3, destination port unreachable; type 3 code 4, fragmentation required; type 11 code 0, TTL expired.
  • Type 3 or type 11 messages are generated upon reception of UDP or TCP packets.
  • ICMP messages do have not the application messages in their headers.
  • The application information is embedded in the payload.

 

Considering the following scenario:

  1. Chassis has received UDP packet IPsrc Psrc-> IPdst Pdst
  2. Processing blade is chosen
  3. DP session is created for the return traffic based on packet definition (IPs, ports, protocol
  4. Blade processed the packet and has added a one-way session for now
  5. The packet is sent back to the physical port (FIM or MBD) and gets out to the next hop
  6. The packet went through the network but at some point, the packet was dropped and an ICMP error message is generated
  7. This ICMP error message is then received on the chassis.
  8. The chassis is not able to match the DP session based on the original traffic because the IP protocol has changed from UDP to ICMP and either src or dst ports are not on the packet header anymore
  9. The chassis will broadcast this ICMP error message to all blades to make sure the packet hits the same processing blade where the packet was seen for the first time
  10. The worker blade will look at the ICMP payload and it will be able to match the one-way session previously create
  11. ICMP packet will be allowed and transmitted to the original client as a reply to its communication attempts.

 

#legit traffic

[FPC01] 103.061234 v140 in 70.70.70.70.12345 -> 131.0.1.11.443: syn 987654
[FPC01] 103.061583 v141 out 141.0.1.106.12345 -> 131.0.1.11.443: syn 987654
[FPC01] 103.061586 port15 out 141.0.1.106.12345 -> 131.0.1.11.443: syn 987654

#ICMP error message as a reply
[FPC01] 103.062222 v141 in 141.0.1.254 -> 141.0.1.106: icmp: 131.0.1.11 unreachable - need to frag (mtu 800)
[FPC01] 103.062428 port15 out 141.0.1.254 -> 70.70.70.70: icmp: 131.0.1.11 unreachable - need to frag (mtu 800)
[MBD ] 103.056377 v141 in 141.0.1.254 -> 141.0.1.106: icmp: 131.0.1.11 unreachable - need to frag (mtu 800)

# reply broadcasted
[FPC02] 103.075775 v141 in 141.0.1.254 -> 141.0.1.106: icmp: 131.0.1.11 unreachable - need to frag (mtu 800)
[FPC04] 103.075726 v141 in 141.0.1.254 -> 141.0.1.106: icmp: 131.0.1.11 unreachable - need to frag (mtu 800)
[FPC06] 103.080496 v141 in 141.0.1.254 -> 141.0.1.106: icmp: 131.0.1.11 unreachable - need to frag (mtu 800)
[FPC05] 103.083237 v141 in 141.0.1.254 -> 141.0.1.106: icmp: 131.0.1.11 unreachable - need to frag (mtu 800)
[FPC03] 103.050471 v141 in 141.0.1.254 -> 141.0.1.106: icmp: 131.0.1.11 unreachable - need to frag (mtu 800)