Site-to-site VPN doesn't works in faillover scenario

[pirgi]

Hi all, I wanna thanks for every advice you can get me. I want use a Site-To-Site VPN in a failover scenario but the tunnel seem to be working only if the lines are up. I try to describe the situation.   Head Office network LAN 192.168.8.0/24 fortigate ip on LAN 192.168.8.253 Primary Link MPLS, IP router 192.168.8.254 connected on FG internal interface ADSL Internet Link is connected to WAN1 port of fortigate I have configured a static route to branch office lan 192.168.4.0/24 - gataway 192.168.8.254 on port1 (internal)   Branch Office network 192.168.4.0/24 fortigate ip 192.168.4.253 Primary Link MPLS, IP router 192.168.4.254 connected on FG internal interface ADSL Internet Link is connected to WAN1 port of fortigate I have configured a static route 192.168.8.0 - gataway 192.168.4.254 on port 1 (internal)   in this condition a pc in the head office LAN with gataway 192.168.8.253 (fortigate) reaches a pc of the branch office LAN through MPLS using routers 192.168.8.254 without problems and vice versa.   Now I configured a SITE-TO-SITE VPN Tunnel between the two fortigates. The Tunnel works fine, until the MPLS does not fall.   I have configured in the Branch Office Fortigate a monitor link (dead link detection use ping on 192.168.8.254 using gataway 192.168.4.254) . When the ping fails the static route on internal port are deleted from the routing table, as I expect. In this case, the only active route to 192.168.8.0/24 network is the “TUNNEL Route”, so I expect the traffic flow through the tunnel towards the newtork head office, but this does not happen.   In conclusion, if the lines are all up and I manually change the priority of static routes, (privileging the “tunnel route”) the traffic passes through the tunnel correctly, but in case of failover of the MPLS link or in case of router MPLS dead, the packets do not pass through the tunnel, (despite the link monitor works fine) how is it possible?   Thank you in advance

[Antonio_Milanese]

Hi Pirgi, you must have link monitors probes on both sites or when, on HQ site, the mpls link fail since this is a transit network the route never be removed (no interface down evnt) effectively blackholing the HQ originated routed traffic. We have some customers with a similar setup and all it's working seamlessly..some quick suggestions: - set your floating routes as same distance different priority so the route it's already installed on the RIB with a little fast failover - set link-monitor source-ip as FGT mpls facing interface ip to bind reachability path Best regards, Antonio

[pirgi]

Hi Antonio, thanks for your answer... I have configured the link monitor only in the Branch Office, when the MPLS falls down I tryed to manually change the priority of the static route configured in the HQ for redirect traffic throught the tunnel but nothing changes. The link monitor on the Branch Office works as I expected, according to the param set update-static-route enable all the static route associated to internal port are erased from the routing table and only the tunnel route remain active.

I think the problem is routing.... and related sessions, but I haven't the solution yet. Now I focus on blackhole route for resolve the issue. In my case I have the same remote subnet can be reached by two alternative paths, but when one oh them die, I think that fortigate doesn't discard the previous sessione that use the old (down) path.... Is it possible ? or I get the wrong end of the stick... Gianni

[Antonio_Milanese]

Hi pirgi

pirgi wrote:
thanks for your answer... I have configured the link monitor only in the Branch Office, when the MPLS falls down I tryed to manually change the priority of the static route configured in the HQ for redirect traffic throught the tunnel but nothing changes. The link monitor on the Branch Office works as I expected, according to the param .... I think the problem is routing.... and related sessions, but I haven't the solution yet. Now I focus on blackhole route for resolve the issue.

Assuming that you have all policy correctly in place and that the tunnel it's working... Yes you have to configure a link probe on HQ to determine whether the transit network path is working end-to-end and therefore will have to remove the now invalid route when the MPLS link fail. to be more explicit: #HQ# routes: 192.168.4.0/24 via device PORT1 , gateway 192.168.8.254 , distance 5 priority 10 192.168.4.0/24 via device VPN_ROBO , distance 5 priority 15 link-monitor: srcintf PORT1 server 192.168.4.254 gateway-ip 192.168.8.254 source-ip 192.168.8.253 update-static-route enable (default) when the MPLS link it's up you have a routing table with both routes installed but with MPLS path preferred/active, something like the following from cli:   FGT-LAB # get router info routing-table static S       192.168.4.0/24 [5/0] via 192.168.8.254, PORT1, [10/0]                       [5/0] is directly connected, VPN_ROBO, [15/0]  (this is the floating route with less favorable priority 15)                        when the MPLS it's down on any of the two sides, the only route active should be via VPN_ROBO. On ROBO fortigate of course you have a simmetric configuration. Without the HQ probe you have a blackhole since the HQ originated and obviously ROBO return path  are still routed to MPLS using the till valid route installed in the RIB of HQ fortigate!! For statefull established sessions route re-evaluation does not happen until the session expire or a new one is established.. For antileak blackhole route in case of both link fail there is already a good post here: [link]https://forum.fortinet.com/tm.aspx?m=120834#120872[/link]

Hope this clarifies the problem better.

Best Regards, Antonio

[juhl]

Hello,

I was reading this post and have also contacted support regarding a similar question. In my scenario I have a backup VPN circuit but only want to disable a single static route to a hosting site when using link monitor, not all routes pointing to the MPLS interface IP.

I have multiple static routes that point to the MPLS (including the hosting site). That way if the remote location IP did not respond to a ping just that route would become inactive. Per support this is not possible and ALL static routes to the MPLS IP become inactive since it is at the interface level not a particular static route.