Troubleshooting Tip: Internal DNS behind FortiGate on the Azure, prevents the HA failover from Master to Slave

[Hassan09]

Description	This article describes how to resolve the issue with internal DNS causing the HA failover from primary to secondary VM on Azure to fail.
Scope	FortiOS.
Solution	- Internal DNS is deployed on Azure, and FortiGate virtual appliance is securing, the inbound and outbound traffic of the DNS server. - When the Internal DNS server is used as the primary and secondary DNS server under DNS settings on the FortiGate, the Failover is not working. -During the failover, FortiGate will interact with Azure API through the Management interface (port4). FortiGate will use the MGMT interface to send a DNS query for resolving Azure Rest API 'management.azure.com'. Since the DNS server is temporarily not reaching outside due to the failover, the DNS resolution for the Azure API will not work. As result moving resources such as cluster IP, other Public IPs, and UDR between instances will fail. - DNS query for the Azure Rest API 'management.azure.com'. - Azure debug output: FGTHA-FGT-B # HA event HA state: primary getting metadata token token size: 1480 token expire in: 83014 seconds Azure vm resource group:FGTHA Azure vm subscription:<Subscription-ID-Removed-For-Confedetiality> AzureSDN: resourcegroup: FGTHA, sub: <Subscription-ID-Removed-For-Confedetiality> Disable interface: port1 Disable interface: port2 get pubip FGTAPClusterPublicIP in resource group FGTHA curl DNS lookup failed: management.azure.com azd api failed, url = https://management.azure.com/subscriptions/<Subscription-ID-Removed-For-Confedetiality> /resourceGroups/FGTHA/providers/Microsoft.Network/publicIPAddresse s/FGTAPClusterPublicIP?api-version=2021-04-01, rc = -1  -There are two solutions for this issue: 1) Use public DNS as a secondary DNS server and keep internal one as primary:  # config system dns     set primary 10.1.73.7     set secondary 8.8.8.8 <----- end 2) Locate the internal DNS server to a different subnet than the internal one, then route the outside traffic directly to the Internet (Next hop type Internet, for virtual network traffic routing), instead of FortiGate.  (The second solution should be avoided since the internal Server will be exposed to the outside. FortiGate will provide a complete set of security functionalities that will ensure the virtual machine workloads including internal DNS and data are protected, and the capabilities that the FortiGate enables are different from native security features such as Security Groups, port-based firewalls, and so on).