Correctly Blocking QUIC and HTTP/3 on Sophos Firewall

QUIC is a modern, encrypted transport protocol over UDP; HTTP/3 uses QUIC as its transport. The terms are therefore closely related, but they are not identical. Browsers and web services commonly use HTTP/3 over UDP 443. For administrators, the crucial point is that this is not the classic HTTPS path over TCP.

On Sophos Firewall, this matters because the SFOS 22 documentation states that the web filter can’t scan QUIC and that QUIC bypasses web filtering. If a client rule must enforce a web policy, malware scanning, or TCP-based TLS inspection, Block QUIC protocol is therefore the documented standard method. The switch doesn’t wait to identify a QUIC handshake: within the scope of the matching firewall rule, it drops all outbound UDP packets to destination ports 80 and 443.

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:

• Plan web policy, URL groups, SafeSearch, and web filtering in general: Set up Sophos Firewall Web Protection with Web Policies
• Operate web categories and instant alerts: Use Sophos Firewall Web Categories and Instant Alerts
• Decrypt and roll out HTTPS traffic in a controlled manner: Properly Introduce Sophos Firewall TLS Inspection
• Check which firewall rule actually matches: Test Sophos Firewall Rule with Log Viewer and Packet Capture

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.

HTTP/3 moves this web traffic to QUIC over UDP. For the firewall, this means:

• Web traffic no longer looks like classic HTTPS over TCP.
• QUIC can bypass SFOS web filtering and can’t be scanned by this web filter.
• 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 drops outbound UDP packets to destination ports 80 and 443 when the traffic meets the criteria of that firewall rule. If a client reaches the internet through another rule, the setting in the standard rule has no effect. Because the switch is port-based, it can also affect a non-QUIC application that uses UDP 80 or 443. Common browsers usually try HTTPS over TCP after HTTP/3 fails, but this fallback must be verified for each business-critical application.

HTTPS is not automatically decrypted by this. QUIC blocking only moves the traffic into a more controllable TCP path. Whether web policy, malware scan, application control or TLS inspection then applies depends on the rest of the rule and inspection configuration.

When to Block QUIC

In many production client networks, blocking QUIC is sensible if one or more of these conditions 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.

Allowing QUIC can be a conscious choice for a guest Wi-Fi network without web filtering or content inspection. In that case, document that the UDP path isn’t scanned by the SFOS web filter. For managed client networks or compliance scope, the rule-specific block is usually easier to justify. Test servers and specialist applications separately because not every QUIC-based client is guaranteed to fall back to TCP.

Check Setting in the Firewall Rule

The normal location is the outbound firewall rule, for example LAN_to_WAN_Clients. In SFOS 22, the option is located under Security features > Web filtering > Block QUIC protocol.

Menu path:

Rules and policies > Firewall rules

Procedure:

For a pilot client, copy the existing internet rule or create a narrow rule above it. A documentable example uses Source zones: LAN, Source networks and devices: CLIENT-WEB-01 with 10.20.30.50, Destination zones: WAN, Destination networks: Any, and the services and security policies already required in production. Replace 10.20.30.50 and the object names with an unambiguously identifiable test client; initially keep destination, NAT, and protection profiles unchanged from the previous path.

1. Open the affected client internet rule.
2. Go to Security features > Web filtering.
3. Activate Log firewall traffic so tests are visible in Log Viewer.
4. Check the intended Web policy and Scan HTTP and decrypted HTTPS setting.
5. Keep Block QUIC protocol activated or consciously activate it.
6. Only activate Scan HTTP and decrypted HTTPS if it is also clear how HTTPS is decrypted.
7. In DPI Mode, check that Use web proxy instead of DPI engine is not accidentally active.
8. In Web Proxy Mode, check whether Decrypt HTTPS during web proxy filtering and CA distribution fit the objective.
9. Save the rule.
10. Check the test client and Log Viewer.

SFOS 22 selects Block QUIC protocol by default when you select a web policy or turn on Scan HTTP and decrypted HTTPS. This is a UI default for that rule, not a global policy. After migrations, copied rules, and rule-order changes, check the rule that actually matches again.

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.

Position Application Control and Custom UDP Rules Correctly

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

• Block QUIC protocol in the firewall rule: The standard choice for web filtering and scanning. Limitation: it only applies to traffic that matches this rule.
• Application Control: Signature-based detection and logging can supplement the block. Check Applications > Application list to see whether the current pattern version offers a suitable QUIC entry; a historical screenshot isn’t evidence of the current catalogue. An application filter only takes effect when assigned to the matching firewall rule under Other security features > Identify and control applications (App control).
• Custom drop rule for UDP 80/443: A clear technical block. Limitation: it must be correctly positioned and limited to client networks.
• Browser configuration: Useful for a short test or a managed specialist environment. Limitation: it isn’t robust enough to be the only firewall policy.

If a custom drop rule is used, place it above general client internet rules and enable logging. Otherwise, it will be difficult to tell later whether QUIC was deliberately blocked or the traffic failed elsewhere.

