On 2010-06-14, william dunand <william.dun...@gmail.com> wrote:
> On Tue, Jun 15, 2010 at 12:28 AM, Stuart Henderson <s...@spacehopper.org>
> wrote:
>> On 2010-06-14, william dunand <william.dun...@gmail.com> 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 sent a PR for this so it's not lost - it will probably be
>> kernel/6401.
>>
>> You don't need it for your requirements though:
>>
>>> ### 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 ...
>>
>> add "block out log on $ext_if proto tcp to port 25" here
>>
>>> 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
>>
>> 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 Translation section:
>
> Subsequent rules will see packets as they look after any addresses and
> ports have been translated. These rules will therefore have to filter
> based on the translated address and port number.
>
> So unless I am reading it wrong, I think one would expect the "match
> ... nat-to" rules to have to be after the related pass rules.
ah, yes, I see what you mean, but this depends on the values chosen for
A, B, somewhere, something.
it might be simpler to combine the rules e.g.
pass out on $ext_if proto tcp from {A, B} to port 25 nat-to $something
each packet that doesn't match existing state passes through the ruleset.
if a 'match...nat-to' (or rdr-to, scrub, etc) is seen, the settings are
remembered and applied to the next matching pass/block rule. ruleset
processing stops at the first 'quick' rule, otherwise the last matching
rule (pass/block) is used, with the modifiers from previous match rules
being used.
if a rule which changes the address is traversed, following rules see
the new address. without this it would be impossible to use 'match...nat-to'
as a simple replacement for existing nat rules (otherwise you would need
widespread reordering to convert old rulesets).
