Fortinet white logo
Fortinet white logo

Azure vWAN SD-WAN NGFW Deployment Guide

7.4.0

Dynamic rerouting

Appendix C - Dynamic rerouting

The FortiGate SD-WAN solution in Azure vWAN Hubs is designed for two active FortiGates. It is recommended for each FortiGate to have at least one tunnel to every branch device. If the branch device has multiple ISPs, it is recommended to have one tunnel per ISP that terminates on each of the FortiGates in Azure VWAN hub.

Azure Routing Intents policy for internal and SD-WAN traffic forwards all RFC 1918 destinations to the FortiGates through an Azure load balancer floating IP address. The load balancer only validates that the FortiGate is responsive to probes, but does not validate that a specific tunnel or route is enabled through the FortiGate. As a result, if all tunnels to a specific branch fail through one of the FortiGates, it’s possible for outbound traffic to the branch to be dropped by one FortiGate, but not the other. This appendix offers a solution to dynamically reroute traffic from one FortiGate to the other FortiGate in such a scenario.

Note

If you have changed the default route in any way, review About the dynamic rerouting solution before deploying the CLI scripts. The scripts assume a 0.0.0.0/0 route through port1 of each FortiGate provided by DHCP with an Administrative Distance of 5, which reflects the FortiGates configuration at time of deployment.

The following diagram shows how outbound traffic is dropped by Hub 1 and doesn't reach the branch device.

When the solution described in this appendix is implemented, traffic dynamically reroutes from one FortiGate to the other FortiGate and out to the branch device.

This section includes the following topics:

Dynamic rerouting

Appendix C - Dynamic rerouting

The FortiGate SD-WAN solution in Azure vWAN Hubs is designed for two active FortiGates. It is recommended for each FortiGate to have at least one tunnel to every branch device. If the branch device has multiple ISPs, it is recommended to have one tunnel per ISP that terminates on each of the FortiGates in Azure VWAN hub.

Azure Routing Intents policy for internal and SD-WAN traffic forwards all RFC 1918 destinations to the FortiGates through an Azure load balancer floating IP address. The load balancer only validates that the FortiGate is responsive to probes, but does not validate that a specific tunnel or route is enabled through the FortiGate. As a result, if all tunnels to a specific branch fail through one of the FortiGates, it’s possible for outbound traffic to the branch to be dropped by one FortiGate, but not the other. This appendix offers a solution to dynamically reroute traffic from one FortiGate to the other FortiGate in such a scenario.

Note

If you have changed the default route in any way, review About the dynamic rerouting solution before deploying the CLI scripts. The scripts assume a 0.0.0.0/0 route through port1 of each FortiGate provided by DHCP with an Administrative Distance of 5, which reflects the FortiGates configuration at time of deployment.

The following diagram shows how outbound traffic is dropped by Hub 1 and doesn't reach the branch device.

When the solution described in this appendix is implemented, traffic dynamically reroutes from one FortiGate to the other FortiGate and out to the branch device.

This section includes the following topics: