Network Monitoring

When you apply Network Security Groups (NSGs) on Virtual Networks or NICs, you are essentially defining the allowed and denied traffic based on rules. Once these rules are in place and an application suddenly stops working, it's often due to a blocked port or protocol — just as you've guessed. Your main goal here is to identify which port the application is trying to use and whether the NSG is blocking it.
To monitor or record the network traffic specifically in relation to NSG activity, the most accurate tool is NSG Flow Logs, which you've already enabled. These logs capture both allowed and denied flows, and they log 5-tuple information: source IP, destination IP, source port, destination port, and protocol, along with whether the traffic was allowed or denied. However, NSG flow logs are not real-time; the log data is written in intervals (typically every 10 to 15 minutes), so there is a small delay.
You’ve correctly pointed out that “IP flow verify” is useful only when you already know the port and want to test whether the current NSG rules would allow that communication. It’s a great what-if tool, but not suited for live diagnosis when the port or traffic specifics are unknown.
Regarding Traffic Analytics, you're also right — it is not suitable for the use case you described. It’s built to provide aggregated insights, trends, and top talkers rather than real-time or per-flow diagnostics. It cannot help when troubleshooting why a specific application is being blocked, especially if you're trying to discover the port in use.
Since your challenge is:
You don’t yet know what port the application is using.
You suspect NSG is blocking it.
You want to log and trace this traffic.
Here’s the practical, detailed path forward:
The most accurate way to discover the actual port being used is to use packet capture via Network Watcher on the NIC of the VM where the application is running. This will show you live traffic that the VM is trying to send or receive, including the destination IP, source/destination ports, and protocol. Once you capture that, you’ll know exactly what port the application is using.
Once you know the port, you can go back and query NSG Flow Logs using Log Analytics if you’ve linked the flow logs to a workspace. Use Kusto Query Language (KQL) to filter traffic involving the identified IP and port and look for flows marked as “D” (denied). This confirms whether the NSG is the one blocking it.
To sum it up:
Use Packet Capture to determine which port the application is using.
Use NSG Flow Logs (queried via Log Analytics) to confirm whether that traffic is being denied by NSG.
Update the NSG rule once confirmed.
If you want more real-time diagnostics, NSG flow logs do not offer second-by-second monitoring. But packet capture is near real-time, and that’s what makes it the ideal tool for the scenario where you do not yet know what port is in use.
So in short, you are on the right path with NSG flow logs, but you’ll need to pair it with packet capture to identify unknown ports. Flow logs will confirm if NSG blocked it. Traffic Analytics isn’t wrong, but it’s not fit for real-time troubleshooting at the individual flow level.

Believed you are in the right track, please consider:

1. NSG Flow Logs (via Network Watcher)

NSG Flow Logs are ideal for recording network traffic and determining if NSG rules are blocking communication:

• Enable NSG Flow Logs:
• Go to Network Watcher > NSG Flow Logs.
• Enable flow logs for the NSG associated with the affected subnet or NIC.
• Configure the storage account and retention settings.
• Analyze Logs:
• Use a tool like Traffic Analytics to interpret flow logs visually or export them for manual analysis.
• Logs include information on the source IP, destination IP, protocol, and NSG rule that allowed or denied the traffic.

2. IP Flow Verify (Network Watcher)

As you've noted, IP Flow Verify is a great tool to test whether specific traffic is allowed or denied by the NSG:

• Provide the source and destination IPs and the port to verify if traffic is being blocked.
• It's a "what-if" tool, so it's not live monitoring but useful for troubleshooting specific scenarios.

3. Packet Capture (Network Watcher)

For real-time traffic analysis, Packet Capture in Network Watcher can be helpful:

• Create a capture session to monitor traffic on a specific NIC.
• It records packets to a storage account for deep analysis.
• Use 3rd party tools to inspect the captured data and identify blocked ports or failed connections.

4. Azure Monitor Logs

If you want an aggregated view of blocked traffic:

• Configure Azure Monitor to collect NSG Flow Logs and metrics.
• Use Log Analytics to query and visualize traffic patterns:

AzureDiagnostics | where ResourceType == "NETWORKSECURITYGROUPS" | where Action_s == "Deny"