I conducted the IP NAT overload experiment and then captured the packets before and after translation. The translated numbers are not sequence numbers but they are ICMP identifiers. In the below given output 5345, 5346, 5347 are actually identifiers. This identifier can be treated very much like the port numbers in TCP or UDP. For example if two inside PC generated same identifier and sequence number, then the NAT device will modify one of the identifier so that the reply can be associated back with the correct inside PC.
R1#show ip nat translations
Pro Inside global Inside local Outside local Outside global
icmp 10.0.0.1:5345 184.108.40.206:5345 10.0.0.2:5345 10.0.0.2:5345
icmp 10.0.0.1:5346 220.127.116.11:5346 10.0.0.2:5346 10.0.0.2:5346
icmp 10.0.0.1:5347 18.104.22.168:5347 10.0.0.2:5347 10.0.0.2:5347
icmp 10.0.0.1:5348 22.214.171.124:5348 10.0.0.2:5348 10.0.0.2:5348
icmp 10.0.0.1:5349 126.96.36.199:5349 10.0.0.2:5349 10.0.0.2:5349
Re: How NAT/PAT handles ping/icmp
11 years 4 months ago #27578
1024 was the identifier shown in the sniffer both inside and outside, and it's obviously shown above. However, I wasn't able to verify the case were 2 hosts send with the same inside identifiers. I did a test on it but the router on NAT never changed any identifier on the out side. They remained 1024 as shown above!!!. And by the way, those numbers between brackets are not the sequence numbers. I'm guessing I could not send the ICMP pings exactly at the same times. If I assume that it was depending on sequence number difference from the two hosts when the identifiers matched. Then this means the router would need to translate and store the "sequence number" in it's translations table along with the "identifier", which I doubt.