Azure Firewall
An Azure network security service that is used to protect Azure Virtual Network resources.
Hello,
After the upgrade to 7.6.8 Azure FTG - SDN communication has been restored!
Thanks to Alex for the help!
troubleshooting an Azure SDN Connector issue on a FortiGate HA cluster running in Azure.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(76.8, 25%, 17%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EDT%3C/text%3E%3C/svg%3E)
Dimitrov, Todor
0
Reputation points
I've gotten timeout:
2026-10-24 11:16:47 azd connection timeout: 169.254.169.254:80:169.254.169.254
2026-10-24 11:16:47 azd curl retry
2026-10-24 11:17:02 azd connection timeout: 169.254.169.254:80:169.254.169.254
2026-10-24 11:17:02 azd curl retry
2026-10-24 11:17:17 azd connection timeout: 169.254.169.254:80:169.254.169.254
2026-10-24 11:17:17 azd show instance metadata error.
2026-10-24 11:17:22 azd getting instance metadata
2026-10-24 11:17:32 azd connection timeout: 169.254.169.254:80:169.254.169.254
2026-10-24 11:17:32 azd curl retry
2026-10-24 11:17:47 azd connection timeout: 169.254.169.254:80:169.254.169.254
2026-10-24 11:17:47 azd curl retry
2026-10-24 11:18:02 azd connection timeout: 169.254.169.254:80:169.254.169.254
2026-10-24 11:18:02 azd curl retry
DNS is working
LSPFRGAZU402-FGT-A # execute enter vsys_hamgmt
current vdom=vsys_hamgmt:1
LSPFRGAZU402-FGT-A # execute ping management.azure.com
PING arm-frontdoor-edge-geo.trafficmanager.net (4.150.240.10): 56 data bytes
^C
--- arm-frontdoor-edge-geo.trafficmanager.net ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss
LSPFRGAZU402-FGT-A # execute telnet 4.150.240.10 443
Trying 4.150.240.10...
Connected to 4.150.240.10.
Connection closed by foreign host.
There isn't any nsg rule which can block the traffic.
Azure Firewall
-
Dimitrov, Todor 0 Reputation points
2026-10-24T09:38:40.7933333+00:00 when trying i see fortigate is sourcing with mgmt interface
-
Dimitrov, Todor 0 Reputation points
2026-10-24T12:47:32.7566667+00:00 Update:
I built a lab environment and deployed two new FortiGate VMs in Azure configured with Azure SDN connector and public IP failover. During my testing, I noticed different behavior compared to the production cluster.
On the lab deployment, when the FortiGate accesses the Azure Instance Metadata Service (
169.254.169.254), the traffic is sourced through port1 and the TCP connection is established successfully.However, on the production cluster, the same request is sourced through port4 (HA management interface) and times out with repeated SYN retransmissions and no SYN/ACK response.
Sign in to comment
Answer recommended by moderator
2 additional answers
Sort by: Most helpful
-
Alex Burlachenko 26,700 Reputation points MVP Volunteer Moderator2026-10-25T16:27:43.9433333+00:00 Hi Dimitrov, Todor & thx for join me at Q&A platform,
logs actually point to a fairly specific issue. FortiGate's Azure daemon (azd) is timing out while trying to reach Azure Instance Metadata Service (IMDS) at 169.254.169.254:80.
That's different from a connectivity problem with management.azure.com.
Your successful TCP connection to 4.150.240.10:443 confirms that the FortiGate can establish a connection to Azure Resource Manager, but it doesn't tell us whether IMDS is reachable. The failed ping isn't particularly meaningful either, as ICMP responses aren't required for ARM API connectivity.
I'd focus on the interface and source IP FortiGate is using to reach IMDS.
Azure requires IMDS requests to originate from the VM's primary NIC and primary IP. This is especially relevant in FortiGate HA deployments, where multiple interfaces, a dedicated HA management VDOM, and additional routing tables can affect locally generated traffic.
Fortinet has documented this exact azd connection timeout: 169.254.169.254:80 error. One known cause is FortiGate sending IMDS requests through an interface other than the Azure VM's primary NIC, typically port1.
Start by checking the actual traffic path:
diagnose sniffer packet any 'host 169.254.169.254 and port 80' 4 0 a
Run this while the azd daemon is attempting to retrieve metadata. Check which interface the packets leave through and whether any responses arrive.
I'd also check the routing table in the VDOM responsible for that traffic:
get router info routing-table all
Then compare the selected interface and source IP against the primary NIC and primary private IP configured on the Azure VM, not just the interface you normally use for HA management.
If the traffic is leaving through the wrong interface, Fortinet documents adding a specific /32 static route for 169.254.169.254 through the Azure gateway associated with port1.
The important part is to use the correct gateway and routing context for your deployment. I wouldn't add that route blindly on a production HA pair, particularly if the two nodes have different interface or management routing configurations.
Also, IMDS uses HTTP port 80, not HTTPS 443. It is a host-local Azure service, so ordinary internet connectivity tests and the absence of blocking NSG rules don't establish that IMDS is working.
Once IMDS connectivity is restored, you can investigate Azure SDN connector authentication, managed identity, or service principal permissions if errors remain. But those aren't the first things I'd change while the daemon can't even retrieve instance metadata.
You can also check the agent state with diagnose debug cloudinit show and capture additional details using diagnose debug application azd -1. Does the packet capture show IMDS traffic leaving through port1, the HA management interface, or another interface? And is this happening on both FortiGate nodes or only the active/primary unit?
That should help determine whether you're dealing with an incorrect local route, source IP selection, or a more specific Azure host connectivity problem.
rgds,
Alex
p.s. if my answer is help - pls mark it as an answer
-
Dimitrov, Todor 0 Reputation points
2026-10-25T19:34:23.74+00:00 Hi Alex,
Thanks for the guidance.
What I’m seeing is that the traffic towards 169.254.169.254:80 is actually leaving through the HA management interface (port4) rather than through port1.
LSPFRGAZU402-FGT-A # diagnose sniffer packet any " host 169.254.169.254 " 4 0 a
Using Original Sniffing Mode
interfaces=[any]
filters=[ host 169.254.169.254 ]
2026-10-25 19:19:54.195502 port4 out 192.168.201.196.9450 -> 169.254.169.254.80: syn 2995001506
2026-10-25 19:19:54.195507 sriovslv3 out 192.168.201.196.9450 -> 169.254.169.254.80: syn 2995001506
2026-10-25 19:19:55.197132 port4 out 192.168.201.196.9450 -> 169.254.169.254.80: syn 2995001506
2026-10-25 19:19:55.197136 sriovslv3 out 192.168.201.196.9450 -> 169.254.169.254.80: syn 2995001506
After entering the HA management context, the routing table only contains the directly connected subnet on port4 and no additional routes. I am also unable to create static routes in this routing context. This seems to explain why the IMDS requests sourced from port4 cannot reach 169.254.169.254.
LSPFRGAZU402-FGT-A # execute enter vsys_hamgmt
current vdom=vsys_hamgmt:1
LSPFRGAZU402-FGT-A # get router info routing-table details
Codes: K - kernel, C - connected, S - static, R - RIP, B - BGP
O - OSPF, IA - OSPF inter area N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2 E1 - OSPF external type 1, E2 - OSPF external type 2 i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area V - BGP VPNv4 * - candidate defaultRouting table for VRF=0
C 192.168.201.192/27 is directly connected, port4
I did some additional investigation in the HA management VDOM (vsys_hamgmt). The routing table does contain a default route via port4 (192.168.201.193), so the issue does not appear to be a missing route. However, packet captures show that azd-generated IMDS traffic is sourced from the HA management interface (192.168.201.196 on port4). In my lab environment, using the same SDN configuration, IMDS traffic is sourced from port1, which is the Azure primary NIC, and the SDN connector works correctly. This leads me to believe the problem is not route reachability but rather the interface/source IP selected by azd when accessing IMDS. Could there be any known condition that causes azd to prefer the HA management interface instead of the Azure primary NIC?
LSPFRGAZU402-FGT-A # diagnose ip route list
tab=255 vf=1 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/32 pref=127.0.0.1 gwy=0.0.0.0 dev=17(vsys_hamgmt)
tab=255 vf=1 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.0/8 pref=127.0.0.1 gwy=0.0.0.0 dev=17(vsys_hamgmt)
tab=255 vf=1 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.0.0.1/32 pref=127.0.0.1 gwy=0.0.0.0 dev=17(vsys_hamgmt)
tab=255 vf=1 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->127.255.255.255/32 pref=127.0.0.1 gwy=0.0.0.0 dev=17(vsys_hamgmt)
tab=255 vf=1 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.201.192/32 pref=192.168.201.196 gwy=0.0.0.0 dev=7(port4)
tab=255 vf=1 scope=254 type=2 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.201.196/32 pref=192.168.201.196 gwy=0.0.0.0 dev=7(port4)
tab=255 vf=1 scope=253 type=3 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.201.223/32 pref=192.168.201.196 gwy=0.0.0.0 dev=7(port4)
tab=254 vf=1 scope=0 type=1 proto=18 prio=0 0.0.0.0/0.0.0.0/0->0.0.0.0/0 pref=0.0.0.0 gwy=192.168.201.193 dev=7(port4)
tab=254 vf=1 scope=253 type=1 proto=2 prio=0 0.0.0.0/0.0.0.0/0->192.168.201.192/27 pref=192.168.201.196 gwy=0.0.0.0 dev=7(port4)
-
Alex Burlachenko 26,700 Reputation points MVP Volunteer Moderator
2026-10-26T07:57:36.2266667+00:00 Hi again Dimitrov, Todor,
thx for the detailed follow-up. This capture actually narrows things down quite a bit.You're right, the default route isn't missing. Your diagnose ip route list output confirms that vsys_hamgmt has a default route through 192.168.201.193 on port4.
The problem is that azd is sending IMDS requests with source IP 192.168.201.196, which belongs to port4. Azure IMDS requires requests to originate from the VM's primary NIC and primary IP, so the missing SYN/ACK is consistent with that restriction.
There's an important Fortinet-specific detail here, tho.
Fortinet actually documents that Azure HA clusters use the reserved HA management interface (typically port4) for SDN connector communication with Azure Resource Manager. So seeing azd use port4 isn't necessarily a misconfiguration by itself.
The conflict is that ARM communication over HTTPS can work through port4, while IMDS access has the additional Azure primary-NIC requirement.
This also explains why your lab works with port1 but production doesn't.
I'd compare the FortiOS versions and build numbers, HA configuration, and SDN connector authentication settings between the two environments. In particular, check ha-mgmt-status, ha-direct, the reserved management interface configuration, and use-metadata-iam.
These settings may help explain the different local-out behavior, although I wouldn't assume any single one is responsible without comparing the configurations.
Fortinet also documents using a specific /32 route to IMDS through port1 when the wrong interface is selected. However, your capture suggests that azd may be operating in the HA management routing context. Adding a route in the regular VDOM won't necessarily override the source interface selected by a process using vsys_hamgmt.
I wouldn't disable HA management, change ha-direct, or modify production routing just to test this. Those changes could affect SDN failover and management connectivity.
At this point, I'd involve Fortinet TAC with both the working lab and production captures. The specific question for them is whether your FortiOS build supports directing azd IMDS requests through port1 while retaining port4 for Azure ARM communication, or whether this is a known HA local-out routing issue.
You've already isolated the failure to the interface/source selection. I'd focus on that FortiOS behavior rather than NSGs, DNS, or Azure API permissions.
rgds,
Alex
p.s. if my answer is help - pls mark it as an answer
-
Dimitrov, Todor 0 Reputation points
2026-10-26T08:43:21.59+00:00 Hi Alex,
Thank you again for your suggestions.
I opened a case with Fortinet TAC and provided them with the HA configuration, SDN connector configuration, packet captures, routing output, and debug flow results from both environments.
After comparing the working lab and production environments, I found the following:
LAB (FortiOS 7.2.14)
- IMDS traffic is sourced from port1 (172.17.0.4).
- Full TCP handshake with 169.254.169.254 is successful.
- Packet capture shows SYN, SYN/ACK, ACK and subsequent HTTP traffic.
PRODUCTION (FortiOS 7.4.13)
- IMDS traffic is sourced from the HA management interface port4 (192.168.201.196) within vsys_hamgmt.
- Only outbound SYN packets are seen.
- No SYN/ACK is ever received from 169.254.169.254.
- Routing exists in vsys_hamgmt and debug flow does not show any routing, policy, or local-in drops.
One notable configuration difference is that production has:
set ha-direct enablewhile the lab environment does not.
Based on the captures, the biggest difference appears to be the source interface selection. The lab uses port1 and successfully reaches IMDS, while production uses port4 and never receives a response.
I have asked Fortinet whether:
- this behavior is expected in FortiOS 7.4.x,
- ha-direct can influence azd source interface selection,
- and whether there is a supported method to force SDN connector / IMDS traffic to use port1 while keeping Azure ARM communication on the HA management interface.
I will update the thread once TAC responds.
Regards,
Todor
-
Dimitrov, Todor 0 Reputation points
2026-10-29T11:24:40.9533333+00:00 We believe we have identified the cause of the Azure IMDS connectivity issue.
We reproduced the behavior in our FortiOS 7.4.13 lab. When global
ha-directis enabled, the FortiGate sends the Azure IMDS traffic destined for169.254.169.254through the HA Reserved Management Interface (port4).This causes the IMDS communication to fail. In the packet capture, we can see the TCP SYN packets leaving through port4, followed by repeated SYN retransmissions, but no SYN-ACK is received. Eventually, the IMDS connection times out.
When global
ha-directis disabled, the IMDS traffic is no longer forced through the HA management path.
Sign in to comment -
-
Dimitrov, Todor 0 Reputation points
2026-10-30T08:23:13.45+00:00 Based on Fortinet’s investigation, the IMDS issue appears to be related to FortiOS 7.4.13, where the IMDS traffic is incorrectly reverting to the HA management interface (port4). Fortinet confirmed that this behavior is not seen in the 7.6 branch and recommended upgrading to version 7.6.8.
We are therefore planning to upgrade the FortiGate cluster to FortiOS 7.6.8 rather than changing the current
ha-directdesign. Once the upgrade is completed, we will validate the Azure SDN connector and specifically check whether the IMDS communication is working correctly.We will provide an update after the upgrade and testing are completed.