cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
617
Views
6
Helpful
13
Replies

L2L VPN: NAT solves return routing architecture for backup VPN?

 

Hello.

PROBLEM: Our primary ASA IPsec VPN is at one location, our backup ASA IPsec VPN is at a different location. When switching VPNs from primary to secondary, on both local and remote LANs there always exists an organic routing issue in which the return routes need to be changed from the primary tunnel source to the backup tunnel source.

It seems to me that this can be solved by adjusting the typical identity-NAT, so that 2 of the 4 fields are changed: Example...

TRUE local server= 172.16.0.1
NATED local server= 172.16.77.1

TRUE remote server= 10.0.0.1
NATTED remote server= 10.0.77.1
---

nat (inside,outside)
source static
my_enterprise_TRUE_endpoints my_enterprise_NATTED_endpoints
destination static
vendor_TRUE_endpoints vendor_NATTED_endpoints

QUESTIONWill above config work for both incoming and outgoing packets, so that the backup VPN is fully functional with no need to ever change return routing (after 1st installing all routes) ?

Thank you.

1 Accepted Solution

Accepted Solutions

@jmaxwellUSAF if traffic enters from the remote LAN as the source communicating with an IP address in your local LAN, then in the example above the source (remote LAN) is TRANSLATED-DST the destination (your local LAN) is TRANSLATED-SRC. Remember the NAT rules are bidirectional, in this instance the NAT rule was written from inside to outside, so the inside network (your local LAN) is ORIGINAL-SRC/TRANSLATED-SRC.

You can write the rules from outside to inside, you'd flip the source and destination networks.

View solution in original post

13 Replies 13

Ipsec redundacy using NATing I dont get it 

But you can use 

Crypto ipsec mhm seq 10 set peer x.x.x.x y.y.y.y

This give you auto failover within same crypto map seq.

No need NAT.

This is a return-routing issue.

Backup VPN device is at different location. Traffic returning through the backup tunnel needs a different destination IP address than the primary tunnel, because primary routing cannot dynamically change-- it points to the primary tunnel.

So it seems to me that NAT will solve this issue.

@jmaxwellUSAF please clarify, is the original source and original destination IP address the same when connecting to both the primary and secondary VPN peer? but the source and destination IP address are translated differently depending on when peer tunnel is established?

"is the original source and original destination IP address the same when connecting to both the primary and secondary VPN peer"-- yes. And our backup VPN tunnel source exists at a different location.

It seems to me that the NAT in my original post will solve this. What do you think?

@jmaxwellUSAF your initial question and responses are confusing, "And our backup VPN tunnel source exists at a different location" < do you mean you have a backup VPN tunnel on a different ASA (2 x ASA in total on different sites)? Or do you have 1 ASA with two VPN's to a partner (which has a primary and seconday VPN tunnels)?

Primary ASA at one location. Backup ASA at second location.

@jmaxwellUSAF ok well, yes you would create different NAT rules on each of your ASA to translate accordingly. E.g.

ASA Site 1

nat (INSIDE,OUTSIDE) source dynamic ORIG-SRC TRANS-SITE1 destination static ORIG-DST TRANS-DST-PRIMARY

ASA Site 2

nat (INSIDE,OUTSIDE) source dynamic ORIG-SRC TRANS-SITE2 destination static ORIG-DST TRANS-DST-BACKUP

 

I assume the crypto ACLs are already setup correctly based on the translated addresses?

Hi. I'm thinking all of our NAT statements are currently incorrect.

It seems to me the correct statements are...

ASA Site 1

nat (INSIDE,OUTSIDE) source dynamic ORIG-SRC TRANS-SITE1 destination static TRANS-DST-PRIMARY ORIG-DST

ASA Site 2

nat (INSIDE,OUTSIDE) source dynamic ORIG-SRC TRANS-SITE2 destination static TRANS-DST-BACKUP ORIG-DST 

Your thoughts?

@jmaxwellUSAF no, original is before translated.

nat (INSIDE,OUTSIDE) source static ORIGINAL-SRC TRANSLATE-SRC destination static ORIGINAL-DST TRANSLATED-DST

 

(I understand the ACL and routing implications.)

Now, if...

"nat (INSIDE,OUTSIDE) source static ORIGINAL-SRC TRANSLATE-SRC destination static ORIGINAL-DST TRANSLATED-DST"

...ok, traffic enters from remote LAN. Then the return traffic inside my local LAN will have a destination IP address of "TRANSLATED-DST", it enters the tunnel and then gets translated back to "ORIGINAL-DST"

Correct?

@jmaxwellUSAF if traffic enters from the remote LAN as the source communicating with an IP address in your local LAN, then in the example above the source (remote LAN) is TRANSLATED-DST the destination (your local LAN) is TRANSLATED-SRC. Remember the NAT rules are bidirectional, in this instance the NAT rule was written from inside to outside, so the inside network (your local LAN) is ORIGINAL-SRC/TRANSLATED-SRC.

You can write the rules from outside to inside, you'd flip the source and destination networks.

Hi.

In your below text, you use "dynamic" for the sources. Shouldn't this be "static"?

---

ASA Site 1

nat (INSIDE,OUTSIDE) source dynamic ORIG-SRC TRANS-SITE1 destination static ORIG-DST TRANS-DST-PRIMARY

ASA Site 2

nat (INSIDE,OUTSIDE) source dynamic ORIG-SRC TRANS-SITE2 destination static ORIG-DST TRANS-DST-BACKUP