Redundant/Backup IPSEC VPN Options R81.20

[Douglas_Rich]

Looking at configuring a IPSEC VPN with a backup tunnel. external client(Interoperable Device), no dynamic routing, single ISP on CP side.

I found two options and I'm wondering which is the better option, in your opinion. 

1. Two tunnels utilizing VTI interfaces with redundant routes configured with different priorities for each tunnel. 

2. The example shown in sk sk164355 VPN redundancy

[the_rock · Accepted solution]

I can only speak for myself, but I know 2 customers who tried the sk you mentioned and we could never get it to work the way we wanted. We even had TAC case, but gave up trying after some time, since it was taking too many hours.

I did option 1 many times, no problems.

Hope that helps.

[Douglas_Rich]

Thank you this is very helpful

[the_rock]

No worries! Message me directly if you want to discuss it, no issue.

[Vincent_Bacher · Accepted solution]

While I'm not the biggest fan of VTIs in general, I'm familiar with route-based VPN designs from other vendors, and the concept works reliably. So in this case, I would agree that using VTIs with appropriate routing metrics is the right approach.

And because I'm not satisfied with the solution described in the SK referenced above.

[the_rock]

Im certain there is a way to make it work, but if I had patience like I did in my 20s, maybe I would be willing to spend 100 hours on it to make it function 🙂

Otherwise, I like to stick with method that does work.

[Vincent_Bacher]

The same applies to me. At the moment, I prefer to focus my time on working with the APIs and developing scripts — for example with Copilot — to automate various workflows.

For example, upgrading or replacing dozens of VMware-based gateways for the upgrade to R82. I do everything on the vCenter and SmartCenter side via API. I still have enough patience for that kind of thing today.

There are so many APIs these days to learn playing with.

[the_rock]

Totally, no argument there. Have a great weekend, Vin!

[Vincent_Bacher]

And you!

Best
Vince

(Vin always confuses me — I’m not a Diesel, you know. 😉 )

[the_rock]

haha, true...Vince it is 🙂

[Duane_Toler]

Echoing the others,  I would also vote for VTIs and universal tunnels (Community properties -> Tunnel Management -> "subnet per gateway pair").  You can still do static routing via the VTI.  You can't to ECMP across them, but you can set route priorities.

For your case here, just use the 169.254.1.x/24 address space for your side of the VTI (numbered VTI). It doesn't matter what the peer has; it's irrelevant. They can be 192.168.5.23.  

add vpn tunnel 101 type numbered local 169.254.1.3 remote 10.255.254.5 peer gw101

Unnumbered VTI can be done, but it needs a proxy interface, which can be either physical interface (eth2) or a loopback.  This gets more complicated and you probably don't need that (but you do in a cluster with BGP).

VTIs are point-to-point links; anything you send down that pseudo-wire is going to go out that interface.  There is no next-hop; your routes are:

set static-route 192.0.2.0/24 nexthop gateway logical vti101

The only time a next-hop matters is if you're doing BGP with it, but sounds like you only need static routes.

When you add your VTI, be sure you go to SmartConsole and gateway properties -> network managment and do Fetch interfaces (without topology) so you get the correct interface type added.

Good luck with your implementation and let us know if you run into anything unusual!