A "QUIC" Primer to How Netskope Handles the Quick UDP Internet Connections Protocol

[sshiflett]

The Quick UDP Internet Connections (QUIC) protocol is a transport layer protocol created by Google.   If you are interested in learning more about the inner workings of QUIC, you can look at the Chromium Project.   Netskope recommends blocking QUIC to force a fallback to traditional HTTPS.  This allows for SSL inspection and applying Netskope’s activity, instance, and other advanced controls to traffic that would traditionally utilize QUIC.  In most Netskope configurations, no additional configuration is required.  See the sections below based on your Netskope deployment. 

Client Using Secure Web Gateway, CASB, or Cloud Firewall Steering

No configuration is needed in most cases. The Netskope client will automatically block QUIC traffic from the “google chrome” and “google chrome helper” processes on Mac and Chrome.exe processes on Windows.  The Netskope client also blocks QUIC from other common browsers such as Edge and Firefox.  

The Netskope client can be configured to use DTLS which also utilizes UDP over port 443.  The implicit block for QUIC does not impact this functionality as the traffic is from the client service. 

IPSEC or GRE Tunnel Using Web Steering

No configuration is necessary if you’re sending TCP and UDP traffic on ports 80 and 443 to Netskope.  Netskope will automatically drop non-standard HTTP/HTTPS when sent to the Netskope proxy.  If you’re using an SD-WAN device or NGFW that is steering traffic to Netskope based on protocols such as TCP, HTTP or HTTPS, you can block QUIC or UDP/443 at the device which will force the traffic to fall back to HTTPS. 

NOTE:  When blocking UDP/443 with your network security device, ensure that you do not block UDP/443 traffic to Netskope’s IP ranges as clients can be configured to use DTLS over UDP/443.  The exact configuration depends on whether devices with clients are steered over the tunnel.  

IPSEC or GRE Tunnel Using Cloud Firewall Steering

When steering all traffic to Netskope via a tunnel, the exact behavior depends on the default firewall action and whether QUIC is allowed by policy.  Netskope recommends explicitly blocking QUIC via a firewall rule to ensure that connections fallback to HTTPS and can be inspected.  Follow the steps below to create this policy.  

1. Navigate to Settings > Security Cloud Platform > App Definition. 
   
2. Click NEW APP DEFINITION RULE and select Firewall App.
   
   
3. Configure the new app definition with a name, UDP as the protocol and 443 as the port.  
   
4. Apply the new app definition by clicking APPLY CHANGES
   
   
5. Navigate to Policies > Real-time Protection.
   
   
6.   Click NEW POLICY and select Firewall.
   
   
7. Select the Application you created in step 4 and change the Action to Block. 
   
   
8. Give the Policy a name and click SAVE.  
   
   
9. Apply the new policy by clicking APPLY CHANGES

[qyost]

We're seeing similar challenges for meeting/collaboration sites that utilize STUN, and don't implement a fallback HTTP(S) connection.

[doge-tech]

This is unsatisfying. There's nothing in the QUIC protocol standard that mandates the use of port 443. If we block UDP port 443 at the tunnel or firewall level a malicious QUIC site running on UDP port 31337 (for example) would have its traffic sail through the SWG uninspected. I'm not sure how the Netskope client blocks QUIC, but if it's also looking for UDP port 443 the same problem exists.

Is Netskope working on detecting and inspecting QUIC connections?