Network Watcher frequently asked questions (FAQ)

Network Watcher provides a suite of tools to monitor, diagnose, view metrics, and enable or disable logs for IaaS (Infrastructure-as-a-Service) resources, which include virtual machines, virtual networks, application gateways, load balancers, and other resources in an Azure virtual network. It isn't a solution for monitoring PaaS (Platform-as-a-Service) infrastructure or getting web/mobile analytics.

Network Watcher provides three major sets of capabilities:

• Monitoring
  • Topology view shows you the resources in your virtual network and the relationships between them.
  • Connection monitor allows you to monitor connectivity and latency between endpoints inside and outside Azure.
• Network diagnostic tools
  • IP flow verify allows you to detect traffic filtering issues at a virtual machine level.
  • NSG diagnostics allows you to detect traffic filtering issues at a virtual machine, virtual machine scale set, or application gateway level.
  • Next hop helps you verify traffic routes and detect routing issues.
  • Connection troubleshoot enables a one-time connectivity and latency check between a virtual machine and Bastion host, application gateway, or another virtual machine.
  • Packet capture enables you to capture your virtual machine traffic.
  • VPN troubleshoot runs multiple diagnostics checks on your VPN gateways and connections to help debug issues.
• Traffic
  • Virtual network flow logs and network security group flow logs allow you to log network traffic passing through your virtual networks and network security groups (NSGs) respectively.
  • Traffic analytics processes your network security group flow log data enabling you to visualize, query, analyze, and understand your network traffic.

For more detailed information, see Network Watcher overview.

See Network Watcher pricing for pricing details about different Network Watcher components.

See Network Watcher regions to learn about the regions that support Network Watcher.

See Azure RBAC permissions required to use Network Watcher for a detailed list of required permissions for each of capability of Network Watcher.

The Network Watcher service is automatically enabled for every subscription. You must manually enable Network Watcher if you opted out Network Watcher automatic enablement. For more information, see Enable or disable Azure Network Watcher.

The Network Watcher parent resource is deployed with a unique instance in every region. Default naming format: NetworkWatcher_RegionName. Example: NetworkWatcher_centralus is the Network Watcher resource for the "Central US" region. You can customize the name of Network Watcher instance using PowerShell or REST API.

Network Watcher just needs to be enabled once per a region per a subscription for its features to work. Network Watcher is enabled in a region by creating a Network Watcher instance in that region.

The Network Watcher resource represents the backend service for Network Watcher, which is fully managed by Azure. However, you can create or delete the Network Watcher resource to enable or disable it in a particular region. For more information, see Enable or disable Azure Network Watcher.

No, moving Network Watcher resource or any of its child resources across regions isn't supported. For more information, see Move operation support for networking resources.

Yes, moving Network Watcher resource between resource groups is supported. For more information, see Move operation support for networking resources.

NetworkWatcherRG is a resource group that's automatically created for Network Watcher resources. For example, Network Watcher regional instances and the network security group flow log resources are created in NetworkWatcherRG resource group. You can customize the name of Network Watcher resource group using PowerShell, Azure CLI, or REST API.

Azure Network Watcher doesn't store customer data, except for the Connection monitor. Connection monitor stores customer data, which is automatically stored by Network Watcher in a single region to satisfy in-region data residency requirements.

Network Watcher has the following limits:

Yes, the Network Watcher service is zone-resilient by default.

No configuration is necessary to enable zone-resiliency. Zone-resiliency for Network Watcher resources is available by default and managed by the service itself.

The Network Watcher Agent is required for any Network Watcher feature that generates or intercepts traffic from a virtual machine.

The Connection monitor, Packet capture, and Connection troubleshoot (connectivity test) features require the Network Watcher extension to be present.

The latest version of the Network Watcher extension is 1.4.3614.3. For more information, see Update Azure Network Watcher extension to the latest version.

• Linux: the Network Watcher Agent uses available ports starting from port 50000 until it reaches port 65535.
• Windows: the Network Watcher Agent uses the ports that the operating system responds with when queried for available ports.

The Network Watcher Agent requires outbound TCP connectivity to 169.254.169.254 over port 80 and 168.63.129.16 over port 8037. The agent uses these IP addresses to communicate with the Azure platform.

No, connection monitor doesn't support classic VMs. For more information, see Migrate IaaS resources from classic to Azure Resource Manager.

