> On Mon, Jan 31, 2011 at 04:28:28PM -0800, patrick keshishian wrote:
> >
> > Also consider explaining what defines a state (protocol, family,
> > src/dst addr/port, rdomain).
> >
note that there is a stateful filtering section that documents this
stuff in more detail.
> > Then continue fresh:
On Mon, Jan 31, 2011 at 04:28:28PM -0800, patrick keshishian wrote:
> > --- pf.conf.5 23 Jan 2011 23:34:18 - 1.488
> > +++ pf.conf.5 1 Feb 2011 00:01:05 -
> > @@ -127,7 +127,7 @@
> > the first time a packet matches a
> > .Ar pass
> > rule, a state entry is created; for subsequen
On Mon, Jan 31, 2011 at 4:03 PM, Jason McIntyre wrote:
> On Mon, Jan 31, 2011 at 11:27:18PM +0100, Henning Brauer wrote:
>>
>> i don't understand the confusion. we have a state table (let me
>> nitpick: it's a tree). a packet comes in. we do a lookup in the table,
>> looking for an entry where the
* Jason McIntyre [2011-02-01 01:14]:
> On Mon, Jan 31, 2011 at 11:27:18PM +0100, Henning Brauer wrote:
> >
> > i don't understand the confusion. we have a state table (let me
> > nitpick: it's a tree). a packet comes in. we do a lookup in the table,
> > looking for an entry where the key fields m
On Tue, Feb 01, 2011 at 10:53:31AM +1300, Paul M wrote:
> >On Mon, Jan 31, 2011 at 11:28:13AM +0100, Henning Brauer wrote:
> >>
> >>then i change my mind and we should add a note that the default pass
> >>behaviour (NOT rule, even tho there kinda is a default rule
> >>internally...) doesn't lead to
On Mon, Jan 31, 2011 at 11:27:18PM +0100, Henning Brauer wrote:
>
> i don't understand the confusion. we have a state table (let me
> nitpick: it's a tree). a packet comes in. we do a lookup in the table,
> looking for an entry where the key fields match the packet. keys are:
>
> protocol
> addre
* Jason McIntyre [2011-01-31 21:45]:
> > puh. not sure we're on the road to overengineering here.
> > basically, the flow is like this:
> > -we do a state lookup. if we find a mathcing state, we apply actions
> > associated with it and are done.
> > -if no state matched we traverse the ruleset. t
On Mon, Jan 31, 2011 at 11:28:13AM +0100, Henning Brauer wrote:
then i change my mind and we should add a note that the default pass
behaviour (NOT rule, even tho there kinda is a default rule
internally...) doesn't lead to state creation.
Perhaps it could be worded in terms of what one should
On Mon, Jan 31, 2011 at 08:41:02PM +0100, Henning Brauer wrote:
> * Jason McIntyre [2011-01-31 18:14]:
> > On Mon, Jan 31, 2011 at 11:28:13AM +0100, Henning Brauer wrote:
> > > then i change my mind and we should add a note that the default pass
> > > behaviour (NOT rule, even tho there kinda is a
On Mon, Jan 31, 2011 at 05:10:04PM +, Jason McIntyre wrote:
> On Mon, Jan 31, 2011 at 11:28:13AM +0100, Henning Brauer wrote:
> > then i change my mind and we should add a note that the default pass
> > behaviour (NOT rule, even tho there kinda is a default rule
> > internally...) doesn't lead
* Jason McIntyre [2011-01-31 18:14]:
> On Mon, Jan 31, 2011 at 11:28:13AM +0100, Henning Brauer wrote:
> > then i change my mind and we should add a note that the default pass
> > behaviour (NOT rule, even tho there kinda is a default rule
> > internally...) doesn't lead to state creation.
> it's
On Mon, Jan 31, 2011 at 11:28:13AM +0100, Henning Brauer wrote:
>
> then i change my mind and we should add a note that the default pass
> behaviour (NOT rule, even tho there kinda is a default rule
> internally...) doesn't lead to state creation.
>
it's not going to be easy deciding where to in
* Peter Hessler [2011-01-31 09:37]:
> On 2011 Jan 30 (Sun) at 22:48:17 +0100 (+0100), Henning Brauer wrote:
> :* Peter Hessler [2011-01-30 22:23]:
> :> On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
> :> :* Stuart Henderson [2011-01-30 19:03]:
> :> :> I disagree, I think i
On 2011 Jan 30 (Sun) at 22:48:17 +0100 (+0100), Henning Brauer wrote:
:* Peter Hessler [2011-01-30 22:23]:
:> On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
:> :* Stuart Henderson [2011-01-30 19:03]:
:> :> I disagree, I think it is worth mentioning explicity - I have seen
:
On Sun, Jan 30, 2011 at 10:48:17PM +0100, Henning Brauer wrote:
| * Peter Hessler [2011-01-30 22:23]:
| > On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
| > :* Stuart Henderson [2011-01-30 19:03]:
| > :> I disagree, I think it is worth mentioning explicity - I have seen
| >
* Peter Hessler [2011-01-30 22:23]:
> On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
> :* Stuart Henderson [2011-01-30 19:03]:
> :> I disagree, I think it is worth mentioning explicity - I have seen
> :> a few people run into problems because they don't realise the implicit
On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
:* Stuart Henderson [2011-01-30 19:03]:
:> I disagree, I think it is worth mentioning explicity - I have seen
:> a few people run into problems because they don't realise the implicit
:> rule is effectively "pass flags any no st
* Stuart Henderson [2011-01-30 19:03]:
> On 2011-01-30, Henning Brauer wrote:
> > * Jason McIntyre [2011-01-30 16:37]:
> >> ok, so that's not so bad. in a way we're already there: pf.conf(5) notes
> >> in PACKET FILTERING first:
> >>
> >> For block and pass, the last matching rule decid
On 2011-01-30, Henning Brauer wrote:
> * Jason McIntyre [2011-01-30 16:37]:
>> ok, so that's not so bad. in a way we're already there: pf.conf(5) notes
>> in PACKET FILTERING first:
>>
>> For block and pass, the last matching rule decides what
>> action is taken; if no rule match
* Jason McIntyre [2011-01-30 16:37]:
> ok, so that's not so bad. in a way we're already there: pf.conf(5) notes
> in PACKET FILTERING first:
>
> For block and pass, the last matching rule decides what
> action is taken; if no rule matches the packet, the default
> action i
On Sun, Jan 30, 2011 at 01:28:12PM +0100, Henning Brauer wrote:
> >
> > is this correct:
> >
> > - match rules will not work if "no state" is also used on the rule (not
> > sure that would make sense anyway)
>
> well, they do "work".
>
> > - all packets are passed by default, but effectively
* Jason McIntyre [2011-01-30 09:13]:
> On Sat, Jan 29, 2011 at 06:26:29PM +0100, Henning Brauer wrote:
> > * Ted Unangst [2011-01-29 17:36]:
> > > On Sat, Jan 29, 2011 at 5:37 AM, Henning Brauer
> > > wrote:
> > > > no, that's wrong. match rules that matched during evaluation get their
> > > > c
On Sat, Jan 29, 2011 at 06:26:29PM +0100, Henning Brauer wrote:
> * Ted Unangst [2011-01-29 17:36]:
> > On Sat, Jan 29, 2011 at 5:37 AM, Henning Brauer
> > wrote:
> > > no, that's wrong. match rules that matched during evaluation get their
> > > counters updated. aka, your rule did not match.
> >
* Ted Unangst [2011-01-29 17:36]:
> On Sat, Jan 29, 2011 at 5:37 AM, Henning Brauer
> wrote:
> > no, that's wrong. match rules that matched during evaluation get their
> > counters updated. aka, your rule did not match.
>
> ok, that's wrong. :)
>
> Somebody else told me to add a "pass all" rule
On Sat, Jan 29, 2011 at 5:37 AM, Henning Brauer
wrote:
> no, that's wrong. match rules that matched during evaluation get their
> counters updated. aka, your rule did not match.
ok, that's wrong. :)
Somebody else told me to add a "pass all" rule at the top of the rule
set. Then it did work. Bu
no, that's wrong. match rules that matched during evaluation get their
counters updated. aka, your rule did not match.
see pf_counters_inc() in sys/net/pf.c
* Josh Hoppes [2011-01-29 07:11]:
> If I'm reading the man page correctly the rule only counts if it's the
> one creating a state. Since th
If I'm reading the man page correctly the rule only counts if it's the
one creating a state. Since the match rule won't be the deciding one
to generate a state or not I expect it will never actually count on
those statistics.
On Fri, Jan 28, 2011 at 8:48 PM, Ted Unangst wrote:
> I am apparently n
I am apparently not getting pf at a very simple level. Here's my rule:
match proto tcp from any to any port 80 label "web"
Here's the output of pfctl -sr -v after visiting a few websites:
match proto tcp from any to any port = www label "web"
[ Evaluations: 1398 Packets: 0 Bytes:
28 matches
Mail list logo
