Azure Update Manager can't communicate with VM after routing traffic through FW

Question

Azure Update Manager can't communicate with VM after routing traffic through FW

ShawnO 45

None of my Azure VMs are communicating with Azure update manager since I setup a Fortigate Firewall in my Azure Environment routing all traffic in and out from VMs through it. I setup a route table and added one route for 0.0.0.0/0 traffic to exit out through the firewall for internet traffic. From what I can find Azure documentation says that Azure Update Manager only needs port 443 to access a few sites. https://learn.microsoft.com/en-us/azure/automation/automation-network-configuration#update-management-and-change-tracking-and-inventory . When I unassign the subnet from the route table allowing outbound traffic to go out the default route then update manager starts to work again. What do I need to do either to the route table or firewall to get this working again?

Mohan Krishna T Sreeramulu 280 Reputation points Microsoft External Staff Moderator

2025-05-23T19:50:03.21+00:00

Hi ShawnO,

You mentioned, when you tried unassign the subnet from the route table allowed outbound traffic to go out the default route then update manager starts to work again. usually When you create a virtual network, Azure automatically creates a default Routable for each of its subnets and adds system default routes to the table.

whereas route all traffic to the firewall, you create a user-defined route table that routes all traffic to the firewall and then associate it with the App Service subnet in the integrated virtual network.

App Service outbound traffic control with Azure Firewall - Azure App Service | Microsoft Learn

ensure that the firewall allows outbound traffic to the necessary Azure Update Manager endpoints. As it's mentioned that the Azure documentation indicates that port 443 is required, you should verify that the firewall rules permit traffic on this port to the specific URLs used by Azure Update Manager.

Additionally, check the following:

Verify that the route table associated with your subnet correctly routes traffic to the Fortigate Firewall. The route for 0.0.0.0/0 should direct all internet-bound traffic through the firewall. Ensure that there are no conflicting routes that might be causing issues.

Ensure that the firewall policies allow outbound traffic to the Azure Update Manager endpoints. This includes making sure that the IP addresses for Azure Update Manager are not being blocked.

Network Security Groups (NSGs) If you are using NSGs, make sure that the outbound rules allow traffic on port 443 to the required Azure services.

Since you have a route table directing traffic through the firewall, ensure that the route for 0.0.0.0/0 is correctly configured and does not inadvertently block the required traffic.

After making changes, test the connectivity to the Azure Update Manager endpoints to confirm that the changes have resolved the issue.

Are there any specific error messages in the Azure Update Manager or Fortigate logs that might provide additional insights?

Please check and let us know if you face any issues or have any additional queries. We are happy to assist.

Please Upvote if this information helps!!
Mohan Krishna T Sreeramulu 280 Reputation points Microsoft External Staff Moderator

2025-05-26T14:11:25.0233333+00:00

Hi ShawnO,

Just want to check if the above information worked for you or else please let us know if need any help, we are always here to help whenever you need us.

Please do not forget to “Upvote it” wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others.
ShawnO 45 Reputation points

2025-05-27T14:54:04.6933333+00:00

I can log into a virtual machine that has its traffic routed to the firewall and have no issue browsing the internet. I have no restriction other than filters for bad sites on 443 traffic outbound. When I browse to IP Chicken on the VM, it shows the correct public IP from the firewalls NIC, so I know that traffic is getting routed correctly out through the firewall.
Mohan Krishna T Sreeramulu 280 Reputation points Microsoft External Staff Moderator

2025-05-28T05:37:45.4533333+00:00
Hi ShawnO,

Thank you for your response,
Azure Update Manager doesn't just need internet, it needs to reach specific Azure service endpoints over

HTTPS (port 443). These endpoints are FQDNs (domain names) like

*.ods.opinsights.azure.com

*.oms.opinsights.azure.com

*.azure-automation.net

*.blob.core.windows.net

Even though general 443 traffic is allowed, FortiGate might not be allowing traffic to those specific domains, especially if you're using:

URL filtering or DNS-based filtering

SSL inspection or deep packet inspection, which might break TLS handshakes to Microsoft endpoints

You can cross-verify to get Update Manager working again try these steps,

Allow Required Domains (FQDNs) Through the FortiGate Firewall

Azure Update Manager requires access to specific Microsoft domains. Make sure the firewall allows outbound 443 traffic to these:
Required FQDNs from this document
FYR: Update Management Network Requirements

*.ods.opinsights.azure.com
*.oms.opinsights.azure.com

*.blob.core.windows.net

*.azure-automation.net

*.azure.com

*.windows.net

*.monitoring.azure.com

If FortiGate is using FQDN-based rules, ensure it’s configured to resolve and allow these domains, and that DNS resolution isn’t blocked internally.
You can test connectivity from a VM using PowerShell:

Test-NetConnection -ComputerName ods.opinsights.azure.com -Port 443

Once you allow or bypass inspection for the Update Manager FQDNs, it should start communicating again without needing to remove the route table or firewall.

Please check and let me know if you face any issues or have any additional queries. We are happy to assist.

Please Upvote if this information helps!!
ShawnO 45 Reputation points

2025-05-28T16:44:58.6333333+00:00

I found an error which lead me to realize that the documentation is wrong, It's using Port 80. Once I opened port 80 outbound I was able to push updates to a server.

Could not connect to azure.archive.ubuntu.com:80 (52.252.163.49), connection timed out
Mohan Krishna T Sreeramulu 280 Reputation points Microsoft External Staff Moderator

