I am trying to get my head around if a scenario is possible, I will try and describe:
I have 4 sites, site A, B C and D, all connected via MPLS network, all internal networking is on the 10.0.0.0/8 subnet. I have static routes on the Fortigate devices pointing 10.0.0.0/8 towards MPLS for all sites - actual routing over the MPLS (BGP) is handled via service provider routers that I have no access to. Site A and B are head office sites, also have ISP links (direct to internet), default route 0.0.0.0 obviously points out to internet, site C and D only have MPLS. The MPLS link between site A and B is a SPOF that causes service issues. I need some sort of resilience. Putting in an IPSEC VPN between sites A and B over the internet is an option, but I am stuck with creating any automatic failover.
To complicate the matter, if we have a service interruption between site A and B over MPLS, I can't just use a link monitor to disable the port or static routes, because I cannot cause service issues to sites C and D, could be an issue where the issue is link to site A, so sites C and D are still working happily as they can still access site B.
What I really need is a link monitor where I can disable only specific static routes, so in the case of the failure above, site B still routes traffic to C and D over MPLS, but the traffic to site A is diverted to VPN tunnel.
Hope my ramble makes sense to someone. :)
Ta
J
I don't know what 'SPOF' is and why only A-B fails while other combinations work over MPLS. But based on what I grasped about your situation, and by knowing link-monitor's route removal is interface-base, only option I can think of is to extend your MPLS provider's BGP domain to your FGT at A and B locations, so that your FGT would lose routes for the other side at A and B when it has problems. FGT side change should be relatively simple, adding new BGP config to set a neighbor for the provider's local router and set to advertise local subnets. You need to talk to the provider if they offer that arrangement.
Hi
SPOF = Single point of failure
To be more specific, key parts of my phone system IP PBX are at site B, I have 500 people at site A that cannot loose connectivity, but I also cannot have the 50 users per site at C and D experience lost connectivity
I think the long term solution is to configure the MPLS and VPN interfaces into a single SD-WAN interface, and use SD-WAN rules to direct the traffic, but implementing on a production firewall with 400 policies each is too much of an ask.
This might have to wait for when I have budget to replace the firewalls next April, and build the new units with SD-WAN interfaces from the get go.
Hello, its very simple if i understand what you trying to do.
If you wanna do a failover using MPLS, you simple just need to create a VPN MPLS, set a IP on the VPN tunnel interface A like 1.1.1.1 IP VPN Tunnel B 1.1.1.2 and then create your link monitor pointing to each IP side.
Change your MPLS static router gateway for your VPNs MPLS created, and then make your test.
I did that and sucess of failover using static routes and mpls. :)
ronildo@secureway.com.br wrote:Hello, its very simple if i understand what you trying to do.
If you wanna do a failover using MPLS, you simple just need to create a VPN MPLS, set a IP on the VPN tunnel interface A like 1.1.1.1 IP VPN Tunnel B 1.1.1.2 and then create your link monitor pointing to each IP side.
Change your MPLS static router gateway for your VPNs MPLS created, and then make your test.
I did that and sucess of failover using static routes and mpls. :)
Did you notice any issues with latency by doing this? It seems unnecessary to have the firewall run a VPN over a private connection but I understand why.
I'm running in to same question here about Linkmonitor removing all routes and not specific ones for a VPN backup to MPLS.
User | Count |
---|---|
1922 | |
1144 | |
769 | |
447 | |
277 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2025 Fortinet, Inc. All Rights Reserved.