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) log rule is located
after the match rule, then it is properly logged (which seems in line
with the man page). Unfortunately, I don't think I can change the
order of the rules in my particular case.
Here is a condensed version of my rule-set:
<pf.conf>
ext_if = "bge0"
int_if = "em0"
cross_if = "bge1"
non_routable = "{127.0.0.0/8, 192.168.0.0/16, 172.16.0.0/12,
10.0.0.0/8, 169.254.0.0/16, 192.0.2.0/24, 0.0.0.0/8, 240.0.0.0/4}"
...
bunch of aliases
...
set skip on {lo, $cross_if, em1}
set block-policy return
set optimization normal
altq on $ext_if priq bandwidth 46Mb queue {q_max, q_hig, q_def, q_low}
queue q_max priority 15
queue q_hig priority 10
queue q_def priority 5 priq(default)
queue q_low priority 0
antispoof for {$ext_if, $int_if}
block in quick on $ext_if from $non_routable to any
block out quick on $ext_if from any to $non_routable
block quick inet6
block all
pass quick on {$ext_if, $int_if} proto carp keep state (no-sync) queue q_hig
match on $ext_if all scrub (reassemble tcp random-id)
### Ext inbound ###
match in on $ext_if proto {tcp, udp} from any to $ext_if:network queue
(q_def, q_hig)
pass in on $ext_if proto icmp from any to $ext_if:network queue q_low
pass in on $ext_if proto tcp from $somewhere to self port 22 keep
state (no-sync) queue (q_low, q_max)
pass in on $ext_if proto tcp from $somewhere to self port 80 keep
state (no-sync) queue (q_low, q_max)
... bunch of pass in on $ext_if from something to something rdr-to something ...
### Ext outbound ###
match out on $ext_if from any to any queue (q_low, q_max)
... bunch of pass out on $ext_if from something to something ...
pass out on $ext_if proto tcp from {A, B} to any port 25
match out on $ext_if from $somewhere to any nat-to $something
### Int inbound ###
pass in on $int_if
### Int outbound ###
pass out on $int_if
</pf.conf>
So what I would like to do is simply to log blocked outgoing smtp
traffic (not coming from A or B), but I can't find a clean way (it is
in prod so I don't want to turn it upside down) to do it as long as my
nat-to rule has to be at the end of the "ext outbound" section, and my
block rules have to stay on top of everything.
Regards,
William
On Mon, Jun 14, 2010 at 8:35 PM, Stuart Henderson <s...@spacehopper.org> wrote:
> 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 <william.dun...@gmail.com> wrote:
>> 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:
>>
>><pf.conf>
>> 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 to x.x.x.x port 80
>><\pf.conf>
>>
>> Then if I just try a simple hping on x.x.x.x on port 80, I expect to
>> see the packet blocked, and logged on pflog0, but I don't see it.
>> If I just add a "log" to the "match" rule, then my hping packet will
>> be logged twice on pflog0 (for the block and the match).
>> I observe analog behavior if I replace the block rule by a similar pass rule.
>>
>> So it seems impossible to log specific traffic if this traffic is
>> matched somewhere by a simple "match" rule, one would need to add the
>> "log" directive to the latter, which might of course not be desirable.
>>
>> Is this the expected behavior, or is there something I am overlooking?
>>
>> Any help would be greatly appreciated.
>>
>> Regards,
>> William
