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 subsequent packets
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 2011 Jan 30 (Sun) at 22:48:17 +0100 (+0100), Henning Brauer wrote:
:* Peter Hessler phess...@theapt.org [2011-01-30 22:23]:
: On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
: :* Stuart Henderson s...@spacehopper.org [2011-01-30 19:03]:
: : I disagree, I think it is worth
* Peter Hessler phess...@theapt.org [2011-01-31 09:37]:
On 2011 Jan 30 (Sun) at 22:48:17 +0100 (+0100), Henning Brauer wrote:
:* Peter Hessler phess...@theapt.org [2011-01-30 22:23]:
: On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
: :* Stuart Henderson
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 insert
* Jason McIntyre j...@kerhand.co.uk [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
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 to
On Mon, Jan 31, 2011 at 08:41:02PM +0100, Henning Brauer wrote:
* Jason McIntyre j...@kerhand.co.uk [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
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
* Jason McIntyre j...@kerhand.co.uk [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
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
address
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 state
* Jason McIntyre j...@kerhand.co.uk [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
On Mon, Jan 31, 2011 at 4:03 PM, Jason McIntyre j...@kerhand.co.uk 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
On Sat, Jan 29, 2011 at 06:26:29PM +0100, Henning Brauer wrote:
* Ted Unangst ted.unan...@gmail.com [2011-01-29 17:36]:
On Sat, Jan 29, 2011 at 5:37 AM, Henning Brauer lists-open...@bsws.de
wrote:
no, that's wrong. match rules that matched during evaluation get their
counters updated.
* Jason McIntyre j...@kerhand.co.uk [2011-01-30 09:13]:
On Sat, Jan 29, 2011 at 06:26:29PM +0100, Henning Brauer wrote:
* Ted Unangst ted.unan...@gmail.com [2011-01-29 17:36]:
On Sat, Jan 29, 2011 at 5:37 AM, Henning Brauer lists-open...@bsws.de
wrote:
no, that's wrong. match rules
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 with no state
* Jason McIntyre j...@kerhand.co.uk [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
On 2011-01-30, Henning Brauer lists-open...@bsws.de wrote:
* Jason McIntyre j...@kerhand.co.uk [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
* Stuart Henderson s...@spacehopper.org [2011-01-30 19:03]:
On 2011-01-30, Henning Brauer lists-open...@bsws.de wrote:
* Jason McIntyre j...@kerhand.co.uk [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
On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
:* Stuart Henderson s...@spacehopper.org [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
* Peter Hessler phess...@theapt.org [2011-01-30 22:23]:
On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
:* Stuart Henderson s...@spacehopper.org [2011-01-30 19:03]:
: I disagree, I think it is worth mentioning explicity - I have seen
: a few people run into problems
On Sun, Jan 30, 2011 at 10:48:17PM +0100, Henning Brauer wrote:
| * Peter Hessler phess...@theapt.org [2011-01-30 22:23]:
| On 2011 Jan 30 (Sun) at 19:04:50 +0100 (+0100), Henning Brauer wrote:
| :* Stuart Henderson s...@spacehopper.org [2011-01-30 19:03]:
| : I disagree, I think it is worth
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 josh.hop...@gmail.com [2011-01-29 07:11]:
If I'm reading the man page correctly the rule only counts if it's the
one
On Sat, Jan 29, 2011 at 5:37 AM, Henning Brauer lists-open...@bsws.de
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.
* Ted Unangst ted.unan...@gmail.com [2011-01-29 17:36]:
On Sat, Jan 29, 2011 at 5:37 AM, Henning Brauer lists-open...@bsws.de
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
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: 0
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 ted.unan...@gmail.com
28 matches
Mail list logo
