It is due to history. ipf didn't have stateful, at all.
the first version of pf didn't have stateful, but it was incrementally added starting after 1 year over a period of 3 years. during development, it was not the default. other projects started adopting pf. (here is where it ges ugly) Along with many other advances, stateful was made the default. but other projects kept their old code, or performed partial updates of the code, or didn't change the defaults like we did therefore the lack of unification in the ecosystem can be directly blamed on those other projects who adopted our code, but soon abandoned efforts to keep things updated. but there is another piece of blame which can be apportioned i suppose -- a wise man does not assume that one system is the same as another, and reads the MODERN documentation rather than something dated off the web. Keeping things identical takes much effort, and one should not assume the work was done. > Thanks for your answer. > > The disturbing thing for me was that I work on several firewalls, and some > have the flags S/SA keep state options, and some not… so as I’m quite new to > pf I was really wondering. > > f.g. > > > Le 22 oct. 2018 à 17:09, Daniel Corbe <dco...@hammerfiber.com> a écrit : > > > > at 10:04 AM, Frédéric Goudal <frederic.gou...@bordeaux-inp.fr> wrote: > > > >> - is there any reason to add keep state to a pass rule ? > > > > 1) UDP rules don’t keep state by default. > > > > 2) Even for TCP connections, it’s better to explicitly throw a keep state > > on there for clarity, so that people who come in behind you and actually > > bother reading the documentation don’t have to ask the same question. > > There’s also other available options for TCP connections that you might > > want to look into, such as flags S/SA (only allow initial handshake between > > endpoints that don’t have an established state) and modulate state, which > > generates strong, random ISNs for new connections. > > > > > > > > > > > > >
