We have a custom analytics solution that sends telemetry data to a Log Analytics workspace from VMs in a locked-down subnet. After implementing network security hardening, data ingestion started failing with connection timeout errors. The application logs show attempts to reach the workspace endpoint are being blocked.
Our VMs use the Log Analytics agent to send custom logs and performance metrics. The workspace was working fine before we applied restrictive NSG rules and enabled the workspace firewall. Now we’re seeing gaps in our monitoring data which is critical for compliance reporting.
The workspace firewall is configured to allow access from specific VNets, and we’ve added our application subnet to the allowed list:
Workspace: law-prod-analytics
Public network access: Enabled from selected networks
Allowed VNets: vnet-apps (subnet: snet-analytics-10.5.2.0/24)
Despite this configuration, the Log Analytics agent on VMs reports ‘Unable to connect to workspace’ errors. Is there a specific requirement for subnet access or private endpoint configuration that we’re missing?
You have a few options depending on your security requirements. If you enable ‘Public network access’ on the workspace and add your VNet’s public IP range to the firewall rules, that might work if your VMs are using NAT to reach the internet. However, this isn’t ideal from a security perspective. The better approach is definitely private endpoints, but I understand that adds complexity. Another consideration: make sure your NSG rules aren’t blocking the specific FQDNs that Log Analytics uses. The agent needs to reach multiple endpoints, not just the workspace URL.
I checked the NSG rules and we do have an outbound allow rule for HTTPS to the AzureMonitor service tag. The rule has priority 150 which should be evaluated before our default deny rule at priority 4096. However, I’m still seeing connection failures in the agent logs. Could there be an issue with how the workspace firewall interprets the subnet access? The workspace shows the subnet as allowed in the portal.
Log Analytics workspace firewall rules work differently than storage account firewalls. When you enable firewall restrictions on a workspace, you’re controlling access to the workspace API, but the data ingestion endpoint (ods.opinsights.azure.com) is separate. You might need to configure both the workspace firewall and ensure your NSG rules allow outbound HTTPS (443) to the AzureMonitor service tag.
One thing to note about Log Analytics workspace firewalls: they don’t support VNet service endpoints like storage accounts do. If you need to restrict access to the workspace from specific VNets, you have to use Azure Private Link with private endpoints. The ‘Allowed VNets’ setting in the workspace firewall is actually for controlling access through public endpoints, not for VNet integration. This might be causing your confusion.