11-20-2023 09:24 AM - edited 11-20-2023 11:54 AM
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
QUESTION: Will 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.
Solved! Go to Solution.
11-20-2023 12:48 PM
@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.
11-20-2023 09:38 AM
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.
11-20-2023 09:46 AM
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.
11-20-2023 11:15 AM
@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?
11-20-2023 11:41 AM
"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?
11-20-2023 11:48 AM
@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)?
11-20-2023 11:51 AM
Primary ASA at one location. Backup ASA at second location.
11-20-2023 11:57 AM
@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?
11-20-2023 12:16 PM
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?
11-20-2023 12:20 PM
@jmaxwellUSAF no, original is before translated.
nat (INSIDE,OUTSIDE) source static ORIGINAL-SRC TRANSLATE-SRC destination static ORIGINAL-DST TRANSLATED-DST
11-20-2023 12:38 PM
(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?
11-20-2023 12:48 PM
@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.
11-20-2023 01:57 PM
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
11-21-2023 12:13 AM
@jmaxwellUSAF yes static
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: