MS-Teams Update Security Policy Help

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Announcements
Please sign in to see details of an important advisory in our Customer Advisories area.

MS-Teams Update Security Policy Help

L2 Linker

Hello all,

 

 I'm trying to fine tune a security policy to allow MS-Teams to update; based on what I can see the logs, it seems to contact statics.teams.cdn.office.net for the update.  I have created a single policy with that destination as a FQDN, allowing the usual ports and applications.  However, the rule is never hit, it skips over it and hits a deny rule.  When I check the URL Filtering logs, it does indeed show that it hits statics.teams.cdn.office.net but the destination IP is completely different than any ping, nslookup, PAN resolve, etc... to that FQDN and I can't figure out why the IP doesn't match what returns for that FQDN.  

 

Does anyone have any experience with something similar or even a better way that I might be able to allow Teams to update through the application itself?  

 

Thank you. 

3 REPLIES 3

Cyber Elite
Cyber Elite

@COlson,

I would personally setup this policy based off of a custom URL category to identify the traffic, instead of attempting to restrict it by destination. Akamai (which is the CDN in this case) uses GeoDNS and various other methods to spread load across its network, so just because you get two addresses in your NSLOOKUP request doesn't mean your clients are going to be hitting the same addresses. 

@BPry ,

Thank you for the suggestion.  I have done this before but tend to see inconsistent/unexpected results. So, following your advice, I did this for the the statics.teams.cdn.office.net; created a Custom URL CAT, added it as a FDQN inside of that.  In the security policy, allowed the desired apps, ports, Destination ANY and that custom URL CAT.  The rule does work, Teams downloads but I also see the rule several times hitting IP addresses that don't reverse to the aforementioned FQDN.  Based on GeoDNS with Akamai though, you believe this is expected behavior?

@COlson,

So this could be caused by GeoDNS and other technologies that the CDNs use to spread their traffic load, but you should be able to do a WHOIS on the IP address and see it tied to Akamai. The thing to keep in mind here though is that when you filter on URL category the firewall needs to allow enough traffic to pass to actually capture the domain. Keep in mind though that as soon as the domain/url is known it'll no-longer match that entry. 

  • 2583 Views
  • 3 replies
  • 0 Likes
Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!

The LIVEcommunity thanks you for your participation!