Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements
Step-by-Step Configuration and Troubleshooting Best Practices for the NGFW, NGIPS and AMP Technologies A Visual Guide to the Cisco Firepower Threat Defense (FTD)

ASA Natting over VPN loses connection to management

All,

I have an ASA that I downgraded from 9.1(4) to 9.0(3) for the problem I'm about to describe, and it didn't fix it. Here's the deal:

 

I need to nat over a vpn tunnel. The tunnel works fine, but I cannot ping to/from my internal interface. The nat rule looks like this:

 

nat (inside,outside) source static LAN-VPN LAN-Translated destination static DSTNetwork DSTNetwork

 

object network LAN-VPN

subnet 10.20.1.0 255.255.255.0

object network LAN-Translated

subnet 10.40.1.0 255.255.255.0

 

The inside interface of the ASA is 10.20.1.1. When I ping anything across the vpn tunnel sourced from the inside interface, it times out. If I ping from a server to a server across the vpn, it works fine.

 

So, I've found route-lookup, but for every example I've found, they're not natting. Also, I can't enable it anyway because it throws an error due to the natting config:

ERROR: Option route-lookup is only allowed for static identity case

 

How can I enable communications to the inside interface over a natted vpn tunnel. Oh, I have management-access inside enabled already, so that's not it - along with the policy map to perform inspects.

Thanks!

John

HTH, John *** Please rate all useful posts ***
2 REPLIES
Hall of Fame Super Silver

 This generally doesn't work

 

This generally doesn't work because the rule processing for putting traffic into the VPN happens in part due to the access-list on the inside interface that's associated with the cryptomap for the site-site VPN. If the traffic is initiatied by the interface itself, the access-list never gets considered and thus the traffic is not encapsulated in IPsec and sent via the tunnel.

Marvin,Thanks for the reply.

Marvin,

Thanks for the reply. I'm not 100% certain that's what is going on though. I can change the acl to not nat over the tunnel, and it works fine. For example, my real subnet is 10.20.1.0/24, but while going over the vpn I nat to 10.40.1.0/24. If what you're saying was the issue, then technically it wouldn't work even when not natting, correct?

 

I resolved the issue by not natting, but this isn't a good solution. The problem is that we have a hosted solution for one of our applications. Our vpn sites use a 10.78.x.x/24 subnet whereas the hosted site also uses 10.78.x.x in some cases. We haven't had to yet, but there's the possibility of us standing up a site that they use in the same range, and we've been told that we're going to be the side that has to nat. One thought that I had was that I could nat when only going to that site, and that would very well fix the issue I believe, but if we were to nat everything, then that's going to cause us to not be able to ping the inside interface any longer. There was absolutely nothing that I could do to get this to work other than disabling nat across the tunnel completely.

The only thing that I didn't try was to create a host for my inside interface to do a 1-1 nat instead of relying on the subnet object to do the 1-1 nat for me. I don't know; I'm grasping at straws here...

 

Thanks!

John

HTH, John *** Please rate all useful posts ***
50
Views
5
Helpful
2
Replies
CreatePlease to create content