On 10/3/05, jared r r spiegel [EMAIL PROTECTED] wrote:
mathematically, yeah, less rules to evaluate = faster, but
without someone bucking up and making a nice demonstration of why
they needed to do 'quick' a lot, the ~tri-monthly discussion of
someone being upset about the last-match
jared r r spiegel wrote:
i'd VERY much like to see someone put up a short little www-type
( or whatever ) illustration of how they were really experiencing
a service-affecting performance degredation which was solved by
the use of 'quick' in their ruleset.
For what it's worth, I've
On Sat, Oct 01, 2005 at 08:50:13AM -0500, Travis H. wrote:
Yeah, I neglected stateful matching. I should have said that every
packet that has to run the gauntlet of rules, has to run all of them.
Subsequent reading of the PF FAQ confirms that there's no deep
evaluation-reordering magic
On Sat, Oct 01, 2005 at 04:43:40AM -0500, Travis H. wrote:
Ah, but the matching engine doesn't have to traverse the whole rule
list that way. Unless pf is doing something really tricky, every
packet will have to traverse every firewall rule without use of
quicks. On a complicated, busy
In pf nat rules also the first match wins
__but__
in pf filter rules the __last__ match wins.
In fact that is the one thing I don't like in pf, but to have a first
match win you can use the magic word quick in all your pass and block
rules. (e.g pass in quick)
And thereby end up with yards of
On Sat, 1 Oct 2005 04:43:40 -0500, Travis H. wrote:
In pf nat rules also the first match wins
__but__
in pf filter rules the __last__ match wins.
In fact that is the one thing I don't like in pf, but to have a first
match win you can use the magic word quick in all your pass and block
rules.
--On 01 October 2005 04:43 -0500, Travis H. wrote:
Ah, but the matching engine doesn't have to traverse the whole rule
list that way. Unless pf is doing something really tricky, every
packet will have to traverse every firewall rule without use of
quicks.
huh? Before any rules are evaluated,
huh? Before any rules are evaluated, the filter checks whether the
packet matches any state. If it does, the packet is passed without
evaluation of any rules. - pf.conf(5)
Yeah, I neglected stateful matching. I should have said that every
packet that has to run the gauntlet of rules, has to
--On 01 October 2005 08:50 -0500, Travis H. wrote:
huh? Before any rules are evaluated, the filter checks whether the
packet matches any state. If it does, the packet is passed without
evaluation of any rules. - pf.conf(5)
Yeah, I neglected stateful matching. I should have said that every
Travis H. wrote:
Yeah, I neglected stateful matching. I should have said that every
packet that has to run the gauntlet of rules, has to run all of them.
Not necessarily. Search for pf and skip-steps, something that isn't
documented much inside OpenBSD, because it is always on and being
On Saturday, October 1, Travis H. wrote:
Yeah, I neglected stateful matching. I should have said that every
packet that has to run the gauntlet of rules, has to run all of them.
Subsequent reading of the PF FAQ confirms that there's no deep
evaluation-reordering magic going on, that quick
Nico Meijer wrote:
Well, if I suggested to port netfilter to OpenBSD I would most
probably be killed in seconds. ;)
If you're lucky. ;-)
You might want to check http://openbsd.unixtech.be/books.html and more
specifically get a hold of Jacek's book.
Thanks, Nico - I'll have a look.
--
Thanks to the kind help on this list, my test firewall successfully runs
OpenBSD 3.7 and is basically configured. I now need to think about
migrating my existing netfilter rule set to pf and would like to ask
also some general questions to understand the concept(s) suffiently.
If I understand
On 8 Sep 2005, at 13:55, Stephan A. Rickauer wrote:
Thanks to the kind help on this list, my test firewall successfully
runs OpenBSD 3.7 and is basically configured. I now need to think
about migrating my existing netfilter rule set to pf and would like
to ask also some general
Subject: Re: Migration to PF - some questions
On 8 Sep 2005, at 13:55, Stephan A. Rickauer wrote:
Thanks to the kind help on this list, my test firewall successfully
runs OpenBSD 3.7 and is basically configured. I now need to think
about migrating my existing netfilter rule set to pf and would
--On 08 September 2005 14:55 +0200, Stephan A. Rickauer wrote:
If I understand correctly, pf has no 'forward' chain like netfiler
(which is probably by design).
I'm guessing at what netfilter 'forward chain' means here since
(presumably like many people here) I don't have much need to admin
Hello
On 8 Sep 2005, at 13:55, Stephan A. Rickauer wrote:
Thanks to the kind help on this list, my test firewall successfully
runs OpenBSD 3.7 and is basically configured. I now need to think
about migrating my existing netfilter rule set to pf and would like
to ask also some general
9/8/2005, Stephan A. Rickauer [EMAIL PROTECTED]
napisa3(a):
Thanks to the kind help on this list, my test firewall successfully runs
OpenBSD 3.7 and is basically configured. I now need to think about
migrating my existing netfilter rule set to pf and would like to ask
also some general questions
--On 08 September 2005 16:32 +0200, Stephan A. Rickauer wrote:
$if_in=xl0
$if_out=xl1
pass in on $if_in keep state
pass out on $if_out keep state
Ok, let's stick to that example. Imagine a firewall having three
interfaces connecting Internet, LAN and DMZ. When I would like to
allow SMTP
From: Stephan A. Rickauer [mailto:[EMAIL PROTECTED]
Gaby vanhegan wrote:
$if_in=xl0
$if_out=xl1
pass in on $if_in keep state
pass out on $if_out keep state
Ok, let's stick to that example. Imagine a firewall having three
interfaces connecting Internet, LAN and DMZ. When I would
On 2005-09-08 16:51, Gaby vanhegan wrote:
On 8 Sep 2005, at 15:32, Stephan A. Rickauer wrote:
Gaby vanhegan wrote:
$if_in=xl0
$if_out=xl1
pass in on $if_in keep state
pass out on $if_out keep state
Ok, let's stick to that example. Imagine a firewall having three
interfaces connecting
Stephan A. Rickauer wrote:
Gaby vanhegan wrote:
$if_in=xl0
$if_out=xl1
pass in on $if_in keep state
pass out on $if_out keep state
Ok, let's stick to that example. Imagine a firewall having three
interfaces connecting Internet, LAN and DMZ. When I would like to
allow SMTP traffic to my
On 8 Sep 2005, at 16:13, Erik Wikstrvm wrote:
# Put this macro at the top
if_dmz=xl2
# Later on in the ruleset, deny everything but smtp to the DMZ
block in on $if_dmz keep state
pass in on $if_dmz from any to 1.2.3.4 port smtp keep state
Wouldn't that block traffic from the SMTP-server
Hi Stephan,
Well, if I suggested to port netfilter to OpenBSD I would most
probably be killed in seconds. ;)
If you're lucky. ;-)
You might want to check http://openbsd.unixtech.be/books.html and more
specifically get a hold of Jacek's book.
HTH... Nico
24 matches
Mail list logo
