* Stuart Henderson [2010-06-15 13:00]:
> That relates to logging only. 'match log' is special as it is
> handled immediately when the match rule is processed.
you wish. i wish. that is what it should be, but we didn't get this
changed to that yet. i know of at least two little bugs with logging
a
* william dunand [2010-06-14 11:03]:
> Dear list,
>
> I just noticed something strange with pf (4.7) and I wondered if
> someone could help me to understand it.
>
> Let's consider the following simple rule-set:
>
>
> set skip on lo0
> pass all
> block out log on bge0 inet proto tcp from any to
> When you use 'match' to set options (e.g. nat-to) it does that for
> for *subsequent* rules, it doesn't retrospectively loop back and
> change addresses on a rule which has *already* been processed.
Yes I know that much. And as my pass rules care about the not-yet
translated source addresses, th
On 2010/06/15 11:13, william dunand wrote:
> > ah, yes, I see what you mean, but this depends on the values chosen for
> > A, B, somewhere, something.
>
> Yeah sorry for the vagueness :)
> Anyway I tested it just in case and as expected it didn't work.
>
> > it might be simpler to combine the rul
> ah, yes, I see what you mean, but this depends on the values chosen for
> A, B, somewhere, something.
Yeah sorry for the vagueness :)
Anyway I tested it just in case and as expected it didn't work.
> it might be simpler to combine the rules e.g.
>
> pass out on $ext_if proto tcp from {A, B} to
On 2010-06-14, william dunand wrote:
> On Tue, Jun 15, 2010 at 12:28 AM, Stuart Henderson
> wrote:
>> On 2010-06-14, william dunand wrote:
>>> Well this rule-set's purpose is just to illustrate the "problem".
>>
>>
>> Now you would expect any outgoing traffic to be logged. It isn't.
>> I've sen
Stuart,
Thanks for your answer, and for sending the PR.
> Ah, for that we can go simpler:
>
> pass log
> match
Indeed, sorry for the noise.
> move this nat-to rule above the pass rule/s that it needs to apply
> to.
Well, I'll have to test tomorrow, but according to pf.conf man page,
in the Tran
On 2010-06-14, william dunand wrote:
> Well this rule-set's purpose is just to illustrate the "problem".
Ah, for that we can go simpler:
pass log
match
Now you would expect any outgoing traffic to be logged. It isn't.
I've sent a PR for this so it's not lost - it will probably be
kernel/6401.
Hi Stuart,
Thanks for your answer.
Well this rule-set's purpose is just to illustrate the "problem".
In my actual rule-set, I use several match statements to set default
queuing policy for block of rules, and of course for nating outgoing
traffic.
I noticed ny the way that if the block (or pass)
While this is wierd behaviour, I don't see what purpose this
match rule can serve, so it's not entirely surprising this hasn't
been noticed before... What are you trying to do with this?
On 2010-06-14, william dunand wrote:
> Dear list,
>
> I just noticed something strange with pf (4.7) and I wo
Dear list,
I just noticed something strange with pf (4.7) and I wondered if
someone could help me to understand it.
Let's consider the following simple rule-set:
set skip on lo0
pass all
block out log on bge0 inet proto tcp from any to x.x.x.x port 80
match out on bge0 inet proto tcp from any t
11 matches
Mail list logo
