Bit of 'belt and braces' configuration planning.


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.


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.

REM DC                      xx                       HQ
           +---------------+                  x               +-----------+
           | REMOTE DC     |                 xx               |           |
           | ASA           e               xxx                | ASA 5505  |
+----------+               |              xx                  |           +-----------------+
   ^       |               e<-------------------------------------+       |
   |       |               |              xxxx                |           |
   |       |               e                 xxxx             |     ~     |
   |       |               |                    xx            |     |     |
   |       |               |                     xx           +----vpn----+
   |       |               |                      x                 |
           |               |                   xxx
           +---------------+                  xx
    e = public Internet                x
        server endpoint



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 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
interface Vlan2
 nameif outside
 security-level 0
 ip address

Cheers, Rob

  • It is not clear to me if you want to access to private addresses when the VPN is down. Mar 3, 2014 at 17:08
  • Can you provide a diagram of the connectivity? The solution we provide would likely depend on the specific layout and equipment. Mar 3, 2014 at 17:53
  • The so-called "protected" network is actually a public IP segment. It is firewalled but not NAT-ed. Ideally when the VPN is down, the public endpoints should still be accessible. Mar 3, 2014 at 18:56
  • 1
    A more precise ACL is probably your best bet. You could also create a GRE tunnel inside the VPN, but that would require more hardware. If you post more details about the ACL we can help. Maybe change the first two digits to protect the innocent?
    – Ron Trunk
    Mar 3, 2014 at 19:14
  • 1
    Rob, could you give us more of the ASA's configuration? Specifically, routing / interface configs would be useful to see Mar 4, 2014 at 10:12

2 Answers 2


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.

  • Thank you for following up... I hoped that we would find a solution with a dynamic routing protocol over ipsec; although I must confess that I dont have first hand experience with this solution. Mar 24, 2014 at 12:35

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.