2025-05-29T05:33:02.9533333+00:00

Hi ShawnO,

Thank you for pointing this out. It's helpful to know that opening outbound traffic for Port 80 resolved the issue. Could you please confirm if enabling this port established communication from the Update Manager to the Server?, Is the issue resolved?

Accepted answer

0 additional answers

Your answer

Mohan Krishna T Sreeramulu 280 Reputation points Microsoft External Staff Moderator

2025-05-26T14:11:25.0233333+00:00

Hi ShawnO,

Just want to check if the above information worked for you or else please let us know if need any help, we are always here to help whenever you need us.

Please do not forget to “Upvote it” wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others.
ShawnO 45 Reputation points

2025-05-27T14:54:04.6933333+00:00

I can log into a virtual machine that has its traffic routed to the firewall and have no issue browsing the internet. I have no restriction other than filters for bad sites on 443 traffic outbound. When I browse to IP Chicken on the VM, it shows the correct public IP from the firewalls NIC, so I know that traffic is getting routed correctly out through the firewall.
Mohan Krishna T Sreeramulu 280 Reputation points Microsoft External Staff Moderator

2025-05-28T05:37:45.4533333+00:00

Hi ShawnO,

Thank you for your response,
Azure Update Manager doesn't just need internet, it needs to reach specific Azure service endpoints over

HTTPS (port 443). These endpoints are FQDNs (domain names) like

*.ods.opinsights.azure.com

*.oms.opinsights.azure.com

*.azure-automation.net

*.blob.core.windows.net

Even though general 443 traffic is allowed, FortiGate might not be allowing traffic to those specific domains, especially if you're using:

URL filtering or DNS-based filtering

SSL inspection or deep packet inspection, which might break TLS handshakes to Microsoft endpoints

You can cross-verify to get Update Manager working again try these steps,

Allow Required Domains (FQDNs) Through the FortiGate Firewall

Azure Update Manager requires access to specific Microsoft domains. Make sure the firewall allows outbound 443 traffic to these:
Required FQDNs from this document
FYR: Update Management Network Requirements

*.ods.opinsights.azure.com
*.oms.opinsights.azure.com

*.blob.core.windows.net

*.azure-automation.net

*.azure.com

*.windows.net

*.monitoring.azure.com

If FortiGate is using FQDN-based rules, ensure it’s configured to resolve and allow these domains, and that DNS resolution isn’t blocked internally.
You can test connectivity from a VM using PowerShell:

Test-NetConnection -ComputerName ods.opinsights.azure.com -Port 443

Once you allow or bypass inspection for the Update Manager FQDNs, it should start communicating again without needing to remove the route table or firewall.

Please check and let me know if you face any issues or have any additional queries. We are happy to assist.

Please Upvote if this information helps!!
ShawnO 45 Reputation points

2025-05-28T16:44:58.6333333+00:00

I found an error which lead me to realize that the documentation is wrong, It's using Port 80. Once I opened port 80 outbound I was able to push updates to a server.

Could not connect to azure.archive.ubuntu.com:80 (52.252.163.49), connection timed out
Mohan Krishna T Sreeramulu 280 Reputation points Microsoft External Staff Moderator

2025-05-29T05:33:02.9533333+00:00

Hi ShawnO,

Thank you for pointing this out. It's helpful to know that opening outbound traffic for Port 80 resolved the issue. Could you please confirm if enabling this port established communication from the Update Manager to the Server?, Is the issue resolved?

Answer 1

Hi ShawnO i review urs issue and all comments so that’s a huge catch! and yep, u’re totally right sometimes the docs don’t keep up with reality :)

so turns out port 80 is in play after all, at least for some ubuntu repos like azure.archive.ubuntu.com. that’s wild because the official docs swear up and down it’s all 443. but hey, real-world troubleshooting wins again! what this means for u

firewall rules gotta allow both 80 and 443 outbound. some repos (especially linux ones) still use http for package metadata before switching to https for downloads.

route tables if u’re still forcing traffic through the fortigate, make sure it’s not blocking or inspecting port 80 traffic. sometimes firewalls get too aggressive and kill plain http even when it’s needed.

double-check ur logs next time something times out, peek at the firewall logs or run a tcpdump on the vm. u’ll see real fast if it’s dying on port 80.

why this happens some linux distros (like ubuntu) still use http for repo metadata (the "what’s new?" list) before downloading packages over https. azure’s docs probably assume everything’s https-only now, but… surprise! legacy stuff hangs around forever )

final fix update firewall rules allow outbound 80/tcp to at least

azure.archive.ubuntu.com
any other repo urls ur vms use (check /etc/apt/sources.list if ur on ubuntu). test with curl from inside the vm, try curl -v http://azure.archive.ubuntu.com if it works, u’re golden. if not, the firewall’s still blocking something.

u just saved urself (and probably a bunch of other folks) a ton of headache. nice work spotting that

(and hey, maybe someone should file a doc bug… just sayin’)))))

Best regards,

Alex

and "yes" if you would follow me at Q&A - personaly thx.
P.S. If my answer help to you, please Accept my answer
PPS That is my Answer and not a Comment

https://ctrlaltdel.blog/

ShawnO 45 Reputation points

2025-05-29T13:05:43.86+00:00

The issue was the NSG was blocking port 80 so nothing was getting logged in the firewall.

Share via

Azure Update Manager can't communicate with VM after routing traffic through FW

0 additional answers

Your answer