Troubleshooting Tip: DNS/API issue with an SDN configured FortiGate cluster in Azure, firmware upgrade with default Fortiguard servers

[vvarangoulis]

Description	This article describes the behavior of a FortiGate v6.4 cluster upgrading to 7.0.4 and above with the default FortiGuard DNS server configured, specifically an issue where the public IP (on the Azure side) of the external interface (on the FortiGate side) has not been moved to the correct primary cluster FortiGate member. Note: This article is for a cluster that has been set up with the SDN connector and not with the external/internal Azure load balancers.
Scope	FortiGate 6.4, 7.0, 7.2, 7.4.
Solution	If the aforementioned conditions have been met, the FortiGate cluster will have no external connectivity and cannot resolve DNS names. The reason for these issues is most likely that, after the firmware upgrade from 6.4.x to 7.0.4 and above, the default behavior of the default FortiGuard server setting has changed from cleartext (53) to DoT (DNS over TLS) 853. See the New Features section of the FortiGate 7.0 documentation for more information. This change affects the DNS traffic and, based on the Azure environment setup, will cause DNS issues for the FortiGate when resolving domain names. Consequently, the FortiGate cannot contact the MS/Azure REST API address (management.azure.com) to make the appropriate API calls to move public IPs, route tables, and more. See the About FortiGate VM for Azure section of the FortiGate Azure Administration Guide for more information. As a result, the public IP will still be on the secondary cluster member and not on the primary after the firmware upgrade. If the issue happens, attempt the following steps for a quick fix: trigger a cluster failover to the unit with the public IP, then check if internet connectivity for the unit has been restored (try running execute telnet 8.8.8.8 53). If the external connectivity is restored, just disable the TLS on the DNS settings and check if the DNS servers are reachable. If they are, trigger a secondary failover to revert control to the original primary unit. Before the firmware upgrade, choose to specify the DNS servers and keep the primary FortiGuard server already in place. On the secondary, choose one of the public DNS servers (such as 8.8.8.8 or 1.1.1.1) and ensure the TLS option is disabled. This should prevent the issue of the public IP not being transferred because the FortiGates can make the API calls to Azure and move that public IP. Note: API calls are made from the management port of the FortiGate (commonly port4), which means a public IP is required on that interface. This is designed intentionally. Related documents: FortiGate Active-Passive SDN Azure Template.