Ping reply from different source than ping request was sent to.

[NetworkingGeek1]

Hello Community,

Recently I faced interesting behavior of Cisco's routers and switches. I was playing with NAT configuration and just accidently observed situation when ping reply was with the different source IP address than the destination IP of ping request and Cisco device accept it as a reply. I checked it on both Router (different virtual Cisco routers) and Switch (physical Cisco switch catalyst 1000). Let me explain you the topology:

Router 1 -> NAT Router -> Router 2. Let's assume that ip address of interface of Router 1 facing NAT Router is: 192.168.1.2 and IP address of interface of NAT Router facing Router 1 is: 192.168.1.1. So, all packets which are coming out from of that interface of NAT Router will have source IP which is 192.168.1.1. Interface of Router 2 facing NAT Router has IP address: 172.16.1.1
Interface of NAT Router facing Router 1 is NAT outside and Interface of NAT Router facing Router 2 is NAT inside.

I configured default static routes on Router1 and on Router2 towards NAT Router. Then I did ping to 172.16.1.1 from Router 1 and it worked, even though it's clearly seen in wireshark that ping reply has different source IP than destination IP of original ping request:
source IP: 192.168.1.2 
destination IP: 172.16.1.1
and ping reply has:
source IP: 192.168.1.1
destination IP: 192.168.1.2 

Could you please explain how is possible that Router accept ping reply with the different source IP address than destination IP of the original ping request? Is there any check which Cisco IOS do on ICMP source / destination IP if they're correct? From my point of view, in this case ping should have been failed with timeout. By the way, I checked the same on Windows and behavior was as expected, ping request time out.

Please see screenshot from Wireshark:

[paul driver]

Hello

---

@NetworkingGeek1 wrote:

 From my point of view, such ping should have been failed, but it's actually succeed.

so ping request packets arriving from Router 1 to NAT Router will not be translated and they'll arrive to Router 2

---

What makes you think it should have failed, it will only have failed, If the host (172.16.1.1) wasn't reachable or the routing wasn't correct and in both cases these were okay and the host did indeed reply but the nat rtr2 changes the source of packet before it sent back to rtr1, from rtr1 perspective it doesn't care, it received it a reply from the host it attempted to reach.

As stated If you removed any advertisement of 172.16.1.1 from rtr 1 perspective then it would have failed naturally as it would have no idea how to route to it.

Alternately if your nat was (static/fullcone) and rtr1 ping rtr2 wan interface then host 172.16.1.1 will be the one to reply be it by rtr2 wan interface, again rtr1 doesn't care it received a reply from the host.

---

@NetworkingGeek1 wrote:

where did you find information that Routers often do not perform strict source IP checks

---

To negate spoofing( ip or otherwise) then there are lots of material you can find online

[NetworkingGeek1]

@paul driver    Hello

"What makes you think it should have failed, it will only have failed, If the host (172.16.1.1) wasn't reachable or the routing wasn't correct and in both cases these were okay and the host did indeed reply but the nat rtr2 changes the source of packet before it sent back to rtr1, from rtr1 perspective it doesn't care, it received it a reply from the host it attempted to reach." - That's the thing, RTR1 sent request to one IP address and received reply from another IP address, so in fact, from RTR1 point of view it didn't receive it a reply from the host it attempted to reach. There is no way that RTR1 knows that there NAT router in between RTR1 and RTR2, so from RTR1 perspective it pings 172.16.1.1 and is expecting to receive reply from the same source.

Please, forget about routing and NAT here, it's configured correctly. I used NAT in this topology only to simulate situation when Cisco devices receive ping reply with the source IP which is different from destination IP of the original ping request, I wanted to see how Cisco IOS would react. From my point of view, such ping should have been failed, but it's actually succeed. My only question is, how it's possible that RTR1 accepts ping reply with the source IP which is different from destination IP of the original ping request? Cisco IOS doesn't check source IP of ping reply?

"To negate spoofing( ip or otherwise) then there are lots of material you can find online" - so, it means that to negate spoofing it actually should perform strict source IP checks. Please send me any article where it's stated that Cisco IOS doesn't check source IP of ping.