cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1434
Views
15
Helpful
9
Replies

How to route from Office to multiple sites via IPSEC VPN.

mohamedridha
Level 1
Level 1

Hi there

I currently have the following setup 

 

|MAIN SITE (vASA) | -------IPSEC Tunnel------> | SITE A (Fortigate)|

 

All my users VPN to 'MAIN SITE' using AnyConnect and all their traffic traverses the IPSEC tunnel and out of SITE A.  This is achieved using a cryptomap which states something like the following 172.x.x.x --> 0.0.0.0/0 to initiate the IPSEC tunnel. 

I would like to setup SITE B so that when SITE A is down all user traffic will traverse SITE B. This will look something like the following;

 

|MAIN SITE (vASA) | -------IPSEC Tunnel------> | SITE A (Fortigate)|

|MAIN SITE (vASA) | -------IPSEC Tunnel------> | SITE B (Fortigate)|

 

1 - How can this be achieved dynamically?

2 - Can iBGP be used? if so how? and how will this work with the cryptomap?

Kind Regards

 

9 Replies 9

Richard Burts
Hall of Fame
Hall of Fame

You have told us a little bit about your environment and asked 2 questions. Based on what we know so far I believe that we can answer your first question but not your second one. To provide failover to site B when site A is not available you would configure a site to site vpn for site B which is exactly like what you have configured for site A (especially important is that it uses the same peer address as site A. Then on site A you modify the crypto map entry for the peer and you add a second IP address. With this configuration change your main site will open a vpn connection to site A. As long as site A continues to be active the vpn is stable. If there is a problem at site A or in connectivity to site A then the main site will negotiate a vpn with site B. This failover is automatic. There may be a small impact as your main site recognizes that there is a problem and negotiates the new vpn session. 

 

Note that the main site will not automatically revert to the original vpn when site A becomes available. When the main site has reason to renegotiate the vpn it can establish the vpn with site A. Or you can clear the ipsec and isakmp sa and cause the vpn to establish with site A.

 

Since we do not know what you are currently doing with BGP we are not able to address your question about using IBGP.

 

HTH

 

Rick

HTH

Rick

Hi Rick

 

Many thanks for you response this is hugely helpful.

 


 (especially important is that it uses the same peer address as site A.


Please can you clarify what you mean by peer address?  are you reffering to the vASA IP address?

 

So from what I understood I can have a cryptomap entry on the vASA and setup the same site to site VPN to two different endpoints.  This would mean that I ensure that the L2L to Site A always comes up first?

 

With the above settings, if Site A were to fail then the vASA would use cryptomap settings to setup L2L to site B? 

 

Regarding BGP, I have not implemented any BGP routing..this was more about thinking outsite the box to achieve dynamic resilient routing in similar fashion to above. 

 

Kind Regards

 

Mohamed

Mohamed

 

In your crypto map there should be a statement 

set peer <ip_address>

This is to identify the address that is the destination of your vpn session. This is the address I am talking about. So it would be something like

set peer <ip_address> <ip_address2>

 

There should also be a series of tunnel statements for the first peer. You would need a similar set of statements for the backup peer.

 

HTH

 

Rick

HTH

Rick

Hi Rick

Thank you for the clarification.

Unfortunately, my site B has a different IP address to site A.

In my testing I have noticed that the cryptomap priority will always kick in and therefore my crypto map will continue to try and peer with site A even though site A is down and site B is up.

Is there a different or alternative solution to this?

Kind Regards

Mohamed

Also to add I am using IKEv2 which I believe does not support multiple peers in a single cryptomap

Mohamed

 

I do not understand your comment

Unfortunately, my site B has a different IP address to site A

I would assume that site A and site B would have different addresses. Perhaps my explanation was not clear. So let me try again. In the crypto map you would have something like set peer <IP_siteA> <IP_siteB>

 

I am not aware of a restriction of IKEv2 on multiple peers. But while I have configured multiple peer addresses in a crypto map it has been IKEv1 and perhaps there is a restriction that I am not aware of.

 

The approach I have been suggesting defines 2 peers (and 2 tunnels) but has only one active at a time. If that does not work for you then perhaps the other approach to think about would be to have two peers and two tunnels that are active at the same time and to use a routing protocol to prefer one peer but if it fails then to use the other peer. I had a customer who did something like this. In their crypto configuration they set up 2 peers (each with its own tunnel) and both peers would be active at the same time. They ran a routing protocol over the vpn tunnels and manipulated the protocol metrics so that as long as site A was active and the routing peer was reachable then traffic went through site A. And if there were a problem and the site A routing peer was not reachable then traffic used the routes advertised by site B. 

 

HTH

 

Rick

 

HTH

Rick

Hi Rick

 


@Richard Burts wrote:
So let me try again. In the crypto map you would have something like set peer <IP_siteA> <IP_siteB>

Thank you very much for your help it is a greatly appreciated.

Understood now, yeah unfortunately it looks like IKEv2 does not support multiple peers, there is a existing enchancement request with over 220 support tickets. This would have been the ideal solution, not sure I want to move to IKEv1.

 

 


@Richard Burts wrote:
the other approach to think about would be to have two peers and two tunnels that are active at the same time and to use a routing protocol to prefer one peer but if it fails then to use the other peer. I had a customer who did something like this. In their crypto configuration they set up 2 peers (each with its own tunnel) and both peers would be active at the same time. They ran a routing protocol over the vpn tunnels and manipulated the protocol metrics so that as long as site A was active and the routing peer was reachable then traffic went through site A. And if there were a problem and the site A routing peer was not reachable then traffic used the routes advertised by site B.

I think this is what I was trying to get at when I mentioned BGP, probably poorly worded on my end.  I am however struggling to understand how this would work.


My ASA has a default static route as follows

 

0.0.0.0 0.0.0.0 dmzData  where 'dmzData' is the internet facing interface for which webvpn is setup.

So all incoming user traffic terminates on the 'dmzData' interface.

 

If I were to create two tunnels and then use a routing protocol to advertise routes, wouldnt the static route on 'dmzData' always overide routes advertised by routing protocol?

 

Kind Regards

 

Mohamed

Hi Rick

 

I have attached a quick diagram to hep illustrate my scenario.

 

  • All VPN clients connect to 'DMZData' interface
  • default static route is on 'DMZData' interface
  • VPN traffic connects to Site A using cryptomaps
  • Interesting traffic has remote traffic selector set to ANY i.e 0.0.0.0/0
  • This is done to route all internet facing traffic via the L2L tunnels

I have read about using VTI interfaces as a workaround to the limited peers in IKEv2. However the VTI approach would require routing statements in place.

 

Would the default static route on 'DMZData' not overide the requirement to send all VPN traffic down L2L tunnels? i.e wouldnt user traffic end up going back out 'DMZData' ? 


Would a tunnelled static route entry work here?

 

Mohamed

 

If IKEv2 does not support two peers then I believe that 2 vpn tunnels with a routing protocol is a viable solution. The static default route is not a problem. We can look at that from a couple of perspectives:

1) The default route is used when there is not a more specific entry in the routing table. Running a routing protocol over the vpn will generate more specific entries in the routing table and they would be used instead of the default route.

2) What is important is that traffic for the vpn be sent out the interface where the crypto map is. It does not matter whether the traffic is sent out that interface from a routing protocol entry or sent from the default route. It just matters that it is sent out that interface.

 

Here is a link that discusses using a routing protocol over vpn on an ASA. I hope you find it helpful.

https://community.cisco.com/t5/vpn-and-anyconnect/site-to-site-vpn-with-dynamic-routing-on-asas/td-p/1769892

 

HTH

 

Rick

HTH

Rick
Review Cisco Networking for a $25 gift card