HTTP3 / QUIC handling of OPNsense

[meyergru]

I have searched the forum but not found anything about this topic:

As some of you may have noticed, the HTTP3 standard is becoming more of a thing right now. Most browsers implement it and larger sites (CDNs and big providers) use it.
HTTP3 has some benefits (i.e. speed) and some drawbacks, being based on QUIC and thus on UDP.

HTTP1 and HTTP2 were based on TCP, in which we have a direction for packets because of handshakes and sessions which make it possible to have a correlation of incoming and outgoing packets. So, when I define a firewall rule that refers to a source and a destination, everything is clear.

With UDP, this is not so easy. I know of some packet filters that correlate UDP packets based on source and destination ports and a "session" cache which more or less guesses which UDP packets may be responses to UDP requests. For QUIC, this becomes even harder, since everything (including the session information) is encrypted and thus the intermediate firewalls cannot really track what is going on.

Does OPNsense offer a solution for this? In that case, one could define rules for UDP "connections" as well.

From my first observation, HTTP3 does not work out-of-the-box (as per https://cloudflare-quic.com/ and other test sites). I have IPv6 and would assume that is being preferred. I have a general "allow LAN to ANY" rule for both IPv4 and IPv6.

But only when I add a rule to allow any UDPv6 traffic for WAN, the HTTP3 test works. Alas, opening up all UDP traffic to my network is obviously not what I want.

How could I allow HTTP3 in a safer way? Allowing traffic from port 443 only cannot be the solution either.

Am I missing something or is OPNsense not able to do this?

[xkpx]

HaProxy is going to receive http3 update i hope : https://github.com/opnsense/plugins/issues/3026

[meyergru]

That is the other direction, HTTP3 in server mode. What I was referring to is that clients behind OPNsense cannot use HTTP3 connections - at least I was only able to use it when I allowed incoming UDP packets.

Side note: I originally stumbled over HTTP3 in server mode, but that is a problem in itself: Nginx has support for HTTP3 only in the most current versions, which are not included in most Linux distros. Also, the syntax to enable it is terrible for multi-domain hosting, requiring massive changes in site configurations.

[meyergru]

Answering my own question a few years later: OpnSense now works with HTTP/3 as a client. I have not tested HAproxy yet.

[muchacha_grande]

Hi meyergru, what do you mean with "OpnSense now works with HTTP/3 as a client"? What does it imply?

[meyergru]

You can use HTTP/3 websites from behind OpnSense now. That did not work in 2022, as I wrote. Browsers always fell back to HTTP/2 when used behind OpnSense.

[muchacha_grande]

Oh, I never realized that. Excellent.

[RamSense]

Little bit offtopic, but I have QUIC blocked to prevent bypass, i found this article (for pfsense, but works in opnsense) about it:

Block QUIC Protocol

Google added an alternative protocol that can be used to access Google services (including YouTube). It is called QUIC. It is advisable to block QUIC protocol on your pfSense firewall, otherwise Chrome will be able to bypass web filtering.

https://docs.diladele.com/tutorials/filtering_https_traffic_squid_pfsense/additional_steps.html

[meyergru]

It is correct that HTTP/3 would bypass any transparent proxy if that is not set to intercept UDP traffic as well. If you block outgoing traffic on those ports, the browser will normally fall back to TCP.

However, see this, notably section 2.3. If I were an attacker, I would use QUIC on a different UDP port, which is within specification and should be supported. Thus, your blocking of ports 80 and 443 will keep all legitimate HTTP/3-capable sites from using QUIC, but most probably not a tricky attacker.

That is, if you trust HTTPS inspection at all. Note that it does not work for many smartphones and IoT devices anyway, if you cannot install alternate CAs on them. IDK if zenarmor or their likes do or even can keep clients from using QUIC by forbidding ALT-SVC anyway.

[Beehive]

Hi meyergru,

I've been looking into this too. Have you seen this unbound pull request?

Unbound QUIC build https://github.com/NLnetLabs/unbound/pull/871
Unbound GH branch: https://github.com/NLnetLabs/unbound/tree/dnsoverquic and
Openssl QUIC FAQ's: https://github.com/openssl/openssl/blob/master/README-QUIC.md.

Some ref's
https://github.com/quicwg/base-drafts/wiki/Implementations
https://github.com/aiortc/aioquic

I've got some time off coming up, i'll try with a vm and see if I can't get some sort on QUIC gateway working with some port forwarding rules.

[meyergru]

I do not get what you are trying to achieve/say.

In this thread, I initially wrote about OpnSense blocking QUIC for all clients. This is no longer the case as of 2024.

Then the topic turned to how to block QUIC again in order to be able to do traffic introspection (which can be circumvented via QUIC). I said - and this is by design - that you cannot do this reliably unless you disable any outgoing UDP traffic.

So, what would you use a "QUIC gateway" for? QUIC just works (tm) from behind OpnSense as of now. I have not tried in the opposite direction, but I suppose that it would work if you port-forward the ALT-SVC port.

[stanthewizzard]

BTW

Do I need to open udp something on opnsense to ip with caddy to have my services in http3 ?

Thanks