FortiGate Next Generation Firewall utilizes purpose-built security processors and threat intelligence security services from FortiGuard labs to deliver top-rated protection and high performance, including encrypted traffic.

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.

- 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 ''.

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 ''.




- 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:
azd api failed, url =<Subscription-ID-Removed-For-Confedetiality>

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
    set secondary <-----


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).