At 3:18 PM +0000 11/12/06, Stuart Henderson wrote:
Yes, exactly. Other packets (those which don't only have SYN out of
SYN+ACK) don't create state at all, but they're allowed through when
they match an existing state (src/dest port+address, as you'd expect,
and sequence numbers must also be within a reasonable window).
I think one of the main reasons people used to avoid keeping state
was so that a newly-booted firewall could synchronize with existing
packet flows - say, if you want to replace one firewall with a new
one - but we have CARP/PFSYNC for that now so it's less important).
Generally keeping state saves cpu time, and increases security.
keep-state also seems to cause problems in some situations, at least
for 'pf' on freebsd. I had two problems which I eventually tracked
down to a single rule:
pass out quick proto { tcp, udp } all keep state
If I had just that one rule in my pf.conf, and no other rules at
all, then both problems happened.
One problem has to do with 'lpq' requests from remote hosts. If a
given remote-host sent multiple 'lpq's in quick succession to a
print server, and if that print server had the above rule in it,
then the later lpq's would hang. I think that the problem is that
lpq/lpd expects to reuse that port faster than 'pf' expects it to.
The other problem was with a chat server that I run. With the
above single-rule pf.conf file, occasionally some users who had
been on for a long time would be disconnected. This is obviously
a very different scenario than 'lpq', since this wasn't an issue
with any port being reused. I didn't pin down what that was, as
the people on the chat server were getting a bit annoyed with being
guinea pigs for debugging the problem, and the problem would only
happen to people who had been on for a few days straight. (and
thus, it would require a LOT of packet-sniffing before I could
catch the problem in action).
As I said this was on freebsd, with whatever version of 'pf' that
we had back in July. I have no idea if the same issues would come
up with the most-recent version, or with 'pf' on openbsd. I'm not
expecting anyone to drop what they're doing for this (*), but I'm
just saying neither of these problems had anything to do with a
newly-booted firewall synchronizing with some existing packet flow.
(* - certainly I didn't drop what I was doing. I just changed my
pf.conf so the problems went away)
--
Garance Alistair Drosehn = [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Institute or [EMAIL PROTECTED]
