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.
LAN2 (192.168.250.2) ---------- (ge-0/0/0 : 192.168.250.1) SRX (ge-0/0/1) ----------------- (192.168.251.123) LAN1
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
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.
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
2019-07-06: Article reviewed for accuracy. Additional details added referencing the checksum value in the sample image.