Topology can be decorated from non-Azure to Azure only if the destination Azure resource and the connection monitor resource are in the same region.

The same Azure VM can't be used with different configurations in the same connection monitor. For example, using same VM with a filter and without a filter in the same connection monitor isn't supported.

Issues that are displayed on the connection monitor dashboard are found during topology discovery or hop exploration. There can be cases where the threshold set for % loss or RTT is reached but no issues are found on hops.

There's no protocol selection option in connection monitor (classic). Tests in connection monitor (classic) only use the TCP protocol, and that's why, during the migration, we create a TCP configuration in tests in the new connection monitor.

There's currently a regional boundary when an endpoint uses Azure Monitor and Arc agents with the associated Log Analytics workspace. As a result to this limitation, the associated Log Analytics workspace must be in the same region as the Arc endpoint. Data ingested into individual workspaces can be unionized for a single view, see Query data across Log Analytics workspaces, applications, and resources in Azure Monitor.

Flow logs enable you to log 5-tuple flow information about your Azure IP traffic that passes through a network security group or Azure virtual network. The raw flow logs are written to an Azure storage account. From there, you can further process, analyze, query, or export them as needed.

Flow log data is collected outside the path of your network traffic, so it doesn't affect network throughput or latency. You can create or delete flow logs without any risk of impact to network performance.

Network security group flow logs log traffic flowing through a network security group. On the other hand, NSG diagnostics returns all network security groups that your traffic is traversing and the rules of each network security group that are applied to this traffic. Use NSG diagnostics to verify that your network security group rules are being applied as expected.

No, network security group flow logs don't support ESP and AH protocols.

No, network security group flow logs and virtual network flow logs don't support ICMP protocol.

Yes. The associated flow log resource will be deleted too. Flow log data is retained in the storage account for the retention period configured in the flow log.

Yes, but you must delete the associated flow log resource. After you migrate the network security group, you can re-create the flow logs to enable flow logging on it.

Yes, you can use a storage account from a different subscription as long as this subscription is in the same region of the network security group and associated with the same Microsoft Entra tenant of the network security group or virtual network's subscription.

To use a storage account behind a firewall, you have to allow trusted Azure services to access your storage account:

1. Go to the storage account by entering the storage account's name in the search box at the top of the portal.
2. Under the Security + networking, select Networking, then select Firewalls and virtual networks.
3. In Public network access, select Enabled from selected virtual networks and IP addresses. Then under Exceptions, check the box next to Allow Azure services on the trusted services list to access this storage account.
4. Enable flow logs by creating a flow log for your target resource using the storage account. For more information, see Create a flow log.

You can check the storage logs after a few minutes. You should see an updated TimeStamp or a new JSON file created.

Network Watcher has a built-in fallback mechanism that it uses when connecting to a storage account behind a firewall (firewall enabled). It tries to connect to the storage account using a key, and if that fails, it switches to a token. In this case, a 403 error is logged in the storage account activity log.

Yes, Network Watcher supports sending flow logs data to a storage account enabled with a private endpoint.

Flow logs are compatible with service endpoints without requiring any extra configuration. For more information, see Enable a service endpoint.

Flow logs version 2 introduces the concept of flow state and stores information about bytes and packets transmitted. For more information, see Network security group flow log format.

No, a read-only lock on a network security group prevents the creation of the corresponding network security group flow log.

Yes, a cannot-delete lock on the network security group doesn't prevent the creation or modification of the corresponding network security group flow log.

Yes, you can automate network security group flow logs via Azure Resource Manager templates (ARM templates). For more information, see Configure NSG flow logs using an Azure Resource Manager (ARM) template.

Yes, virtual networks and network security groups can be in different regions than your Log Analytics workspace region.

Yes.

In the resource selection dropdown in the traffic analytics dashboard, the resource group of the Virtual Network resource must be selected, not the resource group of the virtual machine or network security group.

Traffic analytics performs a resource discovery scan every 6 hours to identify new VMs, NICs, virtual networks, and subnets. When a new VM or NIC is created after the most recent discovery cycle, and flow data is collected before the next discovery, traffic analytics can't yet associate the traffic with a known resource. As a result, those resources are temporarily labeled as unknown in the analytics view.

Yes, you can disable public access to restrict public inbound traffic to the DCE resource.

Yes. If you select an existing workspace, make sure that it was migrated to the new query language. If you don't want to upgrade the workspace, you need to create a new one. For more information about Kusto Query Language (KQL), see Log queries in Azure Monitor.

