Skip to main content
tanr
tanr
New Member
March 12, 2020
Question

Security Policy for Zoom Meeting HTTPS Doesn't Always Match FQDN Address Objects

  • March 12, 2020
  • 1 reply
  • 12839 views

With more people working remotely I've set up our FortiGate 300D on 6.0.9 to allow Zoom Meetings.  The ISDB zoom definitions aren't complete enough, so I've had to add in special security policies to allow Zoom Meetings to function.

 

This mostly works, but I've run into one problem with allowing Zoom Meetings to use HTTPS to their specific URLs (zoom.us, async.zoom.us, etc.).

 

My security policy specifies destination as an address group object that contains the FQDN address URLs for Zoom.  Service is HTTPS.  I'm doing certificate inspection for the policy, so I would think it should catch the URLs.  This policy is above any other policies that handle HTTPS.

 

What I'm seeing is that *some* of the time HTTPS is allowed through to the Zoom URLs (and I see that the policy is getting hit).  But at other times HTTPS to those same URLs is dropped as not matching any policy.  Note that there is a lower catch-all policy that allows HTTPS to any destination, but somehow that is also not getting hit.

 

Am I missing something here?  Is the FortiGate somehow seeing that Zoom is using HTTPS in a non-standard way and not matching the service somehow?  Or is it not matching the address objects somehow (I thought certificate inspection should have allowed catching the URLs even though they are HTTPS)?

 

Thanks for any help with this.

    1 reply

    tanr
    tanrAuthor
    New Member
    March 13, 2020

    Followed this back a bit, and I have a guess about what is happening.

     

    The security policy is just checking against the IPs it cached for the various URLs set as the policy destination.  So since these URLs are actually resolving differently at different times (load balancing) it doesn't always match.  I sort of verified this by checking that the cached IPs displayed in the GUI for one of the URL's didn't match to what I got with an nslookup, at least some of the time.

     

    Does that sound like what is happening?

     

    If so, I guess I get to plug all 60+ Zoom subnets into an address object for this.  Was hoping to avoid doing that.  Which we were IPv6...

    lobstercreed
    lobstercreed
    New Member
    March 15, 2020

    Hello,

     

    You've guessed it exactly.  The destination object in a firewall policy is strictly layer 3.  If you use an FQDN object rather than an IP it is only for the purpose of performing DNS resolution to dynamically determine the IP of the destination host.  What you're expecting would require using layer 6 in the destination which just isn't a thing.

     

    I'm not sure what you're trying to accomplish exactly or what the issue is since you have catch-all rules further down?  I haven't had to do anything special to allow Zoom to work on my network.

     

    Thanks - Daniel

    tanr
    tanrAuthor
    New Member
    March 15, 2020

    Thanks for the confirmation Daniel.

     

    What I was seeing was neither the security policy rule for Zoom ISDB getting hit nor the lower catch all for HTTPS to all getting hit.  The lower catch all wasn't a real option anyway, due to deep inspection.

     

    I did some testing over the weekend to reproduce this, and noticed that the Zoom ISDB rule had a web filter profile assigned to it.  Even though that web filter DID specify that it allowed collaboration and Zoom, when I removed the web filter the Zoom ISDB rule seemed to match everything correctly.  So I'm tentatively blaming the web filter.

     

    I've left the Zoom ISDB rule without a web filter profile, and added a Zoom rule below it with destination set to all of the Zoom subnets (that they publish anyway) in case the issue wasn't the web filter.  Once Zoom users are online again on Monday I'll take a look and see if the Zoom ISDB is matching everything in a real world test.

    Terms & ConditionsAccessibility statement