Full mesh VPN and routing

Unanswered Question
Apr 27th, 2007

Bit of a head scratch..

I have 4 remote sites all connected in a full mesh. all sites terminate on a ASA and I am setting up IPSEC vpn tunnels between all for security. Now my question any idea how to handle when one link goes down to now send the traffic down a different tunnel. IE if i was going from A to B site and the link went down now send the traffic to B via C?? any suggestions would be appreciated

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
mark.j.hodge Fri, 04/27/2007 - 06:12

As I understand your question, you have 4 sites, A, B, C & D. Each Site is connected to the other three through an IPSEC tunnel.

If tunnel A <-> B fails, you want to route via A <-> C <-> B, or A <-> D <-> B.


If tunnel A <-> B fails, the chances are it is due to ISP / Intenet failure at one of the sites, so all three tunnels will fail at the same time.

As the IPSEC tunnel forwards traffic bassed on an access-list which determines "interesting traffic", I don't believe you can do this with just the ASA devices.

The only thing I can suggest is that you place a Layer 3 routing device on each site behind the ASA, on the Inside network. If you then run a GRE tunnel through the IPSEC tunnel to each site, you should be able to run some sort of dynamic routing protocol.

gabrielbryson Fri, 04/27/2007 - 06:25

HI Mark

Each sites connection is a physical LAN extension not virtual vpn within same cable.

Also concerning routing we can run OSPF on the ASA over the ipsec tunnel, which i plan to use.

mark.j.hodge Fri, 04/27/2007 - 06:47

I'm not sure I take your meaning when you "say each site is a physical LAN extension". Do you mean the IPSEC tunnels will not be across the internet, but another WAN infrastructure? In any case, the probability is that if a site is unable to communicate through one of its IPSEC tunnels it will be due to total communication failure, the link to the Internet/WAN, ASA failure etc. i.e if tunnel A <-> B fails, it is likely that either site A or site B has lost communication with sites C & D as well.

It has been a while since I have looked at this, but I am 99% sure you cannot run OSPF on the ASA, communicating through the IPSEC tunnel.

This is because the IPSEC tunnel identifies interesting traffic as it enters the ASA, any traffic originating from the device itself, in this case the OSPF updates, is not so identified and therfore cannot pass through the tunnel.

gabrielbryson Fri, 04/27/2007 - 07:10

HI Mark

See the following article to run OSPF inside ipsec on the ASA http://www.cisco.com/en/US/partner/products/hw/vpndevc/ps2030/products_configuration_example09186a00804acfea.shtml. LAN extension is a British product offering ethernet as a WAN link (Long reach ethernet eg) and each inter site connection is a 100Mb link with its own RJ45 termination cable, so therefore it is possible to loose a single site without affecting others, they are all terminating on different ASA interfaces.

gabrielbryson Sat, 05/05/2007 - 00:12

I know its long but please read its rather interesting.............DMVPN Dynamic Multipoint VPN......

To continue this discussion I have now configured 4 ASA's in a Partial mesh config running OSPF. Site A and B connect to all other sites and site C connects D and A and SIte D connects to D and B. IPSEC between all sites. OSPF is running on all ASA's and using static routing into each site onto a 3750 L3 switch with a few Vlans on each, which are advertised into OSPF with redistribute static command. Only site A provides internet access to all. After minor tweaking of OSPF costs to ensure symetrical routing between all sites, all is working great. Each site link is on its own dedicated physical connection i.e there are no virtual site links within the same cable comming from the ISP and they all Long reach ethernet L2 connections.

The only slight problem is when testing via a extended ping i bring down one of the inter site links and within 2 seconds it routes via another ipsec tunnel as instructed by the ospf. Great, now the primary link comes up again and if the existing transfer is large it will continue to use the backup link even though the ospf has reverted to using the primary link, problem happens when i try inituate a new connection to the same destination, because of the cached connection now going on the backup link and the ospf saying use primary it does not work. To fix this I can either generate traffic from the dest to the source and it strangely works, or I flush the backup ipsec phase 2 tunnel.

Does anyone have any suggestions on any alternatives to this, I have set secondary links as per ospf with a 1 min ipsec idle timeout to flush those quicker..

Any ideas welcome...



This Discussion