MS-Teams Update Security Policy Help

[COlson]

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. 

[BPry]

@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. 

[COlson]

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

[BPry]

@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.