To fully block YouTube videos on a modern firewall, why do you typically need both an application=quic block and an application=youtube-streaming block?

The first kills the QUIC fallback path (so YouTube uses TCP+TLS); the second blocks the streaming-specific App-ID over that TCP path.

* Block QUIC first to force a decodable TCP fallback, then App-ID bites. *

Step by step:

1. Add Security Rule: application=youtube-streaming, action=deny.
2. Test → videos still play. Why? Browser used QUIC, FW couldn't App-ID it as youtube-streaming.
3. Add Security Rule: application=quic, service=any, action=deny.
4. Browser falls back to TCP. FW now sees the TLS-SNI / App-ID, recognizes youtube-streaming, blocks it.
5. YouTube videos blocked, but youtube.com (search, comments, channel pages) still loads under generic web-browsing App-ID.

Why two rules: App-ID needs the protocol it can decode. Block QUIC first to force a decodable protocol, then block the specific App-ID on that protocol.

Tip: As of the FS26 source window, App-ID rules for QUIC-capable apps should be paired with a QUIC block on the perimeter, until firewall vendors decode QUIC reliably.

Go deeper:

• Deep packet inspection (Wikipedia) — the Layer-7 inspection App-ID relies on, and why QUIC blinds it until you force a TCP fallback.