Hot Downloads

×

Notice

The forum is in read only mode.
Welcome, Guest
Username: Password: Remember me
  • Page:
  • 1
  • 2

TOPIC: How NAT/PAT handles ping/icmp

Re: How NAT/PAT handles ping/icmp 10 years 6 months ago #27536

Yes Solo,I too agree upon that fact. It uses seq numbers .

I will also sniff the traffic if possible .

Thanks
Patiot

Re: How NAT/PAT handles ping/icmp 10 years 6 months ago #27553

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 12.0.0.2:5345 10.0.0.2:5345 10.0.0.2:5345
icmp 10.0.0.1:5346 12.0.0.2:5346 10.0.0.2:5346 10.0.0.2:5346
icmp 10.0.0.1:5347 12.0.0.2:5347 10.0.0.2:5347 10.0.0.2:5347
icmp 10.0.0.1:5348 12.0.0.2:5348 10.0.0.2:5348 10.0.0.2:5348
icmp 10.0.0.1:5349 12.0.0.2:5349 10.0.0.2:5349 10.0.0.2:5349

Re: How NAT/PAT handles ping/icmp 10 years 6 months ago #27578

  • S0lo
  • S0lo's Avatar Topic Author
  • Offline
  • Moderator
  • Moderator
  • Posts: 1577
  • Karma: 3
  • Thank you received: 7
Thanks ramhuliyar for your observation. I just checked it with a sniffer and indeed it seams that the "identifier" field that is being translated NOT the "sequence number".

[code:1]R3#debug ip nat det
IP NAT detailed debugging is on
R3#
00:23:04: NAT*: i: icmp (192.168.0.2, 1024) -> (172.16.1.1, 1024) [37792]
00:23:04: NAT*: s=192.168.0.2->172.16.1.10, d=172.16.1.1 [37792]
00:23:04: NAT*: o: icmp (172.16.1.1, 1024) -> (172.16.1.10, 1024) [514]
00:23:04: NAT*: s=172.16.1.1, d=172.16.1.10->192.168.0.2 [514]
00:23:05: NAT*: i: icmp (192.168.0.2, 1024) -> (172.16.1.1, 1024) [37796]
00:23:05: NAT*: s=192.168.0.2->172.16.1.10, d=172.16.1.1 [37796]
00:23:05: NAT*: o: icmp (172.16.1.1, 1024) -> (172.16.1.10, 1024) [515]
00:23:05: NAT*: s=172.16.1.1, d=172.16.1.10->192.168.0.2 [515]
00:23:06: NAT*: i: icmp (192.168.0.2, 1024) -> (172.16.1.1, 1024) [37810]
00:23:06: NAT*: s=192.168.0.2->172.16.1.10, d=172.16.1.1 [37810]
00:23:06: NAT*: o: icmp (172.16.1.1, 1024) -> (172.16.1.10, 1024) [516]
00:23:06: NAT*: s=172.16.1.1, d=172.16.1.10->192.168.0.2 [516][/code:1]

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.
Studying CCNP...

Ammar Muqaddas
Forum Moderator
www.firewall.cx
  • Page:
  • 1
  • 2
Time to create page: 0.101 seconds

CCENT/CCNA

Cisco Routers

  • SSL WebVPN
  • Securing Routers
  • Policy Based Routing
  • Router on-a-Stick

VPN Security

  • Understand DMVPN
  • GRE/IPSec Configuration
  • Site-to-Site IPSec VPN
  • IPSec Modes

Cisco Help

  • VPN Client Windows 8
  • VPN Client Windows 7
  • CCP Display Problem
  • Cisco Support App.

Windows 2012

  • New Features
  • Licensing
  • Hyper-V / VDI
  • Install Hyper-V

Linux

  • File Permissions
  • Webmin
  • Groups - Users
  • Samba Setup