VPN trafic does not hit cryptomap

[Svetoslav Chinkov]

Hello All,

I am new to security and need help figuring out the following issue. I have a site to site VPN. All remote subnets are reachable over the VPN except 192.168.0.0/24 - 401_Data when sourced from 192.168.9.0 GPS-Secure. I suspect the issue is with NAT or the cryptomap ACL. I am attaching the ASA configuration, portion of show access-list and a packet trace. Please let me know if you notice anything I missed.

Thank You

[Francesco Molino]

Hi 

The config looks like correct. Your packet-tracer doesn't have a destination ip in the subnet that's not working 192.168.0.0/24.

Can you redo it please? 

I've made a document to ensure the traffic is passing through the vpn on your side:

https://supportforums.cisco.com/document/13299206/asa-how-troubleshoot-vpn-l2l-ensure-traffic-passing-through-vpn

Can you follow it please and paste your output on a text file? 

The issue can be on the other side. 

Thanks

PS: Please don't forget to rate and mark as correct answer if this answered your question. 

[Svetoslav Chinkov]

Thank You for your reply Francesco. I fat fingered the destination subnet in the packet tracer file above. Attached is the correct packet trace. I think the problem is identified in phase 4 (192.168.9.0/24 is dynamically NATed, instead of tunneled in over the VPN). After I created the discussion, I took pakcet captures that showed the same  result, however I believe my NAT statements and the NAT order is correct?

Also, show crypto ipsec sa does not display any security associations between 192.168.9.0/24 and 192.168.0.0/24.

P.S. - I found your troubleshooting document extremely helpful and I will be using it in the future.

[Francesco Molino]

Now with this capture is clear. I'm sorry I didn't pay attention to your interfaces. The subnet 192.168.9.0 isn't part of your inside but had its own interface on the asa. 

You have this nat statement in place and  you need the same one for your interface OSK-Secured. 

nat (inside,outside) source static DM_INLINE_NETWORK_3 DM_INLINE_NETWORK_3 destination static DM_INLINE_NETWORK_4 DM_INLINE_NETWORK_4 no-proxy-arp route-lookup

For simplicity copy paste this one and change inside by OSK-Secured. 

Thanks 

PS: Please don't forget to rate and mark as correct answer if this answered your question 

[Svetoslav Chinkov]

Francesco, once again thank you for your help.

When I first started troubleshooting this issue I added a NAT statement similar to the one you suggested, however it did not help. Attached are the current modify configuration, the output of packet tracer, show crypto ipsec sa and sh asp table vpn-context detail. I can see that interesting traffic is now being unNATed. Following your troubleshooting document I can see that the current user_data value and the SPI values do not match, however I do not understand why. FYI - there is only one configured l2l tunnel on that firewall.

Could you please take a look at the attached files and let me know what I am missing?

[Francesco Molino]

Hi

Most of the time this error means an issue with crypto ACL. Have you validated with the end peer that it has the mirror of your acl?

Thanks

[Svetoslav Chinkov]

Yes, I did. The best I can tell they match - however I am not sure if ACL statements were enter in the configuration in the order they are displayed or if that is just how the device sorts out the output when the running config is displayed. Please feel free to take a look at the attached file.

Thanks

[Francesco Molino · Accepted solution]

You're managing both ASA?

If Yes, can you adapt your ACL to the other end with same object groups and members?

If Not, replicate the other end acl on your side.

What are the ASA versions on both end?

EDIT:  on your crypto ipsec we don't see this subnet part of the tunnel. After doing the below modification. Can you run a ping from a host in the 192.168.9.0/24 subnet to your peer 192.168.0.0/24 subnet ? While the ping is running, could you do a sh crypt ipsec sa peer x.x.x.x (public IP of the other end ASA) and verify if you see traffic encaps.

Thanks

[Svetoslav Chinkov]

Francesco, sorry I was not able to post sooner. Both firewalls are managed by me. I will try your suggestion on the weekend and see if that helps.

The ASA versions are as follows:

Local: ASA5520 - 9.1(6)

Remote: ASA5515X - 9.7(1)

Thanks

[Francesco Molino]

Ok let me know as soon as you did the change. don't forget to clear your crypto ipsec to force it to be rebuilt

[Svetoslav Chinkov]

Hi Francesco,

Modifying both ends of the VPN tunnel with the mirrored crypto ACL worked.

Thank You for helping me solve this issue.

[Francesco Molino]

you're welcome