Active-Passive Tunnel Identification Issue from Azure

[rajp]

Hi,

We have 2 ISPs at on-premises ISP1 and ISP2 in fortigate firewall.

Two IPsec tunnels are created from on-premises to azure for site-to-site connectivity per ISP each.

Azure VPN Gateway at cloud and Fortigate Firewall at onprem having connectivity using two different tunnels.

Both tunnels are in connected state 24x7 but at fortigate it is configured like if primary ISP's tunnel goes down then only on-premises traffic flow through the secondary ISP's tunnel even though both tunnels shows in connected state in azure.

But from azure side packets are flowing in both the tunnels and that's why whenever packets  are routed through secondary tunnel then that will be dropped at on-premises side. so for temporary basis we have to down the secondary tunnel so that azure do not send data through that tunnel.

Is there any permanent solution for this issue? (we can not enable BGP since it is not supported in SKU we have, also can we achieve our goal via asymmetric routing or any other solution suggested to be configured at fortigate firewall?)

[FredPaul]

Hi!

Without BGP the easiest way to do this is by using static routing and link monitoring. All this is done on the Fortigate side of things. So configure the two tunnels identically, that is with the same static routing etc (same distance and priority). Then do this:

# config vpn ipsec phase1-interface
    edit <backup-phase1-name>
        set monitor <primary-phase1-name>
end

This will bring the backup IPSec tunnel down, and it will stay down until the primary tunnel goes down. This way you don't have to worry about asymmetric routing etc.

[rajp]

Hi Fredrik,

Let's say this functionality had brought down the primary tunnel and up the secondary(backup) tunnel when ISP1(primary tunnel)'s internet goes down.

But if ISP1(primary tunnel)'s internet comes back again then will it bring primary up and down the secondary one automatically?

[FredPaul]

Yes, the secondary tunnel will monitor the primary one, so when the primary one is up, the secondary goes down, and vice versa.

[rajp]

Hi Fredrik,

Here routing(static routes) is not an issue, they have two routes as traffic passing through primary ISP having AD value as 10 and secondary ISP as 20, so static routes are working perfectly fine. Like if primary ISP goes down then secondary ISP's static route will work as primary.

But *IPSec tunnel* is the issue, because both IPSec are in up state and traffic flowing from on-premises to azure based on static route. just like even secondary is up but traffic will flow from on-premises to azure based on static route which having AD 10. Issue is that since both the tunnels are up, azure is treating that it can flow traffic to both tunnels as 50-50% ratio, but at fortigate it will drop all the packets coming from azure to secondary tunnel.

In this scenario will this link monitor feature work?

thanks

-Raj

[FredPaul]

Hi Raj,

Seen from the Fortigate side of things using two static routes with different distance is fine. This is however not shared with Azure, and in Azure the distance on the two routes is the same, so some responses will come back on the secondary IPsec tunnel. This will result in asymmetric routing on the Fortigate, and those packages will be dropped. Without a dynamic routing protocol where the devices communicate on how to route the traffic you'll need to control the traffic by using an active-passive setup of the tunnels, and the way to do this is using monitoring.

So short answer: yes. This is a good scenario for using the link monitoring feature.

That being said, there is possibly one more way of doing this which enables the use of both tunnels while using static routing: ECMP. Probably the best way to set this up is with SD-WAN. You can read more about that here:

https://docs.fortinet.com/document/fortigate/7.2.3/administration-guide/25967/equal-cost-multi-path

I haven't tested this approach using static routing, though.