ASA VPN L2L - NATing inside host from private addr to a public addr for a Remote End Site

diggy · ‎06-03-2010

I know this is possible on our VPN3000. I do this for for a few remote sites. Basically we have an internal 172.16.x.x address we NAT to a publicly registered IP if the destination matches x.x.x.x/x.x.x.x. This makes it easy on the remote side as they don't have to worry about any overlaps since it is a registered IP that we own. The VPN 3000 will only NAT if the source on the remote/vendor side is X and the IP is the NAT address of Y. Basically a static policy NAT (I'm assuming this is the proper as they are all 1 to 1 NATs on the VPN 3000).

I've done polcy NATing on our FWSM's in situations where inside host(s) X on our network going out to remote host Y through the outisde (internet) interface, will NAT to publicly registered IP Z. This of course is to make it also easier on the remote sites end so they don't have to allow our full publically registered ranges that are part of a global pool, but just 1 address that PATs a specific set of our internal IPs for security sake. This setup on our FWSM does not go over a VPN, but is purely a plain TCP/IP connection over the Internet.

We are now deploying an ASA 5580 to replace the FWSM. A new VPN tunnel request has come in that will be temporary for testing till a dedicated frame link in put in place. I figured this is a good candidate for our first VPN tunnel on the ASA as it will eventually go if I don't configure it optimally. Basically use it as a sandbox.

This VPN L2L requires me to NAT one of our private IPs (I'll keep it to a static 1-1) on our end to one of our registered public IP's.

For the life of me, I'm having problems finding exacatly the right config on an ASA 5580 that would achive what we already do on our VPN3000's.

-----

I currently have a L2L tunnel configured going to my home Cisco 871 router. It's a simple L2L tunnel with private to private IP ranges as I can control both sides and don't need to worry about overlaps. I want to use this tunnel to test the setup. The current tunnel of course has a current NAT exemption rule, which I don't know if perhaps this is causing the issue, as the internal host privatly IP'd host on the 'work' side falls into this range. I'm starting to think that the exeption is being evaluated before the new test static 1-1, and hence the ASA will never actaully NAT it, as it will be evaualated by this ACL first (I kinda remember the evaluation chain in past reading being something like expemption, static, policy, global in that order of evaluation).

Anyway using hypothetical information is the following possible:

ASA v8.x

Current tunnel working L2L tunnel:

Protected Data - Normall NAT exemption

Remote cisco 871 - 192.168.255.0 255.255.255.0

Corporate ASA 5580 - 192.168.0.0 255.255.255.0, 172.16.0.0 255.240.0.0, 10.0.0.0 255.255.255.0

ASA outside interface is the VPN termination point.

On the ASA side I now want to add a NAT for that VPN traffic from 192.168.255.0 255.255.255.0 to 5.5.5.5 (5.5.5.5 being the hypothetical registered IP) so that when any traffic over the tunnel from 192.168.255.0 255.255.255.0 destined for 5.5.5.5 gets translated on the corporate (ASA) side to 172.16.1.1 on the inside interface.

Sorry, I know it was long winded, but I hope I answered any questions with this one post.

Gonna end it here, and hope it's clear enough, if not please ask, and I will try and answer anything that isn't clear.

diggy · ‎06-03-2010

I actaully figured it out...maybe this post got my brain back on track...

What I had to do was put in a NAT "NO-exemption" for 172.16.1.1. This precedes the the NAT exemption rule/acl that was already in place for the tunnel.

I already had a static 172.16.1.1 to 5.5.5.5 on the inside/outside, and this is also required, which I figured...but I removed that static just to test and indeed it broke it.

So for my post above, I needed to add a NAT-"NO" exemption so it would get passed/fall-through to the STATIC nat, which then allowed it to get proccessed by the already exhisting NAT-exemption acl which then allowed it to hit the crypto map.

Man, I know that Cisco is on the other end of things, but you would think they would of at least gotten something from their purchase of Altiga and how they "automagically" do exactly this instead of having to imagine an ambigous flow-chart in your mind...