ASA NAT issue

[dustin.kinn]

I have several NAT statements pointing External to Internal on an ASA.  When I do a packet-tracer, it appears that everything is working, but I can't get to it via the IP...

The command I ran was this:

#packet-tracer input outside icmp [MY IP] 0 8 [External NAT] detailed

The result I get is this:

 Forward Flow based lookup yields rule:
 in  id=0x7fffa3bca830, priority=66, domain=inspect-icmp-error, deny=false
        hits=1317, user_data=0x7fffa3bc9da0, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
        src ip/id=0.0.0.0, mask=0.0.0.0, icmp-type=0, tag=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, icmp-code=0, tag=0 dscp=0x0
        input_ifc=outside, output_ifc=any

Phase: 6
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:
 Forward Flow based lookup yields rule:
 in  id=0x7fffa59b5750, priority=13, domain=ipsec-tunnel-flow, deny=true
        hits=15711, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
        dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0 dscp=0x0
        input_ifc=outside, output_ifc=any

Phase: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network ftp2
 nat (inside,outside) static [External NAT IP]
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0x7fffa3cae3e0, priority=6, domain=nat-reverse, deny=false
        hits=342, user_data=0x7fffa3bf8cf0, cs_id=0x0, use_real_addr, flags=0x0, protocol=0
        src ip/id=0.0.0.0, mask=0.0.0.0, port=0, tag=0
        dst ip/id=[Internal NAT IP], mask=255.255.255.255, port=0, tag=0 dscp=0x0
        input_ifc=outside, output_ifc=inside

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?

I'm confused.

[ronbuchalski]

Dustin,

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.

-rb

[dustin.kinn]

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.

[Julio Carvajal · Accepted solution]

Glad to know that.

If it works please make sure you mark this question as answered so the discussion can be closed

Regards

[Julio Carvajal]

Hello,

There are certain settings on a server that will make it reachable from devices on the same subnet but not from other subnets (Host Based Firewall, Anti-Virus,etc).

Make sure that is disable and if that does not work then move forward to the next step which is ICMP Inspection is turned on on both firewalls

To add use fixup protocol icmp.

If that does not make a difference than run a packet capture on the inside interfaces of both firewalls

On your side

capture jcarvaja interface inside match icmp host Your_PC host _Remote_PC

cap asp type asp-drop all circular-buffer

On the other side

capture jcarvaja interface inside match icmp host Your_PC host Remote_PC

cap asp type asp-drop all circular-buffer

Then attempt to ping and provide

show cap capin (On both Firewalls)

show cap asp | include Your_IP (On both firewalls)

Regards,

Jcarvaja

[dustin.kinn]

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.

This place is in need of a network diagram badly.