09-05-2013 01:27 PM - edited 02-21-2020 07:07 PM
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!
Solved! Go to Solution.
09-05-2013 02:32 PM
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
09-05-2013 01:35 PM
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
09-05-2013 02:12 PM
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
Thanks for your help!!
09-05-2013 02:20 PM
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
09-05-2013 02:27 PM
Sorry I should have been clearer yes, the outside interface
09-05-2013 02:32 PM
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
09-05-2013 04:05 PM
Hi Jeet,
Thank you that worked splendidly.
09-05-2013 04:14 PM
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
09-05-2013 02:43 PM
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
09-05-2013 02:49 PM
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
09-06-2013 05:06 AM
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
09-05-2013 04:15 PM
I am sorry,
I didn't see you already did
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide