Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[SRX] ICMP error message processing in SRX

0

0

Article ID: KB36089 KB Last Updated: 14 Aug 2020Version: 1.0
Summary:

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

Cause:

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.

Most commonly seen ICMP error codes:

    0  Echo Reply
    3  Destination Unreachable
    4  Source Quench
    5  Redirect
    8  Echo
   11  Time Exceeded
   12  Parameter Problem
   13  Timestamp
   14  Timestamp Reply
   15  Information Request
   16  Information Reply

For more information related to ICMP error codes and subcodes, refer to Internet Control Message Protocol (ICMP) Parameters.
Solution:

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:

The below ping result indicates that the ICMP echo request has been failed and returned ICMP error code as "frag needed and DF set" originated from the source 192.168.100.2.
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:

The session output indicates that the packet has been sent out from the SRX but the return traffic is not received. Since the ping was initiated from the SRX, it is taking the in-built security policy - self-traffic-policy.
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:

Flow traceoptions has been configured to capture the ping packets where packet-filters PF1 - Forward traffic and PF2 - Return traffic.
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.

root@SRX# run show log PING-TRACE | find PF2
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:<192.168.100.2/1->192.168.100.1/1;1> matched filter PF2:
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:packet [56] ipid = 0, @0x43eb0ba4
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x43eb0980, rtbl_idx = 0
Jun 12 18:36:58 18:36:58.497045:CID-0:RT: flow process pak fast ifl 69 in_ifp ge-0/0/0.0
Jun 12 18:36:58 18:36:58.497045:CID-0:RT: ge-0/0/0.0:192.168.100.2->192.168.100.1, icmp, (3/4)
Jun 12 18:36:58 18:36:58.497045:CID-0:RT: find flow: table 0x5419b7f8, hash 30020(0xffff), sa 172.16.31.20, da 192.168.100.1, sp 5478, dp 0, proto 1, tok 6
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:Found: session id 0x8e. sess tok 6
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:flow_find_session: This an Embedded ICMP pkt
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:  flow got session.
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:  flow session id 142
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:  existing vector list 0x300-0x4ad87410.
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:ICMP embedded packet, vector bits 0x300 vector:0x4ad87410
Jun 12 18:36:58 18:36:58.497045:CID-0:RT: vector bits 0x200 vector 0x4ad87410
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:flow_embedded_icmp_vector:embeded icmp vector icmp code 4
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:insert usp tag for apps
Jun 12 18:36:58 18:36:58.497045:CID-0:RT:mbuf 0x43eb0980, exit nh 0xfffb0006
Jun 12 18:36:58 18:36:58.497045:CID-0:RT: -----
flow_process_pkt rc 0x0 (fp rc 0)


ge-0/0/0.0:192.168.100.2->192.168.100.1, icmp, (3/4)  - Indicates incoming traffic on ge-0/0/0.0 interface with source as 192.168.100.2 destined to 192.168.100.1, protocol is ICMP with Type 3 Code 4 which is Fragmentation needed but don't fragment bit set.

flow_find_session: This an Embedded ICMP pkt - Indicates this traffic is matching an existing session and this is not an actual return traffic but an ICMP embedded packet containing the original ICMP Echo Request packet which has failed.

flow_process_pkt rc 0x0 (fp rc 0) - Indicates that return traffic is successfully processed without any errors.

Related Links

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search