A few days ago I started to “play” with the Gateway from Cloudflare for Teams, for DNS resolution (protection, logging, etc.)… not for http(s) inspection.
But now it seems that (at least some of the) web traffic gets forwarded to a proxy.
I just re-tested and the initial link ‘mobileappcommunicator.auth.microsoft.com’ used by the MA app gets redirected to ‘login.microsoftonline.com’, but via the proxy (as the cert is the Cloudflare one)… and I checked and still have disabled the HTTP traffic filtering in the Secure Web Gateway, including disabled TLS decryption
You have to look at the Gateway logs. Search for the domain mobilappcommunicator… and see why the domain was blocked.
The certificate certainly shows that the HTTP policy is configured for TLS Decrypt. You should a create a HTTP policy to skip Microsoft from inspection. If it still doesn’t work you can create a policy for this domain specifically.
This hostname and/or one of the CNAME targets for it is being blocked based on a DNS policy you have configured in Teams. In your Teams dashboard go to Logs | Gateway | DNS and filter on Blocked for Actions taken. likely one or more of the following will show as being blocked:
mobileappcommunicator.auth.microsoft.com. 226 IN CNAME prda.aadg.msidentity.com. prda.aadg.msidentity.com. 226 IN CNAME www.tm.a.prd.aadg.akadns.net.
If I had to make a guess I’d assume new or newly seen domain will be reported as the category for one or more of the records (the link to the Radar report will tell you for sure). You can explicitly allow the host and/or modify your DNS filtering policies as need.
It’s also possible to see the Cloudflare Gateway cert when using ‘custom block page’ even without HTTP filtering enabled as the only way to show a custom block page for a blocked DNS request without it showing a certificate error (since the cert won’t match) is to have that installed.
The issue seemed to be the resolution treatment for ‘mobileappcommunicator.auth.microsoft.com’, which seemed to have also checking the alias ‘prda.aadg.msidentity.com’ and this one was blocked by the CF rule Query categories=Security Risks, Unreachable (why?), with the Resolver decision=Blocked By Query Name , which seems strange at least and I don’t understand this behavior (some abnormal decision in the CF classification logic?).
I set some Gateway DNS policies to “ Allow ” the domains ‘.microsoft.com’ and ‘.msidentity.com’, and set an HTTP policy for ‘.microsoft.com’ to ‘ Do Not Inspect ’, and I no longer received the error, but I feel this doesn’t have to be the case… how many other similar tweaks should we do for how many other domains?
And I was not getting the ‘custom block page’, but some default CF one (per the first image).
I understand the necessity to show the blocked page for human consumption, but for applications/APIs calls this creates issues. And I still believe the issue reside within the DNS filtering engine in the first place.
That’s a custom block page. The other option (if custom block page is not enabled) is that we will return 0.0.0.0 for the address and there’s no block page.
The domain is classified as unreachable because … it’s unreachable… there isn’t anything shown on a web page for that host. Not my favorite classification category (not as clear cut as say a phishing domain). You can submit domains/hosts you believe are miscategorized through radar.cloudflare.com.
There’s no one size fits all set for filters to apply. In some organizations an aggressive approach to allowed domains make sense. In others… not as much.