On 2024-12-18, Janne Johansson <icepic...@gmail.com> wrote: >> I have an NTP server behind an OpenBSD firewall / router and seeing some >> packet loss. The NTP server (Leontp 1200) should be able to handle the >> load easily, so I suspect the packet loss occurs at the firewall/router >> or elsewhere. >> My first suspect was the state table on the firewall/router. Due to the >> nature of the traffic, nearly every incoming packet creates a new state, >> leading to an average of about 50k to 70k states. Close to the default >> limit of 100k, so perhaps the limit was reached during peak traffic. >> The ‘memory’ counter from pfctl -si was also at ~37k. >> >> I increased the state limit to 500k and added ‘keep state (udp.single 5 >> udp.first 5 udp.multiple 5)’ to the rules that concern the NTP traffic. >> The state table is now around 20 – 30k, well below the limit. The load >> on the router is also quite low (~98% idle). > > A quick thought here is to just not keep state for those kinds of packets.
agreed. at least it would help pinpoint the problem. > Creating and cleaning out these states is still a bit of work. > > You are basically going to accept all incoming udp on this port and send back > any replies created from your ntp server, so keeping state on this > udp-port seems > to give no huge* advantage, right? > > so "pass in quick on $ext_if proto udp from any to ntp-box port 123 no > state" and > "pass in quick on $int_if proto udp from ntp-box port 123 to any no state" > basically and just have the firewall idle away even more. I would recommend putting this close to the top of the ruleset, the rules are processed in order (at least, in post-optimiser order) so you want to have these very common packets matched without evaluating against the whole ruleset. > *) yes, if someone hacks your ntp box, they can send out any kind of traffic > over udp/53 and pf would not block it, but I think there would be tons of ways > to exfiltrate data from a hacked box on the inside, so this would probably not > add much risk for an already-hacked box. > -- Please keep replies on the mailing list.
