This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Monitoring Microsoft Teams/Skype Traffic with NetFlow Traffic Analyzer

With remote workers becoming more and more common, collaboration software is being leveraged by more organizations.  Monitoring Microsoft Teams traffic in your network can offer some insights into collaboration usage trends over time.

This the second article in our series describing how to craft custom applications in NTA.

Next Generation Network-Based Application Recognition Protocol (NBAR2)

If your networking infrastructure supports the NBAR2 protocol and you are running Protocol Pack 37.0.0 or later, then you are already seeing Microsoft Teams/Skype as its own application family.  It will appear (after being detected) as “skype,” ms-teams, ms-teams-audio, ms-teams-media, and “ms-teams-video. 

If your network infrastructure doesn’t support NBAR2, you can still get the classification for Microsoft Teams/Skype communications. 

Custom Application Build

A custom application to monitor Microsoft Teams/Skype requires two parts.  The first part is building a custom IP Group with the target addresses of the application.  Thankfully, Microsoft is good about publishing the IP information. 

Build the IP Group

From the NetFlow settings page, scroll down to IP Address Groups.

Picture1 (2).png

Build a new group and add the addresses.

Picture1.png

These are rarely small lists, so we’ve expedited the process by attaching a file you can import. See the attachment below. If you choose to import it, be sure to “append” to the existing list of IPs.


Build the Multi-Port Application
The last step for building the custom application is configuring the ports for traffic matching. From the NetFlow settings page, select “Application and Service Ports.”

Click “Add Application” and give it a name, enter “80,443,3478-3481” in the port list, and select Microsoft Teams/Skype in the Destination IP Address.

Picture1.pngSubmit all your changes.
Now the new custom application will show up in your Flow Navigator.

Picture1.png

Using IP groups to distinguish application traffic is a simple way to pull out a clear view of some application services, and can offer you insight you can act upon. Discuss your experiences with custom applications below!

 

  • Microsoft publishes an excellent comprehensive resource for IP address ranges and ports used by the O365 ecosystem here.

    It's complex, but you can evaluate this list and determine what applies to your environment.

     

  • The traffic you see is what's reported by an individual interface.

    For most routers (where NAT is not occuring) we can reconcile traffic the passes through multiple interfaces in the same node - see the 2020.2 Release announcement for the Traffic Reconciliation feature.

    We don't yet have the ability to perform flow stitching and reconcile inside and outside conversations through a firewall, so you'll need to look at those independently. There is an open Feature Request for this feature; I encourage you to weigh in there with the functionality you'd like to see.

     

  • That's an excellent point; this technique assumes that you are analyzing flow from an observation point where this traffic is actually visible. For many companies running split-tunnel configurations, the traffic from work at home offices never passes through corporate internet routers or firewalls - it's routed directly from the residential network to the network service access points.  

    This is a much broader issue. There's no question that you lose some visibility with a distributed, independently connected workforce. It might be interesting to start a new discussion thread about what kinds of monitoring are critical in this context, and how best to provide that.

    What do you do at your company to maintain this visibility of remote worker's traffic?

     

  • I do have a question about doing this another way but want to say First off this is a fantastic document and guide! 

    Could you also do this under Manage applications and Service ports by specifying the ports for Microsoft teams/skype with a destination IP address as any or would that start classifying web surfing as teams since it uses some of those same ports?

    Thanks

    Adam

  • Hello,

    Does anyone else have issues with this classifying the traffic as teams on the ingress path?

    Not quite sure why I would need to specify my internal IP's on the teams IP group as the incoming traffic is from the same IP server range and from my understanding should classify both ingress and egress traffic if its communicating with that set of IP's on the those ports.