O365 access filtering in R80.10

[Kaspars_Zibarts]

Challenge description: our user general internet access is limited to proxy only or very specific "whitelisted" IPs could be accessed directly bypassing proxy, i.e O365. Up until October we were able to script simple network group with all O365 IPv4 addresses based on XML information from MS. That has been streamedlined now and many services have only FQDNs, not IP addresses and quite a few have a wild-card in front of the FQDN (there goes domain object option..). It's all good and great with R80.20 as there you have ready made updatable objects (Updatable Objects in R80.20 ) that cover exactly this. Seems like with R80.10 the only option is these dynamic objects (Dynamic Objects in R80.10 ) that you must order from CP or enabling Application Control, that requires HTTPS inspection. Which we do not want to do as it breaks some O365 functionality and generally is not recommended by MS.

Is anyone else  facing similar challenge? Any ideas what you are going to do before R80.20 is rolled out? For us it's a simple call of SW maturity and we don't believe that R80.20 is ready to be deployed in production yet.

[Paul_Hagyard]

Has anyone tried this in an environment with no proxy? Scraping the IP addresses is fine, and the FQDN URLs could be replicated as App/URL FQDN objects or (ugly) resolved to temporary static objects, but the wildcard URLs would be a problem.

The R80.20+ updatable objects do this (somehow - any CP developers care to comment on how you solved this?!), but some of the deployment scenarios are limited (even in R80.40, no support for desktop security policy, probably not for the NAT policy).

[nlegastelois]

Hi,

We are using Checkpoint 80.10 with a proxy server, for now all traffic are going through the proxy but I am looking for a solution to exclude office 335 using a proxy pac file and create a rule on checkpoint to permit office365 traffic.

But I have two issues : 

Microsoft doesn't provide the full IP list and when I use the get-pacfile scripte I have only domains with wildcard.

Checkpoint 80.10 doesn't work very well with rules based on non FQDN, I already had strange issues by using them.

So I am lost and I don't know how to progress on this.

Could you please help me.

Thanks

[Paul_Hagyard]

As per my post above, there is no clear way of doing this without the updatable objects in R80.20+. Some people have reported success simply using the IP objects in the Microsoft published JSON file, but my testing showed that some Microsoft OneNote traffic did not get through using just this. I extended it a bit further using FQDN objects based on the FQDNs in the Microsoft published JSON (focussing on domains owned by Microsoft, the JSON includes things like YouTube) and this helped - but still not 100%.

With no feedback from Check Point R&D on this I am *guessing* that they scrape the FQDNs some other way - e.g. possibly from a client with some agent installed.

[nlegastelois]

Ok thanks so I will try to upgrade hopping that it will be better.

[nlegastelois]

Hello,

Could you please share with me the script you used to get only the Office365 IPs from https://endpoints.office.com/endpoints/worldwide and put them into a proxy pac ?

Thanks

[SantiagoPlatero]

Hi Paul and all, yesterday I had a session with TAC cause we've issues with Microsoft Power BI, conditional access policies and users behind remote access VPN. I know it isn't the main scope of this topic but I think I can add some perspective.

Apparently, Microsoft changes its endpoint IPs on a monthly basis (or maybe even in a shorter period), and also when they do update their endpoints, they don't refresh its documentation at the same time (see date published data here https://www.microsoft.com/en-us/download/details.aspx?id=53602 vs. last update from here https://docs.microsoft.com/en-us/microsoft-365/enterprise/urls-and-ip-address-ranges).

As the updatable objects apparently didn't get natted and Microsoft changes its public IPs (so the manual NAT rules I created also didn't match and you can't also add an updatable in a group to get it to the RA encryption domain), my problem was the end user traffic wasn't routed through our gateway, so the conditional access policy denied the access as from Microsoft its detected from "outside" our organization. As per versions, the gateway is on R80.30 and the management in R81.

Long-story short, apparently the answer from the Check Point engineer was: "you will have to get update the IPs all the time Microsoft changes them". I know I can do it in an scripted fashion (download the JSON or CSV, work it through the MGMT API), but nevertheless I think is an unacceptable answer from Check Point, as I believe this isn't a uncommon scenario, specially in these Covid days. 
(note aside: I said apparently, because I got this feedback from my local partner, so maybe it could be some lost in translation).

Right now I'm working in the script but I think Check Point R&D should take this issue more seriously, as I believe that an script is only workaround that probably get broken in upcoming upgrades of the platform. I asked my local partner to talk to the Check Point counterpart to maybe ask a RFE or something like this, maybe he could, maybe he couldn't... So, to sum up that's why I'm writing this long post.

But not all are bad news, when I have the script ready, tested and working I will share here as I think another customer will find it handy.

Cheers