So I setup hair-pinning for customer.Need to hit public IP of inside server sourced from the inside. I then verify with a PING (public IP’s obfuscated)…
Looks good to me… So I open up a web-browser to browse to the server and it fails…
Hmmm… how is THAT possible?!?
So I load up Wireshark and to see what is happening on the wire. And the first thing I notice is that Wireshark sees the ECHO Requests and corresponding Replies as different conversations…
Independent ECHO Requests:
Independent ECHO Replies:
The above screen-shots show (2) different conversations. It is not supposed to look like that. It is supposed to look they are a part of the same conversations as seen below…
Inter-dependent ECHO Replies / Requests:
And then it hit me… how is it possible that the computer is displaying at the command-line successful replies when the corresponding ECHO Reply is being sourced from an IP that was not the original IP destined for in the PING Request?!?!
This is why… ICMP ECHO Requests ARE NOT “connection-oriented” like TCP packets. ICMP does not require acknowledgements. So basically the computer at the command line will show ECHO Replies all day long even if there is not an ECHO Request.
So then I realized that the Cisco ASA does not do an ICMP Redirect (which a router does do). In other words, I assumed because I was getting replies
that what was happening was the ASA was saying to the computer… “Yo… wait a minute… I’m going to re-direct you from the public IP you’re trying to talk to to the private IP you really need to talk to” and that is why successful ECHO Replies.
THIS IS NOT THE CASE. The reason why ECHO Replies is because ICMP is not a “connection-oriented” protocol like TCP and it will receive ECHO Replies all day long without corresponding ECHO Requests.
The solution to the problem was to delete a static route on the servers default-gateway (which was NOT the Firewall) because it was circumventing the Firewall and routing traffic to the client an alternate path.
No comments:
Post a Comment