Discussion:
How to support QUIC with ipfw
Michael Sierchio
2021-04-11 20:24:49 UTC
Permalink
Hi, all. I noticed my firewall was dropping what seemed to be unsolicited
UDP connections from Google and Facebook, but this turned out to be QUIC
traffic. The traffic can be initiated by the browser (or other supporting
software) or the server. The problem is that dynamic rules generally don't
cut it – udp traffic here is predominantly NTP and DNS, and the dynamic
rule lifetime for UDP is very short (3-6 s). And of course they don't work
at all for traffic initiated by the server side.

My kludgy solution at present is to troll the dynamic rules, locate the TCP
connections in them with 443 and 5228 as the target port, and add those
addresses to a table that permits UDP traffic from those ports. I only see
QUIC on IPv6, by the way. The cron job runs once per minute, adds the
addresses seen, and deletes those older than N seconds. I use time_t
seconds since epoch as the table arg, so I know when it was added or
refreshed.

Any suggestions on a better solution?

Thanks.

– M
--
"Well," Brahmā said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata
Matt Joras
2021-04-11 21:20:28 UTC
Permalink
Hi Michael,
Post by Michael Sierchio
Hi, all. I noticed my firewall was dropping what seemed to be unsolicited
UDP connections from Google and Facebook, but this turned out to be QUIC
traffic. The traffic can be initiated by the browser (or other supporting
software) or the server. The problem is that dynamic rules generally don't
cut it – udp traffic here is predominantly NTP and DNS, and the dynamic
rule lifetime for UDP is very short (3-6 s). And of course they don't work
at all for traffic initiated by the server side.
QUIC connections aren't initiated by the server. The browser is initiating
these connections. I'm not an ipfw user, the best generic firewall strategy
would be to have some sort of flow tracking for ~30s for UDP flows
associated with tuples originating on the client for remote port 443. 443
will cover the vast majority of Internet cases, as QUIC is only being used
at scale for HTTP/3.
Post by Michael Sierchio
My kludgy solution at present is to troll the dynamic rules, locate the TCP
connections in them with 443 and 5228 as the target port, and add those
addresses to a table that permits UDP traffic from those ports. I only see
QUIC on IPv6, by the way. The cron job runs once per minute, adds the
addresses seen, and deletes those older than N seconds. I use time_t
seconds since epoch as the table arg, so I know when it was added or
refreshed.
Any suggestions on a better solution?
Thanks.
– M
--
"Well," Brahmā said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."
- The Mahābhārata
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-net
Matt Joras
Michael Sierchio
2021-04-11 21:26:57 UTC
Permalink
Post by Matt Joras
Hi Michael,
Post by Michael Sierchio
Hi, all. I noticed my firewall was dropping what seemed to be unsolicited
UDP connections from Google and Facebook, but this turned out to be QUIC
traffic. The traffic can be initiated by the browser (or other supporting
software) or the server. The problem is that dynamic rules generally don't
cut it – udp traffic here is predominantly NTP and DNS, and the dynamic
rule lifetime for UDP is very short (3-6 s). And of course they don't work
at all for traffic initiated by the server side.
QUIC connections aren't initiated by the server. The browser is initiating
these connections. I'm not an ipfw user, the best generic firewall strategy
would be to have some sort of flow tracking for ~30s for UDP flows
associated with tuples originating on the client for remote port 443. 443
will cover the vast majority of Internet cases, as QUIC is only being used
at scale for HTTP/3.
Hej, Matt. Thanks. That's a solution that occurred to me, but it means a
ton of dynamic rules will get instantiated for ephemeral DNS lookups – 3
seconds is a very long time for a conversation with a DNS server, because
it has probably recursed from the root zone all the way to the A record in
a fraction of that time. 30 seconds is forever – well, since UDP doesn't
have an analogue to a FIN or RST, the rule doesn't go away when the
conversation does.

I'll get some metrics on it. Thanks again.
--
"Well," Brahmā said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata
Michael Sierchio
2021-04-11 21:43:32 UTC
Permalink
Sadly, no. That would be a great feature. The sysctl setting for
dynamic rule lifetime is for all UDP.

But since the firewall itself is responsible for most of the
DNS and NTP traffic, I can write non-stateful rules for that. The
recursive resolver on that port won't respond to outside queries for
DNS, and NTP ignores commands from strangers.
Post by Matt Joras
Hi Michael,
Post by Michael Sierchio
Post by Matt Joras
Hi Michael,
Post by Michael Sierchio
Hi, all. I noticed my firewall was dropping what seemed to be
unsolicited
Post by Michael Sierchio
Post by Matt Joras
Post by Michael Sierchio
UDP connections from Google and Facebook, but this turned out to be
QUIC
Post by Michael Sierchio
Post by Matt Joras
Post by Michael Sierchio
traffic. The traffic can be initiated by the browser (or other
supporting
Post by Michael Sierchio
Post by Matt Joras
Post by Michael Sierchio
software) or the server. The problem is that dynamic rules generally don't
cut it – udp traffic here is predominantly NTP and DNS, and the
dynamic
Post by Michael Sierchio
Post by Matt Joras
Post by Michael Sierchio
rule lifetime for UDP is very short (3-6 s). And of course they don't work
at all for traffic initiated by the server side.
QUIC connections aren't initiated by the server. The browser is
initiating
Post by Michael Sierchio
Post by Matt Joras
these connections. I'm not an ipfw user, the best generic firewall
strategy
Post by Michael Sierchio
Post by Matt Joras
would be to have some sort of flow tracking for ~30s for UDP flows
associated with tuples originating on the client for remote port 443.
443
Post by Michael Sierchio
Post by Matt Joras
will cover the vast majority of Internet cases, as QUIC is only being
used
Post by Michael Sierchio
Post by Matt Joras
at scale for HTTP/3.
Hej, Matt. Thanks. That's a solution that occurred to me, but it means a
ton of dynamic rules will get instantiated for ephemeral DNS lookups – 3
seconds is a very long time for a conversation with a DNS server, because
it has probably recursed from the root zone all the way to the A record
in
Post by Michael Sierchio
a fraction of that time. 30 seconds is forever – well, since UDP doesn't
have an analogue to a FIN or RST, the rule doesn't go away when the
conversation does.
Is it not possible to do the dynamic rule instantiation for select UDP
ports, i.e. 443? That may cause issues if DNS-over-HTTP/3 becomes a
thing, but at least for now it would exclude DNS.
Post by Michael Sierchio
I'll get some metrics on it. Thanks again.
--
"Well," Brahmā said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five
hundred."
Post by Michael Sierchio
- The Mahābhārata
Matt Joras
--
"Well," Brahmā said, "even after ten thousand explanations, a fool is no
wiser, but an intelligent person requires only two thousand five hundred."

- The Mahābhārata
Loading...