Azure NSG logging - reduce unwarranted traffic on your SBC

 A few months back I was trying to sort through SIP logs on my SBC. As I was capturing the call flows I needed, it took me a while to sort the active and real traffic from invites coming from unknown sources.

Then it dawned on me, lets block out traffic from repeat offenders. Not everyone runs their SBC's virtual, but in my case, I run a vSBC in Azure - and there were plenty of tools to help me. I found this doc which helped me visualize and filter the the traffic, subsequently block unwanted traffic using Azure Network Security Groups.

Visualize NSG Log Flows with Power BI

Why is this important - well other than the initial challenge of filtering logs of unwanted traffic to find real calls - why use vCPU to ultimately decline SIP traffic, when you can just drop it before it gets to the SBC application. When "paying" for processing cycles and network traffic - every penny counts.

Before 

After

By creating a Azure Storage Account and dumping the Network Security Group (NSG) Logs to this storage account - we can visualize the unwanted traffic and tune the NSG rules for our SBC interfaces.

If you have more than one physical interface on your SBC - you may have to monitor multiple NSG Flow (example: Public and Private interface on your SBC)

Microsoft documents the required firewall ports and IP's needed for optimal connectivity to Teams, the PowerBI view helps ensure proper rules configuration.

https://learn.microsoft.com/en-us/microsoftteams/direct-routing-plan#sip-signaling-fqdns

Hope this helps - you may find other ways to leverage this visualization for security and optimal media flows.

Update - 12/22/2023

I wanted to add a section regarding uses to troubleshoot Azure NSG rules with SIP Calls (or other applications with port and protocol rules) using this Log Flow visualization tool in Power BI.

Recently I was working to resolve a media session issue - one-way audio between Microsoft Teams and an on-prem PBX.

Here, Wireshark is showing me I only had a single RTP media stream - when a SIP call normally contains a bi-directional flow for 2 way audio (a successful SIP Call)

So I wanted to validate the session was getting to and through my SBC. The SIP ladder diagram shows a successful call - yet I had one way audio and only this one RTP stream at the SIP client.

I selected the source IP from the C-Line in the SIP message and in the NSG Log Flow Analyzer - filtered the log to identify the session and determine if the Azure NSG rules were allowing or dropping the traffic. 

I set the filter for the source of the media stream identified in the SIP message, and set the protocol to UDP, and was able to see the NSG rules "Allowing" the traffic - identified by "Decision - A".

I should mention there are direct ways in Azure to search and analyze these logs using KQL and log analysis - the NSG Log Analyzer in Power BI can be much easier for those not active in Azure or skilled in KQL queries. 

So - the SIP trace from the SBC showed successful signaling and the NSG log confirmed media was properly allowed to and through the SBC. 

Ultimately it was a client-side issue with NAT - once the local NAT rules were corrected - 2 way audio !!

If you are interested in concepts like this, stay tuned for an upcoming series of posts focused on Cloud hosted UCaaS infrastructure. - HERE