Dynamic IP and Port NAT for ICMP Traffic
Resolution
Overview
The Dynamic IP and Port (DIPP) translation is dedicated to TCP and UDP related traffic only, and not to other IP protocols. The reason is because pure IP protocols, such as ICMP, do not use a L4 header that contains source and destination ports. On the other hand, ICMP protocol is widely used in networking as a simple connectivity test (either as PING or Traceroute). A common scenario in enterprise networks is that single DIPP translation is used for all LAN to internet traffic, since that approach consumes less IP address space. Therefore, ICMP traffic will also hit the same DIPP NAT policy.
Details
To translate ICMP traffic, Palo Alto Networks firewall takes the ID and Sequence fields from the ICMP header and treats them the same (internally) as if they were ports. This uses the Identification field as a source port reference and Sequence field as destination port reference. When the ICMP echo reply arrives on the firewall, it is being translated based on the values found in the Sequence and ID field of its ICMP header.
DIPP Policy:
XP-200 {
from Trust;
source 192.168.247.0/24;
to Untrust;
to-interface ;
destination any;
service any/any/any;
translate-to [ "src: 10.193.16.241 (dynamic-ip-and-port) (pool idx: 8)" " 10.193.16.242 (dynamic-ip-and-port) (pool idx: 8)" ];
terminal no;
An example of an ICMP echo request packet sent from host machine (tcpdump):
16:10:44.859384 IP (tos 0x0, ttl 64, id 40874, offset 0, flags [DF], proto ICMP (1), length 84)
192.168.247.248 > 8.8.8.8: ICMP echo request, id 22636, seq 438, length 64
16:10:44.867042 IP (tos 0x0, ttl 49, id 0, offset 0, flags [none], proto ICMP (1), length 84)
8.8.8.8 > 192.168.247.248: ICMP echo reply, id 22636, seq 438, length 64
Session is installed on the firewall for this ICMP traffic:
> show session all filter destination 8.8.8.8 protocol 1 source 192.168.247.248
------------------------------------------------------------------------------------------------------------------------------------
ID Application State Type Flag Src[Sport]/Zone/Proto (translated IP[Port]) Vsys Dst[Dport]/Zone (translated IP[Port])
------------------------------------------------------------------------------------------------------------------------------------
240674 ping ACTIVE FLOW NS 192.168.247.248[22636]/Trust/1 (10.193.16.241(22636]) vsys1 8.8.8.8[438]/Untrust (8.8.8.8[438])
Session is being translated using Identification and Sequence fields from the ICMP header:
> show session id 240674
Session 240674
c2s flow:
source: 192.168.247.248 [Trust]
dst: 8.8.8.8
proto: 1
sport: 22636 dport: 438
state: INIT type: FLOW
src user: unknown
dst user: unknown
s2c flow:
source: 8.8.8.8 [Untrust]
dst: 10.193.16.241
proto: 1
sport: 438 dport: 22636
state: INIT type: FLOW
src user: unknown
dst user: unknown
start time : Wed May 14 17:13:02 2014
timeout : 6 sec
total byte count(c2s) : 98
total byte count(s2c) : 98
layer7 packet count(c2s) : 1
layer7 packet count(s2c) : 1
vsys : vsys1
application : ping
rule : ANY-ANY
session to be logged at end : True
session in session ager : False
session synced from HA peer : False
address/port translation : source + destination
nat-rule : XP-200(vsys1)
layer7 processing : enabled
URL filtering enabled : False
session via syn-cookies : False
session terminated on host : False
session traverses tunnel : False
captive portal session : False
ingress interface : ethernet1/2
egress interface : ethernet1/3
session QoS rule : N/A (class 4)
tracker stage firewall : Aged out
Since ICMP Identifier and Sequence numbers are both 16 bits long, limitation in terms of number of translations per IP is the same as for TCP/UDP traffic, which means 65535 for source and 65535 for destination NAT. Also, limitation in terms of number of NAT DIPP policies applied to UDP/TCP traffic applies to ICMP traffic as well since they share the same memory space.
owner: djoksimovic