Incomplete results from FQDN objects

[TimB_Unbound]

I'm working on separating out the traffic we send to Office 365 with a dedicated firewall rule so we can change how we handle some of our logging.

To this end I have a new rule at the top of the processing chain going to 'outlook.office365.com'. This kind of works. The problem is that when I use the "outlook.office365.com" FQDN objects I'm only getting a handful of the IP addresses.

If our client computer connect to any of the others not on the list they go down the chain to our general rule. Only a tiny percent of the traffic I'm trying to collect goes out through this rule. 

Is there a good way to solve this? 

[MikePruett]

FQDN is highly unreliable. Mainly because it doesn't look up the IP each time so if rotations occur etc things get wonky.

[Srujan]

FQDN objects are reliable, so it is better you check the ip address of the outlook.office365.com and create the object with the ip address

use the same ip address object in the policy, but the ip address of the outlook.office365.com changes depends on the region it is better you check the ip adress of the outlook.office365.com weekly once to have the correct reports.

-srujan

[TimB_Unbound]

Great getting two totally opposite responses here.. Anyways I side with MikePruett on this one. Generally the FQDN method works perfectly but in cases where there is a large rotation it is definitely failing. 

Did some digging on Microsoft's site and found their "Office 365 URLs and IPs" page which includes their "Exchange Online" IPv4 endpoints. 

https://support.office.co...amp;rs=en-US&ad=US

[AtiT]

Be sure your Fortigate is using the same DNS as the clients.

Also you can play with the cache-ttl settings under the FQDN address object so the "older" IP addresses will timeout later.

It could help but I don't know how many IP addresses are possible to cache for one FQDN object.