About the dynamic rerouting solution

Encapsulation is required to route packets from one FortiGate directly to another FortiGate in Azure. Otherwise the Azure Fabric reroutes based on the destination address of the packet, creating a loop in this scenario. Thus, we use VXLAN as a lightweight tunnel between the two FortiGates.

BGP and route reflection are configured to dynamically update routes within the VXLAN tunnel. However, since this is all internal BGP, it is necessary to prefer those routes coming from the VPN (rather than the local peer). BGP weight is used to give priority to those routes received from the VPN.

Even with BGP dynamically providing routes between the two local FortiGates in Azure vWAN Hub, a problem still exists because both FortiGates always have Azure routes designated through their internal interface (port2). Thus, if traffic gets rerouted through the VXLAN interface, it will fail RPF (reverse path forwarding) when it gets to the second FortiGate. To get around this and to allow symmetric flow of the return traffic, a valid, but not preferred route for any packet that may come via VXLAN on either FortiGate is needed. A static default route with the same Administrative Distance as the existing default route (received via DHCP on port1), but with a reduced priority can be used to provide this return route. The reduced priority at the same AD installs the route in the route table, but it is only used for RPF and existing sessions. Any new sessions requiring the default route, will use the better priority default received via DHCP.

Finally, policies to allow traffic to flow from port2 to VXLAN, VXLAN to IPsec tunnel, and the reverse are needed. For policy samples, see Policy deployment. Keep in mind that policies must be specifically determined by your security policy and use the correct filters and profiles.