×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

L2L VPN With One Side NAT - A Lesson Learned

Document

Fri, 06/08/2012 - 08:52
Apr 19th, 2012
User Badges:

We recently engaged with a third party vendor that required us to setup 3 L2L VPN connections from a single host on our network to 3 remote end hosts. Due to our internal private address space in use overlapping with their address space we had to NAT our host to a different private address. Normally this is relatively easy to configure but we encountered complications because our headend VPN firewall (ASA 5520) is also a VPN headend device for remote branch offices that connect from dynamic addresses with the added complexity of all internet browsing traffic has to go through the VPN tunnel. To accommodate this, we have a general NAT exemption rule configured as any/any.


We searched through many configuration examples but found most were based on an assumption the firewall configuration only implemented L2L VPNs with NAT or without NAT (NAT exemption). We had to figure out a hybrid of these scenarios and I thought I would share our findings that made this work.


The scenario:


  • We have a single ASA 5520 acting as our L2L VPN headend device at our headquarters
  • We have already established L2L VPN configurations to branch offices that the peer address is dynamic
  • We also have already established L2L VPN configurations for branch offices that the peer address is static
  • We needed to NAT a single host at our headquarters to a specific private IP in a VPN tunnel to a third party


The first thing that needs to be done is a No Exempt rule needed to be created to exclude the internal host from the NAT exemption when communicating with the third party hosts. The following config excerpts shows how this was accomplished. IP addresses  and specific names have been changed for obvious reasons .


! Setup third party addresses as a object group for easier reference

object-group network THIRD_PARTY

  description CompanyABC Remote Hosts

  network-object host 172.16.1.4

  network-object host 172.16.1.5

  network-object host 172.16.1.6


! Exclude the specifics for the third party connection from the NAT exemption rules

access-list inside_nat0_outbound extended deny ip host 10.1.1.10 object-group THIRD_PARTY

access-list inside_nat0_outbound extended permit ip 10.0.0.0 255.0.0.0 any


! Define the access-list for determining the static NAT

access-list inside_nat_static extended permit ip host 10.1.1.10 object-group THIRD_PARTY


! Define the 3 access-lists to be used in the 3 crypto maps

access-list outside_3_cryptomap extended permit ip host 172.16.1.2 host 172.16.1.4

access-list outside_4_cryptomap extended permit ip host 172.16.1.2 host 172.16.1.5

access-list outside_5_cryptomap extended permit ip host 172.16.1.2 host 172.16.1.6


! TURN ON NAT (Overlooked this one too many times ;-))

nat-control

! Apply the NAT exemption

nat (inside) 0 access-list inside_nat0_outbound

! Apply the static policy NAT

static (inside,outside) 172.16.1.2 access-list inside_nat_static


! Setup the crypto maps

crypto map outside_map 3 match address outside_3_cryptomap

crypto map outside_map 3 set pfs

crypto map outside_map 3 set peer 1.1.1.1

crypto map outside_map 3 set transform-set ESP-AES-256-SHA

crypto map outside_map 4 match address outside_4_cryptomap

crypto map outside_map 4 set pfs

crypto map outside_map 4 set peer 1.1.1.2

crypto map outside_map 4 set transform-set ESP-AES-256-SHA

crypto map outside_map 5 match address outside_5_cryptomap

crypto map outside_map 5 set pfs

crypto map outside_map 5 set peer 1.1.1.3

crypto map outside_map 5 set transform-set ESP-AES-256-SHA


! Finally setup the tunnel-groups

tunnel-group 1.1.1.1 type ipsec-l2l

tunnel-group 1.1.1.1 ipsec-attributes

pre-shared-key *

tunnel-group 1.1.1.2 type ipsec-l2l

tunnel-group 1.1.1.2 ipsec-attributes

pre-shared-key *

tunnel-group 1.1.1.3 type ipsec-l2l

tunnel-group 1.1.1.3 ipsec-attributes

pre-shared-key *


What we were originally missing and resulted in 4+ hours of troubleshooting was the exclusion of the specific host that require to be translated in the VPN tunnel to the third party company.


I hope this helps anyone facing a similar scenario. I know I wish I had found something defining this before we spun our wheels troubleshooting this.


Loading.
Azubuike Obiora Fri, 06/08/2012 - 08:52
User Badges:

Hi Doug,


Many thanks for sharing this information with the community, i really do find it way to intresting. Though i have never encountered such in my few years with setting up L2LVPN's at all. I have beeen blessed with just setting yup with vendors that have different RFC1918 address from my own end.


But who knows i might meet such scenario out there someday. Thanks once more for such detailed and vital information.


cheers

Teddy

Actions

This Document