You have deployed a FortiGate HA cluster in Azure using a gateway load balancer for traffic inspection. However, traffic is not being routed correctly through the firewalls.
What can be the cause of the issue?
A.
The FortiNet VMs have IP forwarding disabled, which is required for traffic inspection.
B.
The health probes for the gateway load balancer are failing, which causes traffic to bypass the HA cluster.
C.
The gateway load balancer is not associated with the correct network security group (NSG) rules, which allow traffic to pass through.
D.
The protected VMs are in a different Azure subscription, which prevents the gateway load balancer from forwarding traffic.
According to the FortiOS 7.6 Azure Administration Guide and the Cloud Security 7.4 Public Cloud Study Guide, the integration of FortiGate-VMs with an Azure Gateway Load Balancer (GWLB) requires specific network configurations to ensure packet transit:
IP Forwarding Requirement (Option A): By default, Azure Network Interfaces (NICs) drop any traffic that does not originate from or is not destined for the IP address assigned to that NIC. For a FortiGate to act as a "bump-in-the-wire" or transparent inspector, it must receive traffic destined for other IPs and forward it. This requires the IP Forwarding setting to be explicitly enabled on the FortiGate's network interfaces within the Azure portal. If this is disabled, the Azure fabric will discard the traffic being steered through the FortiGate HA cluster by the GWLB.
VXLAN Encapsulation: The Azure GWLB uses VXLAN to encapsulate traffic (adding a VXLAN header with a specific VNI) before sending it to the FortiGate. The FortiGate must terminate this VXLAN tunnel. While the VXLAN configuration is crucial, the underlying infrastructure check for IP Forwarding is the most common cause of traffic being blocked at the NIC level before the FortiOS stack can process the packet.
Why other options are incorrect:
Option B: If health probes fail, the GWLB will typically stop sending traffic to that specific instance. While this affects the HA cluster's availability, the question states traffic is not being routed correctly through the firewalls (implying an active flow issue), and the primary mechanism for allowing a VM to process third-party traffic in Azure is IP Forwarding.
Option C: NSGs are typically applied to the NIC or Subnet. While incorrect NSG rules can block traffic, "IP Forwarding" is a specific requirement for the FortiGate to function as a network appliance (NVA) regardless of the NSG state.
Option D: Azure GWLB supports cross-subscription and cross-tenant chaining. The consumer (protected VMs) and the provider (FortiGate HA cluster) do not need to be in the same subscription, provided the GWLB endpoint is correctly mapped.
Contribute your Thoughts:
Chosen Answer:
This is a voting comment (?). You can switch to a simple comment. It is better to Upvote an existing comment if you don't have anything to add.
Submit