Correctly Blocking QUIC and HTTP/3 on Sophos Firewall

QUIC is a modern transport protocol that is particularly relevant today in connection with HTTP/3. Many browsers and web services use QUIC to establish web connections more quickly and maintain them more stably. However, for administrators, another point is crucial: QUIC operates over UDP, often over UDP 443, and therefore behaves differently from classic HTTPS over TCP.

On the Sophos Firewall, this is important because web filtering, malware scanning, TLS inspection, and application control can only be reliably assessed if the traffic passes through the rule in the expected form. In many environments, Block QUIC protocol remains a sensible setting in client internet rules.

Which Web Protection Article Fits?

QUIC is usually not the main target but a disruptive factor in web protection, TLS inspection, or troubleshooting scenarios. Depending on the task, a different entry point is suitable:

This article primarily answers the question of when and how to block QUIC or HTTP/3 in the appropriate firewall rule and then validate it cleanly.

What QUIC Means for the Firewall

Classic HTTPS usually runs over TCP 443. The firewall can decide, depending on the rule, web policy, DPI engine, web proxy, and SSL/TLS inspection, whether traffic is only allowed, categorized, decrypted, scanned, or blocked.

QUIC shifts this web traffic to UDP. For users, this is often faster. For the firewall, it means:

• Web traffic no longer looks like classic HTTPS over TCP.
• UDP 443 can bypass web filtering and scanning expectations.
• TLS inspection does not apply as it does with normal HTTPS over TCP.
• Troubleshooting becomes more difficult when browsers automatically switch between TCP and QUIC.
• Policy tester, log viewer, and packet capture must be consciously compared with protocol and port.

The Block QUIC protocol option blocks outgoing UDP packets to port 80 and 443 for traffic that matches the rule. Browsers then usually fall back to HTTPS over TCP.

When to Block QUIC

In many productive client networks, blocking QUIC is sensible if one or more of these statements apply:

• Web filtering should reliably apply.
• Malware scanning for web downloads is important.
• TLS inspection is used for selected categories or user groups.
• Application control should better recognize web applications.
• Web access should be traceable in the log viewer.
• Helpdesk and security team should be able to conduct reproducible tests.

For a guest WLAN without deeper inspection, QUIC may be less critical. For managed client networks, servers with outgoing internet access, or environments with compliance requirements, one should consciously decide on QUIC and not simply leave it to the browser.

Check Setting in the Firewall Rule

The usual location is the outgoing firewall rule, for example, LAN_to_WAN_Clients.

Menu path:

Rules and policies > Firewall rules

Procedure:

1. Open the affected client internet rule.
2. Go to the Security features > Web filtering section.
3. Check web policy or malware scanning.
4. Keep Block QUIC protocol activated or consciously activate it.
5. Only activate Scan HTTP and decrypted HTTPS if it is also clear how HTTPS is decrypted.
6. Save the rule.
7. Check the test client and control the log viewer.

Sophos activates Block QUIC protocol by default when a web policy is selected in a rule or HTTP and decrypted HTTPS are scanned. Nevertheless, one should consciously check the setting for important internet rules, especially after migrations, old rule sets, or copied rules.

More about the individual options of a firewall rule can be found in Understanding and Properly Configuring Sophos Firewall Rules.

Do Not Only Disable QUIC via Browser

It used to be common to disable QUIC directly in the browser or via Chrome flags. This can help for tests but is not a reliable security concept:

• Browser settings change.
• Not only Chrome can use QUIC or HTTP/3.
• Users or updates can reset settings.
• BYOD, guest, and unmanaged devices can hardly be controlled this way.
• Security policies should be traceable centrally on the firewall.

For productive environments, the firewall rule is the better place. Browser-side tests can be additionally useful if you want to narrow down an error.

Alternative: Application Control or UDP Rule

In addition to Block QUIC protocol, there are other ways to restrict QUIC traffic.

If an own drop rule is used, it should be placed above general client internet rules and logged cleanly. Otherwise, it is not recognizable later whether QUIC was consciously blocked or if the traffic is stuck elsewhere.

Connection with TLS Inspection

Block QUIC protocol is not a substitute for TLS inspection. The setting only ensures that browsers do not continue communicating over QUIC with matching traffic but usually fall back to HTTPS over TCP.

Only then does the actual TLS question arise:

• Is there a suitable SSL/TLS inspection rule?
• Is the CA certificate distributed on the clients?
• Is the traffic decrypted or deliberately not decrypted?
• Is Scan HTTP and decrypted HTTPS active in the firewall rule?
• Are there exceptions for applications with certificate pinning?

If HTTPS content is to be checked, a planned TLS rollout is needed. The details are in Properly Introduce Sophos Firewall TLS Inspection.

Test and Validation

After a change, you should check whether the client really falls back to HTTPS over TCP and whether the expected firewall rule matches.

Practical test procedure:

1. Reset the usage counter of the affected firewall rule.
2. Open a website on a test client that previously used QUIC.
3. Filter in the log viewer by source IP and destination port.
4. Check whether UDP 443 is blocked or no longer used.
5. Check whether HTTPS over TCP 443 appears in the expected rule.
6. If web filtering or TLS inspection is active, check the corresponding log modules.
7. If unclear, use packet capture on the client or firewall interface.

For rule tests, the guide Test Sophos Firewall Rule with Log Viewer and Packet Capture is suitable.

Typical Errors

Troubleshooting

If web filtering or scanning does not apply as expected, you should check this sequence:

1. Which firewall rule does the client traffic actually match?
2. Is Block QUIC protocol active in exactly this rule?
3. Does the client use UDP 443 or TCP 443?
4. Is Log firewall traffic activated?
5. Does a more specific rule apply above?
6. Is there an application control policy that treats QUIC differently?
7. Is there an SSL/TLS inspection rule if HTTPS content is to be checked?
8. Does packet capture show outgoing UDP 443 packets despite expected blockade?

If the rule does not match, QUIC is not the main problem, but rule order, source zone, source network, destination, service, or exclusion. For this, Check Causes When Firewall Rule Does Not Match helps.

Operational Checklist

• Clearly identified affected client internet rule.
• Checked web policy, malware scan, or TLS inspection in exactly this rule.
• Consciously activated or justified deactivated Block QUIC protocol.
• Checked rule order and more general allow rules.
• Log firewall traffic active.
• Conducted test with browser and real target site.
• Checked log viewer for UDP 443, TCP 443, rule ID, and web events.
• Additionally checked SSL/TLS inspection logs if TLS inspection is active.
• Documented exceptions or own UDP rules.
• Helpdesk knows that websites should normally continue to function after QUIC block.

Frequently Asked Questions