This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

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!

 

Parents
  • My company, like most all companies, have closed their offices and we are all working remote. We have O365 licenses for Skype/Teams so I guess this monitoring won't apply to us?

  • megabyte24_0-1585755905893.png

    To my thought also, I would not think so, unless your company has VPN set to NOT split tunnel (so all network requests/data from employee PC's will flow via the corporate infrastructure). Of course this can cause other issues with bandwidth via the VPN endpoint, or possibly even in the corporate LAN.

    I do wish SolarWinds/the author of this page would edit it to clarify this point.

  • 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?

     

Reply
  • 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?

     

Children
No Data