If a change explicitly requires a separate blocking rule, create, for example, QUIC_UDP_80_443 under Hosts and services > Services > Add with Type of service: UDP and Destination port: 80,443. Leave the default Source port: 1:65535 unchanged. The firewall rule above the general allow rule uses Action: Drop, Source zones: LAN, the pilot object under Source networks and devices, Destination zones: WAN, Destination networks: Any, this service, and Log firewall traffic. Adapt the name, source scope, and position; keep the UDP destination ports narrow and validate possible non-QUIC effects separately.

Application Control isn’t an equivalent replacement for the documented port-based switch when the TCP web-filter path must be enforced. Signatures and classifications can change with pattern updates. URL-based micro apps also require the DPI engine to see the decrypted URL. Correlate application, firewall, web, and SSL/TLS inspection logs.

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.

The operating mode of the rule is important. In DPI Mode, SSL/TLS inspection rules under Rules and policies > SSL/TLS inspection rules apply. In Web Proxy Mode, HTTPS decryption is controlled through the web proxy settings and the Decrypt HTTPS during web proxy filtering option. If these two models are mixed up, QUIC can quickly look like the main problem even though the inspection architecture is actually unclear.

Choose DPI Engine or Web Proxy correctly explains the feature and migration decision between these traffic paths.

Prove the Effect with Positive and Negative Tests

A reachable website alone doesn’t prove fallback. Acceptance separates three questions: Was UDP 443 dropped by the expected rule, was a new TCP connection then established, and did the intended web or TLS decision apply on that TCP path?

Practical test procedure:

1. Record the previous state, firewall Rule ID, client IP, test destination, and time. In the browser or a capture, first confirm that the destination generates a UDP 443 attempt; otherwise the test says nothing about QUIC.
2. Turn on Log firewall traffic and optionally reset the pilot rule’s usage counter. This doesn’t change policy, but makes new connections easier to correlate.
3. Under Diagnostics > Packet capture, click Configure and enter host 10.20.30.50 and proto UDP and dst port 443 in Enter BPF string. Replace the IP with the real pilot IP. Start the capture, fully close and reopen the browser, then request the prepared destination.
4. Under Diagnostics > Packet capture > Display filter, narrow the view with Source IP, Destination port: 443, Reason: Firewall, and the expected Rule ID. A UDP packet with status Violation in this rule is positive evidence for the block; the mere absence of UDP traffic isn’t.
5. To check fallback, change the capture filter to host 10.20.30.50 and proto TCP and dst port 443 and create a new connection. The TCP handshake and expected firewall Rule ID prove the network path.
6. Open Log viewer at the upper right, select Firewall, and correlate time, source IP, destination, Rule ID, protocol, and port. Firewall sessions often appear only at the Connection Destroy event; also check an open connection under Current activities > Live connections.
7. If web protection is the objective, make one deliberately allowed request and one request blocked by the web policy from the same client scope. For TLS inspection, also check SSL/TLS inspection, the matched decryption rule, and the certificate issuer visible in the browser. Scan HTTP and decrypted HTTPS alone doesn’t prove decryption.
8. For the negative test, remove the pilot client from scope or briefly return Block QUIC protocol to the documented previous state, create a new session, and check whether UDP 443 appears again on the expected rule path. Then restore the approved target state.

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

Typical Errors

• QUIC block only activated in an old or incorrect rule: Current client traffic runs over another rule
• Rule is below a more general allow rule: QUIC is allowed beforehand
• Logging is disabled: Not visible in the log viewer what happens
• Existing browser session is reused: Restart the browser or use a test profile before evaluating logs
• Only Chrome locally adjusted: Other browsers or devices continue to use QUIC
• TLS inspection is expected but not configured: HTTPS content is not decrypted despite QUIC block
• Scan HTTP and decrypted HTTPS misunderstood: The option only scans already decrypted HTTPS
• DPI Mode and Web Proxy Mode are mixed up: The setting being searched for may then be in another place
• UDP 443 is globally blocked: Special applications may be unexpectedly affected

Troubleshooting and SFOS 22 Version Notes

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. Is DPI Mode or Web Proxy Mode being used?
9. Does Packet Capture show outgoing UDP 443 packets despite the expected block?

If the capture still shows Forwarded packets, first check the Rule ID, source object, IPv4/IPv6 path, services, and rule order. A UDP packet may match another rule; a tick in a non-matching rule isn’t a global block. If there is no UDP attempt at all, use a different HTTP/3-capable test destination before assuming a firewall fault.

If the web policy doesn’t apply after TCP fallback, QUIC isn’t automatically the cause. For rules with multiple users or groups, the installed SFOS 22 build also matters: the official release notes list fix NC-176376 for SFOS 22.0 MR1 Build 490; web-policy rules containing more than one group or user had failed after an upgrade to 22.0 GA. Check the build, Rule ID, and user context before changing QUIC or TLS settings. A firmware upgrade follows the organisation’s backup and change process; it isn’t an ad hoc troubleshooting step.

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.
• Deliberately decided on DPI Mode or Web Proxy Mode.
• 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.

Rollback

Before the pilot, record rule status, position, Block QUIC protocol, web policy, application filter, logging, NAT assignment, and TLS/proxy mode. To roll back, disable a separate pilot rule or restore exactly the previous tick-box and policy state in the edited rule. Close the browser and existing sessions, then use a new connection to verify the previous Rule ID and UDP/TCP behaviour. Only then remove pilot-only objects; don’t delete shared services, filters, or NAT rules.

Frequently Asked Questions