How NAT/PAT handles ping/icmp

I've been having thoughts about this for a while. We know that PAT uses TCP/UDP port numbers to distinguish between inside hosts via a mapping table for private IPs, internal/external ports and all that stuff, all happen so that the return packets from outside (despite having the same destination IP) will remap and reach the correct inside host.

Now how can ping/icmp replies route back to the inside while we know ICMP is not at the TCP/UDP level, so it does NOT use port numbers at all? Any idea? May be I'm missing some thing.

Practically, I'm behind PAT and I can always ping outside.

Hum solo that`s a good taught , I taught about it for a while too .

I am not sure if this is the right answer for ASA`s but it could give you some insight . If you configure a router to do NAT overload and if you start pinging outside and simultaneously see the nat translations that are being built you will see the following .

EX:x.x.x.x and y.y.y.y are translated and pinged ip addresses respectively .


CORE02#sh ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp y.y.y.y:1 192.168.3.2:1 x.x.x.x:1 x.x.x.x:1
icmp y.y.y.y:2 192.168.3.2:2 x.x.x.x:2 x.x.x.x:2
icmp y.y.y.y:3 192.168.3.2:3 x.x.x.x:3 x.x.x.x:3
icmp y.y.y.y:4 192.168.3.2:4 x.x.x.x:4 x.x.x.x:4


The above show outputs (are taken from a router and not an ASA) show that the router is associating a port with each and every ping request packet so that it can reroute the replies .

I can not try it out with ASA`s right now, but will surely try this tomorrow and will let you know .

Thanks
Patiot

HI guys

Basically in a PIX environment, it stores each connection in memory, so an outbound connection based on ICMP will be stored in memory taged with the Protocol number (1 "icmp"), and the NAT/PAT id's ( port numbers)

Network Address Translation (NAT) performs translation service on any TCP/UDP traffic that does not carry source and/or destination IP addresses in the application data stream (ie: http, TFTP, telnet, archie, finger, NTP, NFS, rlogin, rsh, rcp).

ICMP Packets embed the source IP adderss in the payload, like FTP does, so the pix uses ALG.

Specific protocols that do embed IP address information within the payload require support of an application level gateway (ALG).

ICMP and PAT/Overloading Inside Address Scheme
While conducting Port Address Translation (PAT) for ICMP traffic, the sequential numbers are associated to ports. Following is an example of the transition table, assuming continuous the ping traffic from source to destination:
icmp w:0 x:0 y:0 z:0
icmp w:1 x:1 y:1 z:1
...
...
icmp w:65535 x:65535 y:65535 x:65535
If the traffic still sustains, then the ICMP sequential numbers will rollover and start from 0. Thus, NAT would not create any new translation for this source to destination traffic).

Basically the sequential ICMP packets are translated into port numbers, all this information is stored in the pix memory, enabling each packet to be redirected back to your client.

Hope this helps.

Thanks guys for the reply.

Basically the sequential ICMP packets are translated into port numbers, all this information is stored in the pix memory, enabling each packet to be redirected back to your client.

That explains allot, so it's all done by ICMP sequence numbers. Yes, I can see them while sniffing for ICMP. However, I don't see why they have to be mapped back to port numbers, ICMP packets simply don't have port fields. I think they are mapped back to the original ICMP sequence numbers they came by from the hosts. Not sure

icmp y.y.y.y:1 192.168.3.2:1 x.x.x.x:1 x.x.x.x:1
icmp y.y.y.y:2 192.168.3.2:2 x.x.x.x:2 x.x.x.x:2
icmp y.y.y.y:3 192.168.3.2:3 x.x.x.x:3 x.x.x.x:3
icmp y.y.y.y:4 192.168.3.2:4 x.x.x.x:4 x.x.x.x:4

Thanks Patiot, may be that confirms what ikon said about sequence numbers. If they were ports, I guess they should have began at least from 1024 and above to avoid the common ports. If you have any other findings, be my guest to share.

Yes I tired it today with the following configuration :

interface Ethernet0/0
nameif outside
security-level 0
ip address x.10.10.1 255.255.255.0
!
interface Ethernet0/1
nameif inside
security-level 100
ip address 10.10.10.1 255.255.255.0
global (outside) 1 interface
nat (inside) 1 10.10.10.0 255.255.255.0

And started pinging from 10.10.10.2 to x.10.10.2 and captured sh conn and sh xlate detail outputs which you can find below .

Answer :

asa# show conn
2 in use, 2 most used
ICMP out x.10.10.2:0 in 10.10.10.2:512 idle 0:00:00 bytes 32
ICMP out x.10.10.2:0 in 10.10.10.2:512 idle 0:00:00 bytes 32
ciscoasa# show conn
2 in use, 2 most used
ICMP out x.10.10.2:0 in 10.10.10.2:512 idle 0:00:00 bytes 96
ICMP out x.10.10.2:0 in 10.10.10.2:512 idle 0:00:00 bytes 96
ciscoasa# show conn
2 in use, 2 most used
ICMP out x.10.10.2:0 in 10.10.10.2:512 idle 0:00:00 bytes 128
ICMP out x.10.10.2:0 in 10.10.10.2:512 idle 0:00:00 bytes 128

ciscoasa# sh xlate detail
1 in use, 1 most used
Flags: D - DNS, d - dump, I - identity, i - dynamic, n - no random,
r - portmap, s - static
ICMP PAT from inside:10.10.10.2/512 to outside:x.10.10.1/6 flags ri

It seems that it is doing a translation and establishing a connection .

Thanks
Patiot

Thanks Patiot for the info. Yes indeed it seems it's doing some translation. May be the question that remains is what fields other than "port numbers" it's using in the IP/ICMP packets to do this translation. I think it is the "sequence numbers" as mentioned earlier. still not sure, may be I'll need to do some further sniffing to verify it.