8.5 Network Watcher: IP Flow, Next Hop, and Connection Troubleshoot

Network Watcher in the administrator toolbox

Network Watcher is Azure's regional network diagnostic and monitoring service. It helps administrators inspect packet permission, routing, topology, connectivity, packet captures, VPN diagnostics, and long-running connection monitoring. AZ-104 does not require you to memorize every field in every output, but you should know which tool answers the operational question.

The three tools most tied to connectivity troubleshooting are IP flow verify, next hop, and connection troubleshoot. IP flow verify asks, Would an NSG allow this traffic to or from this VM? Next hop asks, Which route will Azure use from this VM to that destination? Connection troubleshoot asks, Can this source reach that destination on this protocol and port, and what failed if not?

IP flow verify

IP flow verify evaluates NSG processing for a VM. You provide direction, protocol, local IP and port, remote IP and port, and the VM. The result says whether traffic is allowed or denied and which NSG rule caused the decision. This is excellent when a question says connectivity fails after an NSG change.

Example:

az network watcher test-ip-flow \
  --resource-group rg-network \
  --vm vm-web-1 \
  --direction Inbound \
  --protocol TCP \
  --local 10.20.2.4:443 \
  --remote 198.51.100.25:51515

If the result is denied by DenyAllInBound, you need an allow rule with higher priority than the default deny. If the result is denied by a custom rule, inspect priority, source, destination, protocol, and port. Remember that NSGs can apply at the subnet and NIC. Effective security rules combine both, so a rule in either place can affect the flow.

Limitations matter. IP flow verify evaluates NSG logic; it does not prove the application is listening, DNS is correct, or a firewall appliance allows the flow. If IP flow verify says allowed but the app is still unreachable, continue to route, guest firewall, and listener checks.

Next hop

Next hop shows how Azure routes traffic from a VM to a destination IP. It is useful when a UDR, forced tunneling, peering, VPN, ExpressRoute, or virtual appliance might be involved. The output can identify next hop types such as virtual network, internet, virtual network gateway, virtual appliance, or none.

Example:

az network watcher show-next-hop \
  --resource-group rg-network \
  --vm vm-web-1 \
  --source-ip 10.20.2.4 \
  --dest-ip 10.50.1.10

If the next hop is a virtual appliance, verify the appliance route, firewall policy, and return path. If the next hop is internet when you expected VPN or ExpressRoute, inspect route tables, propagated routes, BGP, peering settings, and address prefix overlap. If the next hop is none, a route is missing or invalid for that destination.

Next hop is especially useful for private endpoint and hybrid cases. If DNS resolves to a private endpoint IP but next hop does not stay inside the private network, the routing design needs attention. If an on-premises prefix is learned through ExpressRoute but a UDR overrides it to a firewall, the route table explains the behavior.

Connection troubleshoot and Connection Monitor

Connection troubleshoot performs an active test from a source to a destination. The source can be an Azure VM in many common cases, and the destination can be an IP, FQDN, or URI depending on the interface. It helps identify whether failure is due to DNS, TCP connectivity, routing, NSG blocking, or endpoint refusal.

Portal path: Network Watcher > Connection troubleshoot. Choose source, destination, protocol, and port. For repeated monitoring, use Network Watcher > Connection Monitor to create test groups, sources, destinations, and test configurations.

Connection Monitor is better when the problem is intermittent. A single test may pass during a quiet period, but historical data can show packet loss, latency spikes, or failures during a deployment window. For AZ-104, recognize that Connection Monitor is not only a one-time ping; it is used to monitor connectivity between endpoints over time.

Effective rules and routes

When a single NSG or route table looks correct, the effective view may still reveal the problem. Effective security rules show the combined result of subnet-level and NIC-level NSGs. Effective routes show system routes, BGP routes, and user-defined routes that apply to a NIC.

Portal paths:

Practical diagnostic sequence

Connectivity failure to VM or service
|-- Does DNS resolve as expected from the source?
|-- Does IP flow verify allow the flow at the VM NSG layer?
|-- Does next hop show the expected route from source to destination?
|-- Does connection troubleshoot report reachable?
|-- Does the destination OS firewall allow the port?
|-- Is the application listening on the destination IP and port?
|-- Do return routes and stateful firewalls allow the response?

Use Network Watcher to narrow the Azure control plane view, then use guest tools to confirm runtime behavior. On the guest, use Test-NetConnection, curl, ss, netstat, logs, and service status. A clean Azure path does not prove the app is healthy.

Exam traps

Do not use IP flow verify to troubleshoot DNS. Do not use next hop to prove an NSG allow. Do not assume ping failure means TCP failure, because ICMP may be blocked while TCP 443 works. Do not overlook regional availability of Network Watcher resources; in normal Azure operations, ensure Network Watcher is enabled in the relevant region.

A frequent scenario says VM1 cannot connect to VM2 after a route table was added. The best first tool is next hop, not IP flow verify, because the change was routing. If the scenario says access failed after a new NSG rule, IP flow verify is the better first test.