Office 365 Updateable Objects

[Dave_B]

Hi folks,

We're in the middle of an Office365 rollout, and getting some confusing results using the O365 Updatable Objects on our Checkpoint (R80.20)

While testing, we have two different UOs (Updatable Objects) configured on the CheckPoint, one for "Office365 Worldwide Services" and another for "Office365 Third Party Domains". I would expect those, between them, to cover all the required domains.

But if I download the O365 Endpoint Data directly from Microsoft at

https://endpoints.office.com/endpoints/worldwide?clientrequestid=b10c5ed1-bad1-445f-b386-b919946339a...

and compare that to the domains in the Checkpoint UOs using:
domains_tool -uo "Office365 Worldwide Services"
domains_tool -uo "Office365 Third Party Domains"

there are many domains that appear in the Microsoft data but are missing on the Checkpoint - for example, in Endpoint 125 of the MS data we see "crl3.digicert.com" but that does not appear in either of the Checkpoint OUs. Same for many of the CRL-related domains in Endpoint 124, and a few others. "cdn.optimizely.com" from Endpoint 53 is another example - present in the MS data but missing in the Checkpoint UOs.

sk135572, "Microsoft Office 365 objects as Network Objects in R80.20" clearly states:
Each Office 365 Updatable Object matches a list of IP addresses and Domains according to the feed published by Microsoft
but it doesn't seem to be working like that.

I've checked sk122636, "How to troubleshoot Updatable Objects in R80.20 and higher"
and sk121877, "Package of Updatable Objects is missing on the Security Gateway" and everything looks OK.

Is anyone else seeing the same problem? Any idea why it's happening?

Thanks,

Dave

[PhoneBoy]

Are you experiencing an actual issue or are you just noticing there appears to be a difference between what we provide and what they provide?

[Dave_B]

Good question!

We're in a testing phase at the moment and users are complaining of poor performance, so we're experimenting with what goes via our web proxies and what goes directly out via the Checkpoint. Office 365 seems such a convoluted mess that it's difficult to say what is and isn't causing issues.

But our basic design brief is that we, as the firewall team, should be honouring Microsoft's advice, which is "you must allow all THIS stuff out to the Internet" and as it stands, due to the mismatch, we aren't doing so.

We can work round it by doing more manual setup on the Checkpoint but the whole point of the Office 354 UO is that we shouldn't need to. So I guess really I'm asking if anyone else has seen this and if it caused them any problems, or if it's just not important.

[Abd_S81]

We ran into this issue and after several trial and error methods, the working solution was to create another rule below the O365 updateable objects rule with allow http/https to any destination and then create an in-line layer rule to perform Application control/URLF and add the O365 applications listed in services. Remember there several wildcard entries from the MS O365 public feed which also does not work unless they are defined or use Application control. 

That seems to have done the trick for us. Though I agree the updateable objects should have worked on its own.

[Dave_B]

Thanks Abdul, we'll look into that. At least now we know it isn't just us.

[Mike_Jensen]

We have a AD Connect server on prem that syncs with Microsoft Azure. I had a firewall rule allowing this server to a destination of "any" so it could connect with Microsoft's cloud. Yesterday I replaced the "any" with the Office 365 updatable object and now not all traffic to Azure is blocked by the firewall but enough to break the AD Connect Sync. The IP's that are being blocked are to legitimate Microsoft Azure IP's. Have any of you been able to make the Office 365 object work better?
I worked through sk122636 and it seems my SMS and security gateways have the full connectivity they need to download the updates.
My SMS and gateways are running 80.30 with the latest GA Jumbo Hotfix.

[PhoneBoy]

Keep in mind if Microsoft updates the IPs and doesn't tell the mechanism we use for the gateways about it (most likely an XML/RSS feed), then our objects won't be up to date.
Best to engage with the TAC here.