VPN with ISDN backup

[TalonKarrde]

Hi All,

for whatever reason, our customer has chosen an Internet based VPN as the primary network link between a key location and the main network.

This link needs high availability and as such they wish to provide a backup to the Internet/VPN based solution.

We have proposed an ISDN connection from this location to the central network of their WAN provider, from which point the WAN provider will route all packets around their network.

The VPN is handled by some third party firewall device that is standardised and cant be changed. It simply provides ethernet hand-off to the locations LAN.

We are looking at sitting a Cisco product with an ISDN port and 2 ethernet ports to act as a gatway for the LAN. The Cisco product would primarily route everything from the LAN to the VPN box and in the event of Internet failure, bring up the ISDN port as a backup connection.

We are looking for some way to automatically failover from the ethernet based VPN link to the ISDN link.

I thought policy based routing might be appropriate, but this seems to require a fairly high end router. We were looking at a 1700 series product since this location does not have a lot of traffic, just important traffic.

Any comments or suggestions are appreciated.

[Richard Burts]

I have a couple of comments and suggestions about your question.

If the VPN device is some third party device which can not be changed, and if the VPN device expects to connect to the remote LAN, how are you planning to insert your router? Does the VPN device supply DHCP services for the remote LAN? If so how will you accomodate this on your router?

The essence of your question is how to fail over from the VPN link to the ISDN link. I am not convinced that Policy Based Routing is the best answer.

I would suggest that you configure a default route pointing to the VPN device and configure a floating static default route pointing to the ISDN device. Then you need a way to remove the default route to the VPN if there is a failure in the VPN network. Cisco has a fairly new feature called Object Tracking which can be used with static routes. So you configure object tracking to verify reachability of some address in the VPN network. So long as the address is reachable the default route remains in the table. And if that address becomes unrechable the default route is removed and the floating static defaut route will be used.

HTH

Rick

[TalonKarrde]

Hi Rick,

Thanks for your response.

I have had a look into advanced object tracking but cant seem to find the functionality that you mention in terms of changing the default route depending on availability of a hop on the network.

Do you know of a specific example of this configuration performing a default route selection based on the availability of a next hop router?

Thanks again.

[Richard Burts]

I found this discussion about Object Tracking and Static Routes to be quite good:

http://www.cisco.com/en/US/products/sw/iosswrel/ps5413/products_feature_guide09186a00801d862d.html

And a shorter discussion would be this one. Look especially at Sample Config #2

http://www.cisco.com/en/US/about/ac123/ac114/ac173/Q2-04/department_techtips.html

HTH

Rick

[jwilson]

If you are planning on using GRE tunnels between locations, you can use keepalives (added in some recent version of IOS) to let you know when a tunnel goes down and have a floating static route to the ISDN interface ready and waiting. However, my experience with these is mixed; sometimes the tunnel interface just doesn't go down.

Regards

Jonathan

[vcjones]

While it will require an IOS feature set upgrade on your 17xx router, I like to use BGP-driven dial on demand routing in this situation. That eliminates the need to reduce MTU with a GRE tunnel, although you do have to be careful of the IPSec VPN overhead.

Your initial description was not totally clear. The easiest way to set up VPN backup is with "dial around" where an ISDN call is placced between the two routers at each end of the VPN. It is significantly trickier if the VPN connects the site to a multitude of sites (mesh toppology rather than point-to-point or hub and spokes). Then you need an approach which detects which end of the VPN has failed so the appropriate calls can be placed, and no others.

Also be aware when you start using ISDN backup to keep track of what and when ISDN is used. Otherwise, the first indication you may have of networking problems is when a humongous telephone bills comes in the mail :-(

There is a white paper on Redundant VPN setups on my web site which you will probably find of interest. It includes an example configuration which may match your requirements, complete with annotations of how it works and how it can fail.

Good luck and have fun!

Vincent C Jones

www.networkingunlimited.com