IOS to ASA dynamic and static VPNs - sharing same crypto ACL?

Question

Is it possible to have a dynamic and static VPN between the same IOS router and ASA, sharing same interesting traffic/crypto ACL on the ASA end? The two devices in question:

• ASA 9.1 - hub/termination point for VPNs
• 897 15.4 - spoke/branch office

The 897 IOS router has two links for internet connectivity:

• Primary link: static IP 2.2.2.2, ATM0 tied to Dialer2 (default route injected via 'ppp ipcp route default', static AD 1)
• Backup link: dynamic IP, Cell0 tied to Dialer1 (floating static default route with AD 200 for when ATM0/Dialer2 interfaces go down)

There is a single network - 10.1.30.0/24 at the branch office. A static L2L VPN (2.2.2.2 for examples sake) is configured over ATM0 link to the ASA and is working successfully. In the event this link/tunnel goes down I want the branch office to maintain reachability back to our corporate networks via the dynamic VPN tunnel over the Cellular 4G backup link.

Currently both the static and dynamic VPN's have identical local and remote networks in their crypto ACL's.

Relevant ASA configuration:

crypto dynamic-map BACKUPCELL 16 match address CRYPTOACL_CELL
crypto dynamic-map BACKUPCELL 16 set pfs group5
crypto dynamic-map BACKUPCELL 16 set ikev1 transform-set ESP-AES-256-SHA
crypto dynamic-map BACKUPCELL 16 set reverse-route
"
crypto map outside_map 11 match address CRYPTOACL_ATM
crypto map outside_map 11 set pfs group5
crypto map outside_map 11 set peer 2.2.2.2
crypto map outside_map 11 set ikev1 transform-set ESP-AES-256-SHA
crypto map outside_map 11 set reverse-route
"
crypto map outside_map 16 ipsec-isakmp dynamic BACKUPCELL

access-list CRYPTOACL_ATM extended permit ip any4 object 10.1.30.0_24 
access-list CRYPTOACL_CELL extended permit ip any4 object 10.1.30.0_24 

The issue I am facing when attempting to test a failover scenario by dropping the ATM0 link on the 897, 'show crypto ipsec sa' on the ASA shows decrypts but no encrypts (packet-tracer shows a DROP on ENCRYPT phase). It appears even with the static peer down, when evaluating the ASA's crypto map sequence it is stopping at the CRYPTOACL_ATM match for the static peer.

If I modify the ASA's CRYPTOACL_ATM to be something else specific, causing the CRYPTOACL_CELL to be matched it works successfully. It's not feasible as the branch office will need to access all networks over it's Cell0 link if ATM0 goes down.

Is there a possible solution with this topology and policy based VPN's on ASAs? (That doesn't involve a second ASA head end, or replacing it with something that supports route based VPNs.)

Thank you in advance.

Answer 1

When the ASA attempts to send traffic out an interface where a crypto map is applied, it will always process the crypto map from top-down, looking for the first match. Therefore, it will always match sequence 11, and never sequence 16. So the behavior you describe above is normal.

One correct way to do this would be to build GRE tunnels with routers, where you can run a dynamic routing protocol to determine the health of the paths. Then, you can wrap the GRE tunnels in IPSec for security. However, you said replacing the hardware is not an option. SDWAN is also another correct solution for this.

But, here's an idea for you, though. If the headquarters never initiates traffic to the remote site (or can withstand an outage when the primary tunnel goes down), you could set it up where the 897 performs NAT on the traffic when it leaves the cellular interface, so that it appears to the HQ that it's a different site. The ASA would then see this "new" site as attached to crypto map sequence 16, instead of 11. This would allow the remote site to maintain connectivity during an outage, but its source addresses would be translated. Then, when the primary internet comes back up, the 897 fails back to the primary path, to the primary tunnel, and to the primary address space. It's a bandaid, but it's an option.