Paloalto firewall google drive blocking -- quic based problem

[OrkhanM]

Hello,

We are experiencing an issue with blocking Google Drive access through Palo Alto Firewall despite applying several mitigation steps.

Current Setup:

• SSL Decryption is enabled and functioning.
• Security policies and URL filtering are configured to block:
  • drive.google.com
  • drive.google*
  • *.drive.google.com
  • *.google.com (selectively for Drive-related services)
• App-ID blocking for google-drive-web, google-docs-base, etc., is also in place.

Issue:

• Some users are still able to access https://drive.google.com even after all blocking measures.
• This seems to happen due to browser caching — once the cache is cleared, Drive becomes inaccessible, as expected.
• However, clearing the cache manually is not a sustainable or correct solution.

Observations:

• Even after applying SSL decryption, we still see App-ID: quic and Service: udp/443 in the Traffic logs for Google domains.
• In some cases, no traffic is visible at all in the firewall logs related to that access, making it difficult to track or block reliably.
• This suggests the session might be:
  • Encrypted and undetected due to session reuse or early QUIC negotiation,
  • Or being misidentified or missed entirely by App-ID before it can be classified.

Questions:

1. Is there a reliable method to prevent access to drive.google.com even when cached, without impacting other Google services?
2. How can we ensure QUIC sessions are correctly inspected or blocked only for Drive, without affecting other QUIC-based services?
3. Could this behavior be due to Chrome QUIC session resumption or preloading even after SSL decryption is enabled?

Any guidance or best practices from the community would be greatly appreciated.

Thanks in advance.

[BPry]

@OrkhanM,

QUIC needs to be disabled, as recommended by PAN.

PAN-OS cannot decrypt the traffic so you either have the option of blocking outbound QUIC traffic on your network (usually by simply blocking udp/443 and not just blocking the app-id) or you need to block it in all approved browsers. Personally I would recommend taking both paths so you don't force the browser to attempt to utilize QUIC and get blocked at the network level and fallback.