On the Azure platform and the FortiGate-VM, the private IP addresses of both interfaces are configured using static assignment using deployment.
In the static routing, a default route has been configured towards the default gateway of the external network on port1. All internal networks are routed to the internal/transit network on port2. The gateway IP address on the Microsoft side is always the first IP address in the subnet IP address range.
Azure uses the 18.104.22.168 address for various services. You can configure an additional route to ensure that this traffic always leaves via port1. See What is IP address 22.214.171.124?
During deployment, a route table is created and attached to the protected subnet. This routing table contains three user-defined routes. The default route 0.0.0.0/0 points to the FortiGate-VM internal IP address. This catches all traffic except for the virtual network traffic and sends it to the FortiGate-VM for inspection.
The virtual network is created as well and forces traffic for additional protected networks to pass through the FortiGate-VM. As Azure applies these subnet routes to each VM, an additional route is needed for the local subnet to send its traffic directly to the VNet. If this route is omitted, you will have microsegmentation sending all traffic between the VMs in the protected subnet also via the FortiGate-VM.
If no internal segmentation is required, you can delete the VNet routes.
Verify that the route table is attached to the ProtectedSubnet. Also ensure that the UDR routes include the destination networks.
To verify and troubleshoot routing, the effective route tables can be requested from each network interface of a running VM. The screenshot shows that the default routes have been invalidated by the UDR deployed within the FortiGate.