Allow access to office 365

[danto]

Hi, I have a strange situation. I have to implement webfilter to a client and he wants to inspect HTTPS traffic as well. The problem is that once the web filter is applied to HTTPS as well the client' s mail(the use office365) and Lync doesn' t work, because they use HTTPS ports as well. I want to create a rule for the specific traffic that the webfilter profile should not be used, but there is no specific address or fqdn for the destination, as the user configure their outlook to connect to autodiscover.client.com and the server is not always the same. I have raised a ticket to microsoft for the list of the servers and the answer came like this: *.microsoftonline.com *.microsoftonline-p.net *.microsoftonline-p.com *.microsoftonlineimages.com *.microsoftonlinesupport.net¹ *.msecnd.net *.msocdn.com *.office.net *.office365.com *.officeapps.live.com *.outlook.com Any ideea how to bypass the inspection? Thanks.

[rwpatterson]

Create address entities for all those destinations using the FQDN setting (Fully Qualified Domain Name), then either put them all in the destination of a policy, or create a group (much neater), and use that group as the destination. This policy needs to be before the general Internet usage policy in the list. From this point on, any traffic destined to any of those servers will go through this new policy.

[danto]

Hi, This is exactly what is wanted to do, but does it work with *.outlook.com for example? It will match for example phbiubl456@outlook.com with fqdn? Meanwhile I created an url exempt for these domains in the webfilter profile. I am waiting to test it Thanks.

[rwpatterson]

ORIGINAL: danto Hi, This is exactly what is wanted to do, but does it work with *.outlook.com for example? It will match for example phbiubl456@outlook.com with fqdn? Meanwhile I created an url exempt for these domains in the webfilter profile. I am waiting to test it Thanks.

Just use ' outlook.com' . The FGT will accept any domain below that.

[Dave_Hall]

In addition to what Bob posted, there are Application Sensors for Lync and I' m pretty sure for MS Exchange as well, that you can apply to either the existing fw policy or the new one (as Bob indicated) with FQDNs, allowing that kind of traffic through.

[Dave_Hall]

This is exactly what is wanted to do, but does it work with *.outlook.com for example? It will match for example phbiubl456@outlook.com with fqdn?

FQDNs have to be fully resolvable host names. A FQDN for phbiubl456@outlook.com would be the " outlook.com" part. In the case of multiple IPs for same host name, the fgt is smart enough to include those too (at least in my own testing it does).

[Wayne11]

Anyone solved this? We have exactly the same problem and strange thing is, the FQDN doesn' t work. For example, we have a policy with ID 1 for HTTPS without SSL Inspection. Everything works so far, as well the Lync authentication. When we enable SSL Inspection on this policy, we can' t authenticate anymore, because of the certificate mismatch. So we created a new policy with all the FQDN address for Office365 as destination with the ID 133 and placed this policy on the TOP and without SSL Inspection of course. But you know what, all traffic is still going through the policy 1 and ignores the new policy 133. evsecure-aia.verisign.com evsecure-crl.verisign.com evsecure-ocsp.verisign.com login.microsoftonline.com lync.com microsoftonline-p.com microsoftonline-p.net microsoftonline.com microsoftonlineimages.com microsoftonlinesupport.net msecnd.net msocdn.com office.net office365.com officeapps.live.com officecdn.microsoft.com online.lync.com onmicrosoft.com outlook.com sharepoint.com our-365-online-domain.com After all the troubles I had with 5.0.4 after updating from 4.x and the bad experience I had with the Fortinet Support with my 2 last cases, where it took 2 weeks just to get any reaction from them, I almost lost my trust in Fortinet right now The support " engineer" really suggested us to reset the FG and start from scratch. He could see our FG has a strange behaviour, but he can' t reproduce it in their lab. To get this answer took 4 weeks and plenty remote-sessions. Does anyone know if we forgot any FQDN needed for Lync authentication? We checked all the Microsoft TID' s and couldn' t find any others than what we have already. But I guess it must be something like that

[Bromont_FTNT]

Looks like there some misconceptions regarding FQDN address entries in this thread. When creating an FQDN firewall address the Fortigate does a DNS lookup for that domain name and caches that IP. The FGT is not smart enough to do wildcard lookups, in fact in order to achieve this it would need to do a zone transfer which most DNS servers would reject. For illustration purposes I' ve created two FQDN addresses... microsoft.com and www.microsoft.com We can check what IPs the Fortigate has cached for those domain names using " diag firewall fqdn list" : microsoft.com: ID(67) REF(1) ADDR(65.55.58.201) ADDR(64.4.11.37) www.microsoft.com: ID(214) REF(1) ADDR(65.55.57.27) As you can see they are different. What' s more, for larger domains like microsoft and Outlook.com (and especially google.com) the time you query and dns servers you query will yield different results as these domains host their services on hundreds/thousands of servers. So it is very important that the Fortigate and client machine query the same DNS server

[Wayne11]

I see, but I guess that for we could change and reduce the cache-ttl for each address to it' s minimum. config firewall address edit BigWebsite.com set cache-ttl 600 end What' s the minimum size of the cache-ttl parameter?

[Socarsky]

Office365, mail, calender etc. looking good now, 

accessible after I allowed this item.

Before Office365 platform went wrong...