I have an odd situation 10.50.50.25 --- |Svr02| --- 10.50.50.26 10.50.50.16 --- |Srv01| --- 10.50.50.15 When I ping 10.50.50.25 and 10.50.50.26 from Srv01 I can see the echo requests and echo replies are received and the pings report as successful. When I ping 10.50.50.16 and 10.50.50.15 from Srv02 only 10.50.50.16 sends the echo replies. When doing a wireshark trace I can see the failing ping request from Srv02 goes like this
Why could this be? asked 09 Nov '15, 10:47 wshark_man_123 edited 09 Nov '15, 12:29 |
One Answer:
You haven't stated whether the icmp echo requests from Srv01 are sent from 10.50.50.15 or 10.50.50.16. I would suspect some firewall to block icmp on the 10.50.50.15 interface of srv01. What happens if you shut down 10.50.50.16 and try to ping 10.50.50.15 from Srv02? answered 09 Nov '15, 12:47 sindy |
I can see Windows Firewall drops inbound for the failed pings which is why no echo reply is being generated.
Hint: If a supplied answer resolves your question can you please "accept" it by clicking the checkmark icon next to it. This highlights good answers for the benefit of subsequent users with the same or similar questions. For extra points you can up vote the answer (thumb up).
So my assumption was correct and according to the principles of the site you should mark my answer as correct/helpful.
If the behaviour seems weird to you: libpcap (Wireshark) is hooked as close as possible to the hardware so it gets any incoming packet before the Windows firewall. So you can see incoming packets dropped by the firewall in the capture but they don't reach higher levels of the protocol stack because the firewall drops them. For sent packets, however, the same arrangement means that if an application sends a packet but the firewall drops it, the packet does not reach libpcap and so you won't see it in the capture. This would hardly happen in case of icmp but it does happen for application protocols.