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] Selective ICMP drops while using Destination NAT without protocol filter

0

0

Article ID: KB32123 KB Last Updated: 24 Jul 2019Version: 2.0
Summary:

ICMP packets with specific checksum values do not get a response back from the SRX. This is as per the current flow design of SRX. This article explains the issue and suggests some workarounds.

Symptoms:

Sample Topology :     

LAN2 (192.168.250.2) ---------- (ge-0/0/0 : 192.168.250.1) SRX  (ge-0/0/1) -----------------  (192.168.251.123) LAN1
This is a simplified design where the end user is trying to ping the IP address 192.168.250.1 from 192.168.250.2. Some ICMP packets with specific checksum values do not get a response back from the firewall. This happens only when the destination NAT is configured to match only on port numbers.

Example:

set security nat destination pool DestinationPool address 192.168.251.123/32
set security nat destination rule-set incoming from zone untrust
set security nat destination rule-set incoming rule Rule_174 match destination-address 0.0.0.0/0
set security nat destination rule-set incoming rule Rule_174 match destination-port 174
set security nat destination rule-set incoming rule Rule_174 then destination-nat pool DestinationPool

SRX will try to NAT translate this ICMP packet with rule Rule_174 and process the packet. In the testbed, there was no policy configured for this traffic and hence this traffic was dropped after getting NAT translated. The following debug messages appear in the log file:

Aug 24 21:15:04 21:15:04.735663:CID-0:RT:<192.168.250.2/5599->192.168.250.1/0;1> matched filter PF2:
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:packet [46] ipid = 9451, @0x43eabf24
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x43eabd00, rtbl_idx = 0
Aug 24 21:15:04 21:15:04.735663:CID-0:RT: flow process pak fast ifl 77 in_ifp ge-0/0/0.0
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:  ge-0/0/0.0:192.168.250.2->192.168.250.1, icmp, (8/0)
Aug 24 21:15:04 21:15:04.735663:CID-0:RT: find flow: table 0x5fa8f970, hash 25805(0xffff), sa 192.168.250.2, da 192.168.250.1, sp 5599, dp 0, proto 1, tok 7 
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:  no session found, start first path. in_tunnel - 0x0, from_cp_flag - 0
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:check self-traffic on ge-0/0/0.0, in_tunnel 0x0
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:retcode: 0x204
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:pak_for_self : proto 1, dst port 0, action 0x4
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:  flow_first_create_session
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:First path alloc and instl pending session, natp=0x6143e8e0, id=7233
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:  flow_first_in_dst_nat: in <ge-0/0/0.0>, out <N/A> dst_adr 192.168.250.1, sp 5599, dp 0
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:  chose interface ge-0/0/0.0 as incoming nat if.
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:flow_first_rule_dst_xlate: DST xlate: 192.168.250.1(0) to 192.168.251.123(0), rule/pool id 4/32769.  <<<<<<<<<<< HERE
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:flow_first_routing: vr_id 0, call flow_route_lookup(): src_ip 192.168.250.2, x_dst_ip 192.168.251.123, in ifp ge-0/0/0.0, out ifp N/A sp 5599, dp 0, ip_proto 1, tos 0
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:Doing DESTINATION addr route-lookup
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:flow_ipv4_rt_lkup success 192.168.251.123, iifl 0x4d, oifl 0x46 
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:Clear MNG session flag as it's not host traffic after dst NATAug 24 21:15:04 21:15:04.735663:CID-0:RT:  routed (x_dst_ip 192.168.251.123) from untrust (ge-0/0/0.0 in 0) to fe-0/0/6.0, Next-hop: 172.22.145.1
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:flow_first_policy_search: policy search from zone untrust-> zone management (0x110,0x15df0000,0x0)
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:  app 0, timeout 60s, curr ageout 60s
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:   could not find policy
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:  packet dropped, no policy.
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:flow_initiate_first_path: first pak no session
Aug 24 21:15:04 21:15:04.735663:CID-0:RT:  flow find session returns error.
Aug 24 21:15:04 21:15:04.735663:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc -1)

You can also verify that the NAT translation counter is incrementing for such traffic with failed sessions.

> show security nat destination rule  Rule_174

Destination NAT rule: Rule_174               Rule-set: incoming
  Rule-Id                    : 4
  Rule position              : 4
  From zone                  : untrust
    Destination addresses    : 0.0.0.0         - 255.255.255.255
    Destination port         : 174             - 174
  Action                     : DestinationPool
  Translation hits           : 5     <<<<<<<<<<<<<<<<<<<<<<<< DST NAT rule getting hit
    Successful sessions      : 0
    Failed sessions          : 5     <<<<<<<<<<<<<<<<<<<<<<<< Session creation failed
  Number of sessions         : 0
Cause:

All sessions on the firewall require 5-tuples to identify them which include Source IP, Destination IP, Source Port, Destination Port and Protocol. Unlike TCP/ UDP traffic, ICMP packets do not have source/destination port numbers that can be used to maintain a session state in firewalls. Therefore, SRX uses the Checksum value of the ICMP packet as its destination port number to match the Destination NAT rule. Hence, if there is no protocol configured in the NAT rule, SRX will match that NAT rule for all types of traffic matching the NAT rule-set context. ‚Äč

The sample capture below shows the checksum value in the ICMP echo request packet, the checksum value "0x00ae" translates to "174" in decimal. Since the destination port in the NAT rule we configured is 174, it tries to translate this ICMP packet.

Solution:

This is as per the current flow design of SRX. There are a few ways around this:

1. It is recommended to configure NAT rules with more specific terms that contain protocol, destination addresses along with port numbers.

2. Create a new DST NAT rule to avoid processing ICMP packets:

set security nat destination rule-set incoming rule SKIP-ICMP match destination-address 0.0.0.0/0
set security nat destination rule-set incoming rule SKIP-ICMP match protocol icmp
set security nat destination rule-set incoming rule SKIP-ICMP then destination-nat off

Do not forget to add this rule to the top of the DST NAT rule list. Use the following command:

# edit security nat destination rule-set incoming
# insert rule SKIP-ICMP before rule Rule_174
# commit
Modification History:
2019-07-06: Article reviewed for accuracy.  Additional details added referencing the checksum value in the sample image.
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