Phase: 8 Type: FLOW-CREATION Subtype: Result: ALLOW Config: Additional Information: New flow created with id 37844, packet dispatched to next module Module information for forward flow ... snp_fp_tracer_drop snp_fp_inspect_ip_options snp_fp_translate snp_fp_adjacency snp_fp_fragment snp_ifc_stat
Module information for reverse flow ...
Result: input-interface: outside input-status: up input-line-status: up output-interface: inside output-status: up output-line-status: up Action: allow
However, my ping from my windows machine (the same IP I'm using in my packet-tracer, btw) yields "request timed out."
I know the device on the other side is pingable, because you can do it from their other ASA on a different external IP. Could it be routing to the other firewall on the return route? Why would it act successful on the new ASA side?
The packet tracer information tells you that the path from Outside to Inside is working. However, it does not check or verify that the path from Inside to Outside is also working for ICMP, and it would need to be working in order for your ICMP echo-reply to reach the sending host on the Outside.
Check your Outside and Inside ACLs to see if they allow ICMP, and compare them to the ACLs on the firewall that you said allows ICMP to successfully ping the inside host from the outside.
Thanks for the reply. The ACLs are exactly the same on both ASAs, except the IPs are changed. That's why I'm thinking a routing problem. I'm speculating that perhaps the ICMP is returning to the current ASA on the out-route, rather than my new one. But the default route for the network goes to the main gateway, so I'm not sure why that would happen. My only thought there is that the default route is the old ASA's network, whereas the new ASA exists on a different subnet (even though the gateway resides on the same core switch).
Tonight, I'm changing the default route for a bit as a test, and anything pointing to the old ASA is getting redirected to the new as well. Then it will go right back, but hopefully the test is successful.
It ended up being routing on the core switch. I had thought they were routing to an interface that existed on their core for the default route, but instead, they were routing to a separate router for an MPLS connection that hosted like 5 of their 20 subnets. That router happened to be on the same subnet as the old ASA, so it was able to thankfully find its way back to the original FW.
Changed that default route to my new ASA and added the routes for the MPLS nets to go to the MPLS router and everything worked.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
[toc:faq]Introduction:This document describes details on how NAT-T
works.Background:ESP encrypts all critical information, encapsulating
the entire inner TCP/UDP datagram within an ESP header. ESP is an IP
protocol in the same sense that TCP and UDP are I...