Bacula File/Storage Connection Woes using PF
Greg.Hennessy at nviz.net
Wed Mar 26 09:09:48 UTC 2008
Jeremy Chadwick wrote:
> This isn't a reply to you (Doug), but -- do not blindly use "keep state"
Hard cases make for bad laws. I have got to point out the error in the
> There's been too many cases I've experienced where using "keep state"
> blindly results in state-mismatch increasing at a very fast rate. When
> I implemented this mentality on our production servers, our users
> started pointing out that scp's between machines would randomly get
> severed mis-stream, same with ssh sessions where large TCP windows were
> used (such as doing 'dmesg' over and over):
Which (taking a rough guess) looking at your rule set in the above has
very little to do with 'keep state' and a lot to do with 'modulate
state'. IIRC there is a filed bug which displays all of the
aforementioned symptoms when modulate state meets selective
acknowledgement (SACK). I'm sure Max has the gory detail, it may even be
> The "use keep state on everything!" attitude seems to stem from people
> reading the OpenBSD pf.conf documentation, which states that as of
> OpenBSD 4.1, "keep state" is implicit on every rule (meaning it's done
> whether you say "keep state" or not). FreeBSD's pf isn't like this.
You miss out the most important bit of the new PF 4.1 state keeping
defaults, 'flags S/SA'.
Our cousins over the road in the OpenBSD neighbourhood have done this
precisely because of the issues caused in prior versions of PF by using
stateless rules and/or establishing TCP state on anything other than the
3 way handshake.
> It gets more confusing when you consider the fact that even though UDP
> and ICMP are stateless protocols, pf can keep track of their state too,
> though I don't know if FreeBSD pf supports that (OpenBSD pf does).
This is not a flame, but if you really do not know that, you really
should not be publicly advocating a position on the basis of incomplete
More information about the freebsd-pf