> A small clarification: QUIC does not use TCP at all, not even for an initial handshake. It is entirely UDP-based.
You are absolutely right, thanks for pointing that out! Somehow picked up that it does a TCP handshake for IP address verification and then switches over to UDP with a negotiated session token - I read up more on it now. I want to offer HTTP3 as well on my server, so I will have to find a way to properly track / rate limit new QUIC connections or traffic volume... will address that sometime later.
On the #netfilter channel on the Liberia IRC I already got help in order to match new TCP connections with the following rule:
add rule inet filter input tcp flags ack ct original packets 2 update @rate4tcp { ip saddr limit rate over 12/minute burst 24 packets }
Since I do the following at the very start of my ruleset, it will correctly only match verified new connections, but not forged ack packets:
ct state invalid drop
This will find the second packet from a client with the ack flag, which is the one concluding the TCP handshake for the new connection - and with the set entry I can track and rate limit.
My question now is though, if this will also match the ack packet, if it has to be retransmitted (packet was fumbled up in transit)...
Does "ct original packets 2" match the second packet overall from the sender, or the second valid (not incrementing on retransmit) one only?
The man pages did not go into too much detail on this unfortunately.