Yes, your Azure storage account can be in one subscription, and your Log Analytics workspace can be in a different subscription.

Yes. You can configure flow logs to be sent to a storage account located in a different subscription, provided you have the appropriate privileges, and that the storage account is located in the same region as the network security group (network security group flow logs) or virtual network (virtual network flow logs). The destination storage account must share the same Microsoft Entra tenant of the network security group or virtual network.

No. All resources must be in the same tenant including network security groups (network security group flow logs), virtual networks (virtual network flow logs), flow logs, storage accounts and Log Analytics workspaces (if traffic analytics is enabled).

Yes.

Traffic Analytics workbooks are powered by Log Analytics queries. If the query exceeds limits for log analytics, the workbook could present low memory errors. To improve performance and reduce low memory errors, users can use Dedicated Log Analytics Clusters.

No. If you delete the storage account that is used for flow logs, the data stored in Log Analytics workspace won't be affected. You can still view historic data in Log Analytics workspace (some metrics will be impacted) but traffic analytics will no longer process any new flow logs until you update the flow logs to use a different storage account.

Select a supported region. If you select a non-supported region, you receive a "Not found" error. For more information, see Traffic analytics supported regions.

The Microsoft.Insights provider must be registered for flow logging to work properly. If you aren't sure whether the Microsoft.Insights provider is registered for your subscription, see Manage NSG flow logs instructions on how to register it.

The dashboard might take up to 30 minutes to show reports for the first time. The solution must first aggregate enough data for it to derive meaningful insights, then it generates reports.

Try the following options:

• Change the time interval in the upper bar.
• Select a different Log Analytics workspace in the upper bar.
• Try accessing traffic analytics after 30 minutes, if it was recently enabled.

You might see this message because:

• Traffic analytics was recently enabled, and might not yet have aggregated enough data for it to derive meaningful insights.
• You're using the free version of the Log Analytics workspace, and it exceeded the quota limits. You might need to use a workspace with a larger capacity.

Try the suggested solutions for the previous question. If problems persist, raise concerns in Microsoft Q&A.

You're seeing the resources information on the dashboard; however, no flow-related statistics are present. Data might not be present because of no communication flows between the resources. Wait for 60 minutes, and recheck status. If the problem persists, and you're sure that communication flows among resources exist, raise concerns in Microsoft Q&A.

Traffic analytics is metered. The metering is based on processing of raw flow log data by the service. For more information, see Network Watcher pricing.
Enhanced logs ingested in Log Analytics workspace can be retained at no charge for up to first 31 days (or 90 days if Microsoft Sentinel is enabled on the workspace). For more information, see Azure Monitor pricing.

Default processing interval of traffic analytics is 60 minutes, however, you can select accelerated processing at 10 minutes intervals. For more information, see Data aggregation in traffic analytics.

Traffic analytics creates and manages data collection rule (DCR) and data collection endpoint (DCE) resources in the same resource group as the workspace, prefixed with NWTA. If you perform any operation on these resources, traffic analytics might not function as expected. For more information, see Data aggregation in traffic analytics. For more information, see Data collection rules in Azure Monitor and Data collection endpoints in Azure Monitor.

It is not recommended to apply locks to DCR and DCE resources created by traffic analytics as these resources are managed by the service. Notably, locked resources would not be cleaned up upon deletion of the related flow logs. If you perform any operation on these resources, traffic analytics might not function as expected. For more information, see Data aggregation in traffic analytics.

Traffic analytics relies on Microsoft internal threat intelligence systems to deem an IP as malicious. These systems use diverse telemetry sources like Microsoft products and services, the Microsoft Digital Crimes Unit (DCU), the Microsoft Security Response Center (MSRC), and external feeds and build intelligence on top of it. Some of this data is Microsoft Internal. If a known IP is getting flagged as malicious, create a support ticket to know the details.

Traffic analytics doesn't have built-in support for alerts. However, since traffic analytics data is stored in Log Analytics, you can write custom queries and set alerts on them. Follow these steps:

• You can use Log Analytics link in traffic analytics.
• Use the traffic analytics schema to write your queries.
• Select New alert rule to create the alert.
• See Create a new alert rule to create the alert.

Yes. Connection troubleshoot and NSG diagnostics don't support private Application Gateway deployments. For more information, see Private Application Gateway deployment.