On Sun, Jul 16, 2006 at 11:44:56PM +0200, Daniel Hartmeier wrote:
> On Sun, Jul 16, 2006 at 11:05:27PM +0200, Dag-Erling Smørgrav wrote:
>
> That would then block all packets on all interfaces, until a ruleset is
> loaded. If anything started through the startup scripts needs unblocked
> packets (
Daniel Hartmeier <[EMAIL PROTECTED]> writes:
> On Mon, Jul 17, 2006 at 01:36:01AM +0300, Giorgos Keramidas wrote:
>
>> I haven't verified that this is the _only_ change needed to make PF
>> block everything by default, but having it as a compile-time option
>> which defaults to block everything wo
[Replying to the latest message available]
Okay, now this is getting pretty pointless. It started out pretty promissing
with an attempt to really investigate into a problem that might exist with
the way we boot up pf. No-one has yet provided evidence that it does exist,
though. What Daniel a
Current FreeBSD problem reports
Critical problems
Serious problems
S Submitted Tracker Resp. Description
---
o [2005/06/15] kern/82271 pf [pf] cbq scheduler cause bad latency
f [2005/09/13] kern/8607
On 2006.07.16 20:23:15 +0200, Daniel Hartmeier wrote:
> The "hole" being discussed is the time, during boot, before pf is fully
> functional with the production ruleset. For a comparatively long time,
> the pf module isn't even loaded yet. The time after module load and
> enabling pf with the prod
On 7/17/06, Simon L. Nielsen <[EMAIL PROTECTED]> wrote:
Personally I would still like a default to deny knob, but that's
mainly to handle the case of an invalid ruleset which causes pf to be
left open. Yes, this is only a problem when the admin screws up, but
it happens...
Since you mention it
Hi,
Simon L. Nielsen wrote:
Since nobody else seems to have actually done this, I took a look at
FreeBSD's rcorder (on my -CURRENT laptop) and actually I don't really
see a hole. Most importantly pf is enabled before routing.
I did this yesterday, but this thread has gotten quite activ
