Primer on Azure Network Watcher
Updated: Oct 31, 2021
Network Watcher is a set of tools you can use to monitor, diagnose, view metrics, and enable logs for resources that reside in your Virtual Networks. Network Watcher is designed to help you with networking for your IaaS-based resources (Virtual Machines, Virtual Networks, Application Gateways, etc.). Network Watcher will not help you with any PaaS-based resources.
A Network Watcher resource is automatically created for you in each Subscription that has a Virtual Network. Azure will create a Resource Group called "NetworkWatcherRG" and inside that it will create the Network Watcher resource called "NetworkWatcher_region" (where 'region' is the Azure Region where your Virtual Network resides). If you have multiple Virtual Networks spread across multiple Regions, then you'll see multiple Network Watcher resources, one for each Region.
If you wish, you can disable this automatic Network Watcher creation by using some Azure PowerShell or Azure CLI commands. But, be careful. If you change your mind and want to turn on the automatic creation again, there's no easy way to do that. You'll have to reach out to Microsoft support and ask them to turn it back on for you.
You also have the option to manually create Network Watcher resources. By utilizing Azure PowerShell or Azure CLI to create Network Watcher, you are given the freedom to choose your own resource name (it doesn't have to be 'NetworkWatcher_region') as well as choose your own Resource Group name (it doesn't have to be 'NetworkWatcherRG').
Okay, so what can Network Watcher do? Actually, it can do quite a bit. In the Portal, the Network Watcher tools are categorized into 4 sections: Monitoring, Network Diagnostic Tools, Metrics, and Logs.
Topology let's you generate a visual diagram of the resources in your Virtual Network, and the relationships between the resources.
Connection Monitor (Classic)
I'm not going to write anything about the Classic Connection Monitor as it is being retired. Microsoft would like you to use the new Connection Monitor experience (described below).
The new Connection Monitor is a big subject by itself. It is designed to replace both the Classic Connection Monitor, and the Network Performance Monitor, which are both being retired.
Connection Monitor helps you monitor communication between two endpoints, or rather, two groups of endpoints. The source group can be made up of Azure VMs and/or non-Azure machines. The destination group can be made up of Azure VMs, non-Azure machines, or any URL or IP address of your choice. Connection Monitor includes built-in presets for Office 365 and Dynamics 365 URLs to make testing those services quite easy.
Then, you must configure how the source group will talk to the destination group. You start by choosing the protocol, which can be either HTTP, TCP, or ICMP. You'll get various additional settings based on which protocol you select. From there you can select your test frequency, from as short as every 30 seconds, to as high as every 30 minutes. Finally, you must configure percentages and timings that determine when a test is considered to be failed.
The results will be stored in a Log Analytics Workspace. You will have access to Dashboards built upon this data that contain a wealth of information about the connection. You can also configure alerts to be triggered based on thresholds of your choice.
Network Performance Monitor
I'm not going to write anything about NPM as its being retired in 2024. Microsoft would like you to use Connection Monitor instead.
Network Diagnostic Tools
IP Flow Verify
This tool lets you test if a packet is allowed or denied either inbound to or outbound from an Azure VM. You can test traffic based on 5-tuple information (source IP, source port, destination IP, destination port, and protocol, which can be either TCP or UDP). IP Flow Verify will tell you if the traffic is allowed or blocked, and will also show you the associated NSG rule which is controlling the traffic.
This is similar to IP Flow Verify, but is slightly more advanced. This time, you can test traffic inbound to or outbound from a VM, a specific NIC, a VMSS NIC, or an Application Gateway. You get more options when specifying the source traffic as well, for example you can set an IPv4 Address, a IPv4 CIDR range, or an Azure Service Tag. Ultimately, the tool will show you all of the NSGs that will be traversed between both endpoints, the rules that will be applied for each NSG, and whether the traffic will be allowed or denied.
This lets you analyze routing information for traffic from an Azure VM to a destination IP address. It will show you what type of next hop will be used for the traffic, as well as the Route Table that will be used.
Effective Security Rules
Select one of your Azure VMs and this will show you all of the NSG rules that apply to it.
This will run a test against your Virtual Network Gateways and/or your Gateway Connections. You can select multiple resources to troubleshoot them all simultaneously. The testing makes use of an Azure Storage Account so you must provide one of those as well. The test will show you if the Gateway and/or Connection is available and healthy, and if they're not available it will show you why.
This tool allows you to create sessions that will capture traffic into and out of an Azure VM. The captured information can be stored in an Azure Storage Account, on the VM's disk, or both. You can then analyze the data using standard networking tools, such as Wireshark.
This is yet another way to test connectivity between two endpoints and is ever so slightly different than the previous options. The source can be an Azure VM, an Application Gateway, or a Bastion Host. The destination can be an Azure VM, a Uniform Resource Identifier (URI), Fully Qualified Domain Name (FQDN), or an IP Address. Finally, the protocol can be TCP or ICMP.
Usage + Quotas
This will show you the various quotas that are attached to network resources, such as Virtual Networks, IP Addresses, Load Balancers, Route Tables, etc. It will show you how many of each resource you are currently using so that you can easily see how close or far you are from the quota.
NSG Flow Logs
NSG Flow Logs store all traffic that flows through a Network Security Group and stores it in an Azure Storage Account. The data that is captured contains source IP, source port, destination IP, destination port, protocol, and if the NSG allowed or denied the traffic. The data in the Storage Account is in JSON format and can be analyzed using various tools, such as PowerBI. Logs are collected at 1 minute intervals. You can set a maximum retention, in days, that the logs will be kept for, or you can keep them indefinitely.
This will show you a nice summary of the various network-related resources (NSGs, IP Addresses, Load Balancers, etc.) and if you have enabled Diagnostic Logs on each of those resources. This gives you a single interface into all of your networking resources. The alternative would be to go to each resource one-by-one and check whether Diagnostic Logs are enabled or not.
This is an add-on to NSG Flow Logs. Traffic Analytics adds extra intelligence on top of the raw log data captured by NSG Flow Logs. Traffic Analytics provides information such as most communicating hosts, most communicating protocols, most conversing host pairs, allowed/blocked traffic, inbound/outbound traffic, open internet ports, most blocking rules, traffic distribution per Azure datacenter, and more. Traffic Analytics will analyze the NSG Flow Logs from your Storage Account in intervals of either 10 minutes or 60 minutes. The analyzed and summarized data is then stored in a Log Analytics Workspace.
Whew, this turned out to be much longer than expected. At first, I did not plan on explaining each and every tool included with Network Watcher. But, when I got started I just couldn't stop myself.
Hopefully you got some use out of this article! Please let me know if you have any feedback or questions.