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.