This article explains the behavior of ICMP error packet or Embedded ICMP packet processing in SRX series devices.

ICMP error packets contain error codes that are sent to the source if there is any issue in delivering the packet to the destination due to error conditions such as Destination Unreachable, Fragmentation Required, TTL Expiry etc. These error messages always contain the IP header, along with the first 8 bytes of the original datagram's data that caused the error. Such packets are known as Embedded ICMP packets .

If the Routing devices were involved, then ICMP error packet processing is normal where only route lookup happens based on the destination. But if firewalls were involved such as SRX, the processing will be different, because SRX being a stateful firewall will maintain session information.

When the ICMP error packets reach the SRX, the default behavior is to inspect the IP packet which is embedded in the ICMP error packet. If the embedded packet is part of an existing session, the ICMP packet is allowed to pass through and if there is no match, it is dropped. In order to allow ICMP error packets to pass through the device even when there is no session match for the embedded packet, use " set security flow allow-embedded-icmp".

If the packet contains an Embedded ICMP packet then the session lookup is performed based on that Embedded packet. That's the reason the ICMP error packets will be successfully processed irrespective of traffic being originated from the Untrust zone.  

To demonstrate this behavior, the ping has been initiated from the SRX to the destination 172.16.31.20 with size = 1000, count = 2 along with DF-bit set.


 

Ping Results:

root@SRX# run ping 172.16.31.20 size 1000 do-not-fragment count 2
PING 172.16.31.20 (172.16.31.20): 1000 data bytes

36 bytes from 192.168.100.2: frag needed and DF set (MTU 486)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0404 fa05   2 0000  40  01 4d25 192.168.100.1  172.16.31.20

36 bytes from 192.168.100.2: frag needed and DF set (MTU 486)
Vr HL TOS  Len   ID Flg  off TTL Pro  cks      Src      Dst
4  5  00 0404 fa0a   2 0000  40  01 4d20 192.168.100.1  172.16.31.20

--- 172.16.31.20 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

Session Output for the Ping:

root@SRX# run show security flow session protocol icmp
Session ID: 149, Policy name: self-traffic-policy/1, Timeout: 2, Valid
  In: 192.168.100.1/1 --> 172.16.31.20/5529;icmp, If: .local..0, Pkts: 1, Bytes: 1028
  Out: 172.16.31.20/5529 --> 192.168.100.1/1;icmp, If: ge-0/0/0.0, Pkts: 0, Bytes: 0
Total sessions: 1

Flow Traceoptions Summary:

root@SRX# run show log PING-TRACE | match matched
Jun 12 19:04:12 19:04:12.743083:CID-0:RT:<192.168.100.1/0->172.16.31.20/5529;1> matched filter PF1:
Jun 12 19:04:12 19:04:12.746444:CID-0:RT:<192.168.100.2/1->192.168.100.1/1;1> matched filter PF2:
Jun 12 19:04:13 19:04:13.744220:CID-0:RT:<192.168.100.1/1->172.16.31.20/5529;1> matched filter PF1:
Jun 12 19:04:13 19:04:13.747088:CID-0:RT:<192.168.100.2/1->192.168.100.1/1;1> matched filter PF2:

Flow Traceoptions Extensive:

Let's dive deep and see what is happening inside the Junos flow. Below is the excerpt from flow traceoptions which was configured earlier and the important information has been highlighted with regards to this ICMP error packet.

• allow-embedded-icmp