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:

[M02@rt37]

Hello @NetworkingGeek1 

Routers do not perform strict checks on ICMP source and destination IP addresses in the same way that an end-host operating system might.

Ping Request -- Router 1 sends a ping request to 172.16.1.1 (Router 2) through the NAT router.

NAT Translation -- The NAT router translates the source IP of the ping request from 192.168.1.2 to its own interface IP, 192.168.1.1, as it exits the network towards Router 2.

Ping Reply -- Router 2 receives the ping request with a source IP of 192.168.1.1 and sends the ping reply back to this source IP.

NAT Translation on Reply -- The NAT router translates the destination IP of the ping reply from 192.168.1.1 to 192.168.1.2 as it enters the network towards Router 1.

Router 1 accepts the ping reply because it is expecting a reply from the destination IP 172.16.1.1. Routers often do not perform strict source IP checks on ICMP replies.

End-host operating systems, on the other hand, might be more strict in validating ICMP replies. When the Windows system receives a ping reply with a source IP different from the destination IP it sent the request to, it may interpret it as an irregularity and display a timeout.

[NetworkingGeek1]

M02@rt37  Hello,

Thank you for the reply. Small correction:

"Ping Request -- Router 1 sends a ping request to 172.16.1.1 (Router 2) through the NAT router.
NAT Translation -- The NAT router translates the source IP of the ping request from 192.168.1.2 to its own interface IP, 192.168.1.1, as it exits the network towards Router 2."
- NAT Router's interface facing Router 1 has IP address 192.168.1.1 and it's configured as IP nat outside, so ping request packets arriving from Router 1 to NAT Router will not be translated and they'll arrive to Router 2 with original source and destination. In other hand, ping reply packets from Router 2 to Router 1 will be translated. Because they first arrive to NAT Router's interface (which is between Router 2 and NAT Router) which is configured as IP nat inside and will be forwarded out of NAT Router's interface (which is between NAT Router and Router 1) which is configured as IP nat outside.

Can you please share with any source where did you find information that Routers often do not perform strict source IP checks on ICMP replies? Maybe some article on Cisco's website?

[NetworkingGeek1]

M02@rt37  Hello. Looks like, only you understood my question correctly so far. Thank you so much for this. Could you please provide me any source, preferably from Cisco articles, that "Routers do not perform strict checks on ICMP source and destination IP addresses".

[Richard Burts]

I believe that there is a flaw in your assumption that the source address of the response to a ping should be the address used as destination in the request. Let me suggest a simple example. Let us assume that R2 has interface G0/0 using 172.16.2.2 as its address. Let us also assume that R1 has sent a ping to 172.16.2.2. R2 receives the ping request and generates a ping response. For the response the source address will be the IP address of the outbound interface, which is G0/1 172.16.1.1. So R1 will receive the ping response with source 172.16.1.1. This is a correct response from the correct device (so is quite valid) but the source of the response does not match the destination of the request - and it should not be a problem.

[NetworkingGeek1]

@Richard Burts  Hello. Thank you for the reply.

1. I already tested scenario you provided and in that case R2 will reply to R1 with ping with source 172.16.2.2, not with address of outbound interface. Even more, you can ping loopback interface of R2 and reply will be with source IP address of that loopback. In that case it doesn't matter what is the address of outbound interface, source IP address of the ping reply will be the address which was the destination address of ping request.

2. Why do you think there is a flaw in my assumption? My logic is quite simple: if source IP is not checked, it means there is no way device would know that reply came from correct device. How would device know that ping reply came from correct device without checking source IP address of the ping reply?

3. I checked the same scenario on Windows and in that case if Windows receives ping reply with source IP address different than destination IP of ping request, then ping fails with timeout and this is exactly behavior I expect. I checked Linux and it accepts such pings the same as Cisco IOS does.

[paul driver]

Hello

---

@NetworkingGeek1 wrote:

interface of NAT Router facing Router 1 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 insid

---

NAT used to "hide" networks so the your destination address may/may not become of a source of reply
Can you share a topology of this, you explanation isn't clear to understand

[NetworkingGeek1]

@paul driver  Hello. Thanks for the reply.

Please check screenshot with topology below. Router1 pings 172.16.1.1 which is interface of Router 2 and Router 2 is behind NAT Router. In the result, Router1 instead of receiving ping reply with the source IP: 172.16.1.1 (IP address of the Router 2 interface), receives ping reply with source IP: 192.168.1.1 (IP address of the NAT Router interface). And Router 1 considers this ping as successful, so my question is, how come Router 1 accept this ping reply with the different source IP, than destination IP of original ping request it sent? Why it consider it as successful? Cisco IOS doesn't check if ping reply was received from the same IP which was used as destination IP for ping request? By the way, I checked it in wireshark (screenshot attached in my first post here) and it's seen that destination IP of the ping request is different from source IP of ping reply.

[MHM Cisco World]

there is asymmetric routing 
so the Outbound NATing 
the Inbound not UnNAting 
it routing issue

do traceroute and see how many first hops you have

MHM

[MHM Cisco World]

I forget bypass my answer.

MHM

[paul driver]

Hello

---

@MHM Cisco World wrote:

there is asymmetric routing 
so the Outbound NATing 
the Inbound not UnNAting 
it routing issue

---

Why is this is a routing issue?

[MHM Cisco World]

Why we use ip nat inside and ip nat outside 

To make NAT detect ingress abd egress of packet which effect by routing.

@paul driver for this issue any Q send it me directly.

MHM

[NetworkingGeek1]

@paul driver  please ignore his statement. There is no any issue with routing or NAT here. Above I replied you with my question.

[paul driver]

Hello
I assume here RTR1 has a route in its rib for 172.16.1.1 pointing towards NAT rtr2 and 172.16.1.1 is Hidden behind nat rtr2?

So when a ping is initiated from rtr1 it route lookup and forwarding sends ICMP for 172.16.1.1 towards RTR2 , RTR2 will first perform NAT if required on it wan interface before any route lookup for 172.16.1.1, then it will route towards 172.16.1.1

For the reply from rtr2, a route lookup is performed for 192.168,2 send to rtr2 wan interface where NAT is again performed   sip=172.16.1.1->192.168.1.1, dip=192.168.1.2

So from rtr1 perspective it will only see the reply from rtr2 WAN facing interface(192.168.1.1), if you were not performing nat for 172.16.1.1 then the reply from rtr 2 will be sourced from 172.16.1.1

[NetworkingGeek1]

@paul driver  Hello. Yes, RTR1 has a route to 172.16.1.1. But my question is not about routing here or NAT here. From routing point of view there are no surprises for me. 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? @paul driver  please check reply from  M02@rt37  he understood my question correctly, please check his reply and you'll understand what is my question about.