Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
gzarini
New Contributor

IPSEC for mpls failover.

Hi, i have a little issue on setting up my network. I have a MPLS network provided by an isp. This network has a HQ and 3 branches. On the short time we're going to move our app servers to a dc, but keep in HQ AD/DNS/Fileserver. I need to create an ipsec between branches and HQ to fordward traffic in case the mpls fails. I need to route 3 networks between each branch and HQ, here is where i have my doubts. Since i can only use static routes, i have a problem on how to handle traffic when the mpls is down. I thought about setting up a dgd on branches to check connectivity through MPLS and send traffic over vpn in case MPLS fails. I understand that what FG does when a dgd is detected is stop sending traffic through that interface. On the HQ, how can i set up a dgd on any kind of detection to check that the other side is unreachable?. I don't think i can use a dgd on HQ because i need to check that three branches are down, but only one can be unaccesible. I could really use some help.   Regards.

12 REPLIES 12
ede_pfau
SuperUser
SuperUser

hi,

 

interesting question. But, please don't cross-post. "VPN" is the right forum I think.

 

Connection failover will be built on route failover. You set up the VPNs to connect all the time. The routes across the MPLS and the VPNs will have to be weighted differently to make the MPLS route prefered. That's what the distance and priority parameters are for.

The prefered (MPLS) routes will be included in the Routing Table and the backup (VPN) routes will not.

 

Now what happens if the MPLS fails.

Dead gateway detection (in the more sophisticated form of ping server detection) will delete the MPLS route from the RT. Now, the secondary, less attractive route across the VPN will be included and traffic will flow again.

As soon as the MPLS is tested OK it's route will be installed and traffic will be diverted back across the MPLS.

 

For the VPN I recommend a hub-and-spokes layout. This is easy to set up and easy to enlarge later.

 

How do you know that the MPLS is down? Well, you can specify up to 3 ping servers which all have to fail until DGD declares the MPLS down. You should always use at least 2 independent servers to guard against 'false' failovers due to server downtime/maintenance window. The additional servers are specified in the CLI only. If you select servers such that more than one external link is monitored you can be quite sure to detect an outage.

 

If you monitor each link independently, you can survice partial link loss. IMHO it's not a 'all or nothing' question.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
gzarini

Thanks for the answer. one question.

"Now what happens if the MPLS fails. Dead gateway detection (in the more sophisticated form of ping server detection) will delete the MPLS route from the RT. Now, the secondary, less attractive route across the VPN will be included and traffic will flow again. As soon as the MPLS is tested OK it's route will be installed and traffic will be diverted back across the MPLS."

 

When Mpls fails and FG deletes routes from the routing table, it deletes all routes associates to the interfac that connects to the mpls, or deletes only routes to one particular branch?.

 

Regards.

gzarini

This is a little diagram of what i need.

 

ede_pfau

Please delete your last post and repost the image. Use "Preview" is unsure how it is rendered.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
gzarini

Sorry, i missed taht.

ede_pfau

Wow, my last post was deleted...I'll repeat:

 

DGD monitors an interface. If the interface fails, all routes involving this interface are removed from the RT. That's why you set up DGD for each interface connected to the MPLS network.

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
gzarini

Sorry, now i get it. The problem is i have only one interface that is the default gateway for the mpls, so this interface connects all branch offices to the HQ. that's why i mentioned that if only one part of the mpls is useless to shut down that interface because the rest of remote sites will lose connectivity.

 

 

ede_pfau

1) It looks like the third branch office doesn't have a connection to the MPLS.

2) You can set it up like this: each branch has 3 ways/routes to reach each server site - 1 MPLS, 2 direct VPN, 3 indirect VPN via HQ. Let the branch firewall decide which way to use, not the HQ firewall.

 

[strike]HQ firewall only decides which route to take to reach the server sites, MPLS or VPN.[/strike]

HQ has no choices, sorry, VPN only.

 

Does that make sense to you, or am I thinking into the wrong direction here?

Ede Kernel panic: Aiee, killing interrupt handler!
Ede Kernel panic: Aiee, killing interrupt handler!
gzarini

HI, yes. that's what i'm implementing. but only that i don't have indirect vpn. in that case i'll configure vpn over second wan against HQ.

Now that you are more interiorize with what i need i'll ask you something.

Branches will use dgd to check connectivity against HQ, and case it fails it'll send traffic over vpn.

IN HQ since i use static routing, i need to change somehow routes metric to send back over vpn.Here's what i tested. In one branch i configured ipsec, and static route (primary and secondary). in HQ i did the same (mpls routes obvouisly have lower metric).

In bramch i disconnect the cable that connect to the mpls and traffic was send over vpn, but when traffic went back from HQ it did over mpls. to send traffic back over vpn i had to change routes metrics.

 

That's what i need to be automatic. I thought abut using scripts to check the other side and change routes metrics, but i have no idea how to use it.

 

Announcements

Select Forum Responses to become Knowledge Articles!

Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.

Labels
Top Kudoed Authors