Cisco IPSec Site-to-site VPN. Permit traffic if VPN is down

Question

Bit of 'belt and braces' configuration planning.

Background:

We have a successful site-to-site VPN link to our remote datacenter.

The remote 'protected' network is also the IP network range that is opened up through the firewall as Internet facing endpoints.

Thus: We use the VPN so we can access non-public endpoints.

Problem Statement:

If the VPN link is down, the ASA drops the traffic, even though the Internet endpoints should still be available through the remote firewall.

Question:

How can I configure the VPN to 'pass' the traffic as regular outgoing traffic, when the VPN is down.

Here is the pertinent segments of the config.

crypto map vpn-crypto-map 20 match address remdc-vpn-acl
crypto map vpn-crypto-map 20 set peer a.b.c.d 
crypto map vpn-crypto-map 20 set transform-set remdc-ipsec-proposal-set
crypto map vpn-crypto-map interface outside

The ACL for matching traffic is very primitive: it specifies the two networks, private and remote, expressed as network objects.

access-list remdc-vpn-acl extended permit ip object <private> object <remote> log 

And a primitive diagram.

                                     INTERNET
                                                x
                                                x
REM DC 203.000.113.000/24                      xx                       HQ 192.168.001.000/24
                                               x
           +---------------+                  x               +-----------+
           | REMOTE DC     |                 xx               |           |
           | ASA           e               xxx                | ASA 5505  |
+----------+               |              xx                  |           +-----------------+
   ^       |               e<-------------------------------------+       |
   |       |               |              xxxx                |           |
   |       |               e                 xxxx             |     ~     |
   |       |               |                    xx            |     |     |
   |       |               |                     xx           +----vpn----+
   |       |               |                      x                 |
   \-------vpn-------------vpn--------------------------------------/
           |               |                   xxx
           +---------------+                  xx
                                           xxx
                                          xx
                                       xxxx
    e = public Internet                x
        server endpoint

Thanks

Rob

Update 01

A more precise ACL has been discussed in the comments below (with thanks)

I can envisage two ACLS. (A) which permits ALL to the remote net, and then denies endpoints that are already available over the Internet. and (B) which opens up just the management/instrumentation as required.

The problem with (B) is that expressesing endpoints such as WMI & Windows RPC is impractical without tweaking standard server conf)

So, maybe (A) is the best approach which becomes an inverse of the remote firewall config.

Update 02

Mike has asked to see more of the ASA's ios configuration.

What follows is for the HQ ASA which is at the HQ site. The remote DC one is under the control of the data center provider, and so I can't comment on exactly how that may be configured.

Well, there isn't much to show: There is one default route to the Internet gateway, and no other specific routes.

route outside 0.0.0.0 0.0.0.0 HQInetGateway 1

Interfaces are very basic. Only basic IPv4 config and vlans to split the group into 1 outside interface and 1 inside interface.

interface Vlan1
 nameif inside
 security-level 100
 ip address 10.30.2.5 255.255.255.0
!
interface Vlan2
 nameif outside
 security-level 0
 ip address 194.28.139.162 255.255.255.0
!

Cheers, Rob

Answer 1

I'm now of the opinion that this isn't practical; at least in our particular scenario.

The scheme is further complicated by the fact that traffic "to tunnel" is selected by ACL between HQ and RemoteDC, (and so we can make it as complicated as we want), but on the reverse "path" (so to speak) the VPN concentrator at the remote end is selecting the whole HQ network as the protected network.

The upshot is that these don't balance and it appears that the forward and reverse xlates don't match. Similar to having forward and reverse routes that cause traffic to fail because NAT is at play at some point.

Essentially - this is being scrapped as "too high technical risk" and requires much more evaluation and possibly more control over the remote end before it becomes a solution.

Thanks to all who looked over this.

Answer 2

If you have or can install a router on the inside of each ASA you could create an encrypted GRE tunnel and either use routing or a floating static to fail to the Internet.