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
  • NSG flow logs and VNet flow logs (preview) allow you to log network traffic passing through your network security groups (NSGs) and virtual networks respectively.
  • Traffic analytics processes your NSG 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 NSG 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 Packet capture, Connection troubleshoot and Connection monitor features require the Network Watcher extension to be present.

The latest version of the Network Watcher extension is 1.4.3206.1. 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.

NSG 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, NSG flow logs don't support ESP and AH protocols.

No, NSG flow logs and VNet 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 provide an exception for Trusted Microsoft 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 NSG flow logs by creating a flow log for your target network security group 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 NSG flow logs data to a storage account enabled with a private endpoint.

NSG 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 NSG flow log format.

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

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

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