S2S IPsec with translated source IPs

[jonathanbruck]

We have a client who requires a site-to-site IPsec tunnel but will not allow our private IPs across the tunnel:

"we do not allow private IP addresses across the tunnel so you will need to translate your source private IP addresses behind publicly routable IP addresses"

How can we set this up so all traffic crossing the VPN tunnel is NAT'd just like any other normal outbound connection (i.e., translated to WAN IP).

Here is an example config of what we have now, standard setup, which isn't working since we are not translating the way the customer is expecting:

object-group network customer-NETS

network-object host 145.118.20.84 (example)

x

x

nat (inside,any) source static prvt-lan-NET prvt-lan-NET destination static customer-NETS customer-NETS

access-list customer-VPN-ACL extended permit ip object prvt-lan-NET object-group customer-NETS

crypto map corp_map 4 match address customer-VPN-ACL

crypto map corp_map 4 set peer 145.118.20.84

crypto map corp_map 4 set ikev1 transform-set primaryset

tunnel-group 145.118.20.84 type ipsec-l2l

tunnel-group 145.118.20.84 ipsec-attributes

ikev1 pre-shared-key xxxxxxxx

Any help with this would be much appreciated!

[Karsten Iwen]

youo need to change two things:

1) your twice nat should translate your private ip to a public IP. The "any" could be changed to the outgoing interface.
2) The VPN-ACL has to use the translated public IP as the source address.

That will work because the traffic is NATed first, and the packet (with the new IP-address) is placed into the tunnel then.


Sent from Cisco Technical Support iPad App

[jonathanbruck]

If understand you correctly changes should look like this?

nat (inside,outside) source static prvt-lan-NET prvt-lan-NET destination static

access-list customer-VPN-ACL extended permit ip object object-group customer-NETS

Thanks for your help!!

[Jeet Kumar]

Hi Jonathan,

I have one question,are you trying to translate the private network into the outside interface of the ASA or to some other public IP.

Thanks

Jeet Kumar

[jonathanbruck]

Sorry I should have been clearer yes, the outside interface

[Jeet Kumar · Accepted solution]

Hi,

In that case you don't need to change anything in the NAT.

Make sure you do not have any NAT exempt configured.

In the crypto access-list source should be your outside ip and destination should be the private IP of the remote site. and on the remote site they should configure your outside IP address as the destination.

If you try the above i am sure you will face no issue.

Thanks

Jeet Kumar

[jonathanbruck]

Hi Jeet,

Thank you that worked splendidly.

[Jeet Kumar]

Thats Awsome.

Please accept it as solution so that other can use this as a reference and if you don't mind please rate the solution as well.

Thanks

Jeet

[Karsten Iwen]

no, it should look like the following:

nat (inside,outside) source dynamic prvt-lan-NET Your-Public-IP destination static customer-NETS customer-NETS

That will change your internal LAN to the public address when you communicate with customer-NETS

I wouldn't use the interface IP for this to avoid any potential conflict that could arise later.

access-list customer-VPN-ACL extended permit ip object Your-Public-IP object-group customer-NETS

With that only the translated packets are sent into the tunnel

-- 
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

[Jeet Kumar]

In My experience with VPN for the last 6 year i have not seen any issue if we use the outside IP in the crypto access-list.

The encryption will trigger only when the traffic is destined for the remote IP.

If you don't wanna use the outside IP thats a different thing. But if yuo have no option but to use teh outside IP that it will be defined in the crypto access-list and there shoudl be no nat exemt for the remote site.

Thanks

Jeet

[Karsten Iwen]

One problem comes when an internal user tries to initiate a remote-access VPN to the same destination. I had this several times and the config needed to be changed only because of this. It's the same reason that I don't like to translate the internal networks to the interface IP. If a different IP is used for this you won't run into trouble later. Of couse it's a complete different story if there is only one public IP ...

Same for translation rules. Also if there is a rule translating everything to the interface address I still would configure a dedicated NAT-exemption. Not because it's needed, just to have a hint that there is a depending function that relies on the translation but is not internet-traffic. Let's name it inline-documentation. And at least the next admin that has to work with the config next year will be happy that there is a hint that reduces the propability of mistakes.


Sent from Cisco Technical Support iPad App

[Jeet Kumar]

I am sorry,

I didn't see you already did