VPN as failover to WAN link(s)

[Steve Coady]

Hello

I have a Data Center with an outsource company and a WAN link to them over an AVPN cloud connection

I have (12) sites around the country each with their own connection to the same AVPN cloud as data center.

We suffered an outage on the Data center WAN interface due to lack of redundancy.

In the event that this happens again, To bypass the Data Center WAN interface as a short term fail over fix, I want to create a VPN connection from my Corpoarate site (used to be my data center before outsource) to the data Center.

Creating the VPN is easy enough and defining the networks to be allowed across. I can create the fw rule is asdm and as long as I don't enable it, there should be no problem with routing issues.

I am wondering what route statement I need to create in each of the 12 site routers that will send data to my Corporate site where it can then be sent over VPN, once the ASA rules is enabled.

Is then even the best short term approach?

[Lei Tian · Accepted solution]

Hi,

So the temp solution is to have ipsec VPN tunnel between data center and corp office, this VPN tunnel will be used as backup link when data center primary WAN link fails. What routing protocol are you running across WAN? What routing protocol are you going to run across the VPN tunnel? Are you advertising default from corp or data enter? Can you summarize prefixes from data center?

HTH,
Lei Tian

Sent from Cisco Technical Support iPhone App

[Steve Coady]

Lei

Thank you for the response.

What routing protocol are you running across WAN?                          Answer BGP

What routing protocol are you going to run across the VPN tunnel?     IPSec (site-to-Site)   

Are you advertising default from corp or data enter?                            Answer Not at this time

Can you summarize prefixes from data center?                                  We could i guess. They are contiguous.

                                                                                                      They are not currently aggregated in the Protected

                                                                                                      Networks field.

[Steve Coady]

[Steve Coady]

Sorry

the above image is our network topology

[Lei Tian]

Hi Steve,

Thanks for the info. Based on your setup, you can advertise datacenter summary route from corp to BGP, and adversie corp summary route from datacenter to BGP. This BGP route will propogate to remotes, and will be used as backup path when remote loses the more specifc routes from BGP.

HTH,

Lei Tian

[Steve Coady]

Lei

Thank you for the response. Greatly appreciated.

I am not sure how the commnds would look. Here are the BGP stements for the Data center router and the Corp site along with statics. At your earliest convenience please review and advise.

CORP Router

router bgp 43210

no bgp log-neighbor-changes

network 0.0.0.0

network 10.x.16.0 mask 255.255.240.0

network 10.x.32.0 mask 255.255.240.0

network 192.168.h.0

network 192.168.i.0

network 192.168.j.0

network 192.168.k.0

network 192.168.l.0

network 192.168.m.0

network 192.168.n.0

network 192.168.o.0

network 192.168.p.0

neighbor 172.16.x.x remote-as 56789

neighbor 172.16.x.x soft-reconfiguration inbound

neighbor 172.16.x.x route-map PrependNetgate in

no auto-summary

!

ip route 0.0.0.0 0.0.0.0 192.168.j.1 track 2

ip route 192.168.k.0 255.255.255.0 192.168.j.1  track 2

ip route 192.168.n.0 255.255.255.0 192.168.j.2 track 2

ip route 192.168.o.0 255.255.255.0 192.168.j.2 track 2

ip route 192.168.253.0 255.255.255.0 192.168.3. track 2

Data Center router

router bgp 01234

no bgp log-neighbor-changes

redistribute static

neighbor 172.16.x.x remote-as 56789

no auto-summary

!

ip route 192.168.a.0 255.255.255.0 172.16.y.z

ip route 192.168.b.0 255.255.255.0 172.16.y.z

ip route 192.168.c.0 255.255.255.0 172.16.y.z

ip route 192.168.d.0 255.255.255.0 172.16.y.z

ip route 192.168.e.0 255.255.255.0 172.16.y.z

[Steve Coady]

The final solution for this specific problem will be:

When connectivity to MY_remote_Data_Center is lost, an alternate routing path will direct traffic from the MY_Company network toward the Internet.

The VPN would be established between the MY_Company_ASAs and MY_remote_Data_Center firewall. The VPN connection has to be manually activated on MY_remote_Data_Center.

A Customer SLA accompany's this solution to guarantee response times.

This sequesnce is for implementation annd initial test

object network MY_remote_Data_Center

host 192.168.y.a

!

object network MY_Company

host 192.168.z.a

!

access-list MY_remote_Data_Center_cryptomap line 1 extended permit ip object MY_Company-Network object MY_remote_Data_Center

group-policy GroupPolicy_MY_remote_Data_Center internal

group-policy GroupPolicy_MY_remote_Data_Center attributes

vpn-tunnel-protocol ikev1

exit

!

tunnel-group 1.1.1.1 type ipsec-l2l !<< obviously Replace 1.1.1.1 with the MY_remote_Data_Center VPN IP Address

tunnel-group 1.1.1.1 general-attributes

default-group-policy GroupPolicy_MY_remote_Data_Center

tunnel-group 1.1.1.1 ipsec-attributes

ikev1 pre-shared-key <>

isakmp keepalive threshold 10 retry 2

!

crypto map outside_map 4 match address MY_remote_Data_Center_cryptomap

crypto map outside_map 4 set  peer  1.1.1.1 !<< obviously Replace 1.1.1.1 with the MY_remote_Data_Center VPN IP Address

crypto map outside_map 4 set  ikev1 transform-set  ESP-AES-256-SHA

Once the above solution has been validated. the loopback ip addresses would be removed and actual production subnets added