On 2023/07/19 19:13, mabi wrote: > ------- Original Message ------- > On Wednesday, July 19th, 2023 at 12:40 PM, Stuart Henderson > <stu.li...@spacehopper.org> wrote: > > > I don't think you understood what I wrote then - they are the > > opposite of helpful here. > > No, I do understand what you wrote but I should have explained my case > in more details. Behind my OpenBSD firewall I have two authoritative DNS > servers and because of recent DDoS originating from >12k IPs against UDP > port 53 on these two servers the whole network behind the firewall gets > unresponsive or has a high packet loss because there is over 2 million > states in the PF states table during the attack. So in my specific case > I don't care that cloudflare or other external DNS servers can not query > my DNS authoritative servers for a few seconds or minutes but I do care > a lot that my whole rest of my network and servers behind the OpenBSD > firewall stays responsive. It's a trade-off I can totally accept and > welcome. Furthermore when I have so many state entries due to a DDoS on > UDP port 53, CARP breaks as well as the OSPF sessions with my border > routers because it can not communicate properly within the defined > timeouts.
If PF is struggling as it is, there's a good chance it will buckle completely if it has to do source tracking too Did you already tweak timeouts for the rule passing UDP DNS traffic? Defaults are 60s/30s/60s for udp.first, udp.single and udp.multiple respectively, that is much too high for a very busy DNS server - you can set them on the specific rule itself rather than changing defaults for all rules. For an auth server which is expected to respond quickly they can be cranked way down. (If that is still too many states, I wonder if your network might actually be happier if you "pass quick proto udp to $server port 53 no state" and "pass quick proto udp from $server port 53 no state" right at the top of the ruleset). Are you already using your DNS server's response rate limiting features?
