[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openbsd-pf
Subject:    Re: DNS answers blocked?
From:       Stuart Henderson <stu () spacehopper ! org>
Date:       2007-03-06 9:31:08
Message-ID: 20070306093107.GA11532 () bootes ! spacehopper ! org
[Download RAW message or body]

On 2007/03/06 01:04, Karl O. Pinc wrote:
> 
> On 03/05/2007 01:05:25 PM, Peter N. M. Hansteen wrote:
> >hard to tell without taking a peek at your actual rule set, but could
> >it be that you forgot "keep state"
> 
> with: flags S/SA

Flags apply to TCP; name lookups are usually done over UDP.

> >in the pass rules which let your
> >name service queries through?
> 
> the omission of which is a common mistake.

This was a useful way to have a firewall synchronize to existing
connections at reboot, avoiding dropping all the active connections.
It meant losing some security advantages of stateful filtering
(e.g. checking that TCP sequence numbers are in an acceptable
range) but gave some other benefits (e.g. lowered CPU use).
But now carp+pfsync are available, they're a better way to handle
many things you'd want to use this for.

So, not using 'flags s/sa' didn't used to be a mistake (indeed,
it was done in the example pf.conf), and it was sometimes done
intentionally.

More recently some TCP stacks (notably in recent Linux kernels
and some new Microsoft product) have changed default settings,
meaning that any stateful firewall carrying out sequence-number
checks must only create state from session setup.

Recent PF versions (e.g. the one in -current OpenBSD that will
become OpenBSD 4.1) do this by default. Before then, people
seeing problems with connections starting up but then stalling
especially where it only affects certain OS should look at
making sure all TCP rules have 'flags S/SA keep state' early
in the fault-finding process.

(Sorry this doesn't help the OP much but I think it's worth
clarifying).
[prev in list] [next in list] [prev in thread] [next in thread]