VPN using outside ip with NAT

[Freddy Andersen]

I'm trying to setup a tunnel from our Cisco 5520 to a 5550 using one of our external ips natted through this tunnel. For some reason traffic that should hit this tunnel goes through global nat. Here is the configs I have for this tunnel:

access-list policy-nat extended permit ip host 66.77.88.170 host 1.2.3.4

access-list Outside_cryptomap_60 extended permit ip inside-network 255.255.254.0 host 1.2.3.4

access-list Outside_cryptomap_60 extended permit ip host 66.85.99.170 host 1.2.3.4

global (outside) 1 66.77.88.135 netmask 255.255.255.192

static (inside,outside) 66.77.88.170  access-list policy-nat

crypto ipsec transform-set TRANSFORM_SET esp-3des esp-md5-hmac

crypto map Outside_map 60 match address Outside_cryptomap_60

crypto map Outside_map 60 set peer 200.200.200.200

crypto map Outside_map 60 set transform-set TRANSFORM_SET

tunnel-group 200.200.200.200 type ipsec-l2l

tunnel-group 200.200.200.200 general-attributes

default-group-policy site2site

tunnel-group 200.200.200.200 ipsec-attributes

pre-shared-key *****

If I ping 1.2.3.4 from a inside ip host I see in the logs that it uses 66.77.88.136 as the NAT and not 66.77.88.170. Do you see something wrong with this configuration?

[Karsten Iwen]

I see two possible problems:

1) The host already has an xlate and so your new config isn't used until the xlate times out or you clear the translation of that host.

2) There are other translation-rules in your config with higher priority.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[abcdrohan · Accepted solution]

You basically have wrong acls in wrong places.

It should be as follows ---->

crypto map Outside_map 60 match address policy-nat

crypto map Outside_map 60 set peer 200.200.200.200

crypto map Outside_map 60 set transform-set TRANSFORM_SET

access-list policy-nat extended permit ip host 66.77.88.170 host 1.2.3.4

static (inside,outside)  66.77.88.170  access-list Outside_cryptomap_60

access-list Outside_cryptomap_60 extended permit ip inside-network 255.255.254.0 host 1.2.3.4 ---> this acl doesnt need the 2nd line you have
      

[Karsten Iwen]

good find! (5 Stars!). I completely overlooked that. But I wouldn't use the same ACL for policy-NAT and the crypto-definition. It's likely that these will be different sometime in the future for a "living" network.

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Freddy Andersen]

Great answer but the issue now is with the static since it will overlap my global nat...

fw(config#) static (inside,outside)  66.77.88.170  access-list Outside_cryptomap_60

global address overlaps with mask

[Freddy Andersen]

I added a direct static to one of my hosts on the internal-network

static (inside,outside) 66.77.88.170 10.21.31.87 netmask 255.255.255.255

and that now works fine. Tunnel got created and traffic is flowing, so i guess we are close. But what I want is the ability to have multiple hosts on our internal-network talk to this host through this tunnel. We have multiple vpn tunnels to different locations and we need all of our internal-network hosts to talk to all of the different tunnels. Is this possible? are we using the wrong strategy?

[Karsten Iwen · Accepted solution]

For that you should use dynamic policy-NAT. There you have the ACL in the "nat"-statement and reference the right natted IP in a global with the nat-id.

Sent from Cisco Technical Support iPad App

[Freddy Andersen]

I have this for nat now:

global (outside) 1 66.77.88.135 netmask 255.255.255.192

nat (inside) 0 access-list nonat10

nat (inside) 1 0.0.0.0 0.0.0.0

nat (mgmt) 0 access-list nonat10

nat (mgmt) 1 0.0.0.0 0.0.0.0

so will this be something like this:

nat (inside) 2 10.21.30.0 255.255.254.0

global (outside) 2 66.77.88.170

and then I just add nat (inside) 3 and 4 and 5 for each extra tunnel ? (with matching global)

[Freddy Andersen]

after some testing this works!

access-list Outside_cryptomap_60 extended permit ip inside-network 255.255.254.0 host 1.2.3.4

access-list policy-nat extended permit ip inside-network 255.255.254.0 host 1.2.3.4

global (outside) 2 66.77.88.170 netmask 255.255.255.0

nat (inside) 2 access-list Outside_cryptomap_60

crypto map Outside_map 60 match address policy-nat

Are there any recommendations for why we should not do this?

[Karsten Iwen]

I think there is something going wrong. First your config is a little bit confusing as you use an ACL with "policy-nat" in the name for crypto and an ACL with "crypto" in the name for policy-nat. Thats not a good naming-convention if you later start troubleshooting at 2:00am ...

But your policy-nat should work that way and your packets should get translated. But your crypto ACL ("policy-nat") matches on the traffic with the real IP and not with the translated IP. So the traffic should not be encrypted.

Your crypto-ACL has to be:

access-list policy-nat extended permit ip host 66.77.88.170 host 1.2.3.4

-- 
Don't stop after you've improved your network! Improve the world by lending money to the working poor:
http://www.kiva.org/invitedby/karsteni

[Freddy Andersen]

Thanks! I flipped the two access-list so that the outside 66.77.88.170 address is now in my Cryptomap and the internal-network subnet is in my policy-nat. My configuration now looks cleaner and most importantly; it works I'm going to add one more of these on a seperate ip like 66.77.88.171 and see if that works but I'm sure that will work at this point.