FortiGate
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.
pathik_mehta
Staff
Staff
Article Id 350964
Description This article describes a probable reason why the SDN connector is not connecting due to a DNS lookup failure.
Scope FortiGate.
Solution

The FortiGate firewall A-P cluster is deployed in Azure. The port configuration is as follows:

 

Port1: WAN

Port2: LAN

Port3: HA

Port4: MGMT

 

HA config:

 

config system ha

    set group-id 5
    set group-name "AzureHA"
    set mode a-p
    set hbdev "port3" 100
    set session-pickup enable
    set session-pickup-connectionless enable
    set ha-mgmt-status enable
        config ha-mgmt-interfaces
            edit 1
                set interface "port4"
                set gateway 172.29.220.1
            next
        end
    set override enable
    set priority 150
    set unicast-hb enable
    set unicast-hb-peerip 172.29.220.69
end

 

The issue is that the SDN connector shows as down in the GUI. The SDN connector configuration, shown below, appears to be fine:

 

config system sdn-connector

    edit "AzureSDN"

        set status disable
        set type azure

    next

    edit "AZ-SDN"

        set type azure

        set use-metadata-iam disable

        set tenant-id "035694e9-xxxx-xxxx-xxxx-24fce088b110"

        set client-id "478c681e-xxxx-xxxx-xxxx-ffb9c014a269"

    next
end

 

As per the usual behavior, port 4 serves as out-of-band management port managed by vsys_hamgmt VDOM. This interface could not be used for routing or policy configuration. Additionally DNS servers must be accessible through the management interface.

During troubleshooting, to check the correct VDOMs assigned to ports and display all VDOMs(including hidden VDOMs):

 

diagnose sys vd list

To check if port 4 has internet access and DNS resolution:

 

execute enter vsys_hamgmt
execute ping 8.8.8.8
execute ping management.azure.com

 

To identify why the SDN connector remains down, collect the following debug output:


diagnose debug reset
diagnose debug application azd -1
diagnose debug console timestamp enable
diagnose debug enable

 

The following is the debug output:


2024-08-25 13:01:07 azd sdn connector AZ-SDN prepare to update
2024-08-25 13:01:07 azd sdn connector AZ-SDN getting token
2024-08-25 13:02:32 curl DNS lookup failed: management.azure.com
2024-08-25 13:02:32 azd api failed, url = https://management.azure.com/subscriptions?api-version=2021-04-01, rc = -1

2024-08-25 13:02:32 azd failed to list subscriptions
2024-08-25 13:02:32 curl DNS lookup failed: login.microsoftonline.com
2024-08-25 13:02:32 -1

2024-08-25 13:02:32 get token failed for resource: https://management.azure.com
2024-08-25 13:02:32 azd sdn connector AZ-SDN failed to get token

 

From the above debug output, the DNS lookup failed, which resulted in the SDN connector being down.

 

When the SDN connector is initiating the DNS lookup query, it will always go out via the management interface i.e. port4 in this case. Even though the DNS servers under Network -> DNS show as reachable, the DNS servers must be reachable through the management interface as well.

 

Packet capture on the management interface can be taken to confirm whether DNS reply packets are coming back or not.

If not, it is necessary to check the routing from the Azure side. If there is no public IP address associated with port 4 in Azure or if there is any outbound rule for the Internet access traffic, port 4 will not be able to connect to the Internet so the DNS query will fail.

 

Note:

Further communication to management.azure.com on port 443 is also going via port 4 and should have outbound internet access as during the connection between SDN connector and Azure API management, multiple queries will be executed. The first query of SDN connector is targeted to special address 169.254.169.254 to get a token in order to interact with Azure management API and other queries are made to manage public IP and routing table update.