On 2014-03-18, Marko Cupać <marko.cu...@mimar.rs> wrote:
> On Tue, 18 Mar 2014 01:15:16 +0000 (UTC)
> Stuart Henderson <s...@spacehopper.org> wrote:
>
>> The ruleset is now traversed in order, changes made in match rules
>> are "sticky" and affect rules lower down in the ruleset. More
>> predictable, no more "oh this 'nat pass' rule which you included
>> halfway down the ruleset actually takes effect before the
>> 'block quick' rule right at the top"... so besides allowing for
>> cleaner rulesets, you could say it's a security fix too.
>
> I am using "new" syntax for years now, and although there are a lot of
> improvements, there is also downside.
>
> I have /24 public network, where I need to have one "catch all" NAT
> rule, but also exceptions (smtp servers translate to other public IPs,
> vpn clients to their own public IPs etc).
>
> If I have a lot of subnets behind NAT firewall, I need to specify them
> all for "catch all" NAT rule, listing exceptions (this is of course
> shortened, actually I need to declare 100 or so networks and dozens of
> exceptions):
>
> table <catchallnat> { 10.20.69.0/24 10.43.26.0/22 \
> !10.20.69.15 !10.43.26.29 }
> smtp = { 10.20.69.15 }
> vpn = { 10.43.26.29 }
> ...
> match out on $ext_if inet from <catchallnat> to any nat-to $catchallnat
> match out on $ext_if inet from $smtp to any nat-to $smtp-nat
> match out on $ext_if inet from $vpn to any nat-to $vpn-nat
>
> I don't know if there would be negative consequences for other pf
> aspects, but for me it would be better if more specific match rules
> overrided more general match rules. This way I would not have to
> maintain <catchallnat> table with list of subnets and exceptions.
Just put your "catchall" rule *after* the others.
| "Subsequent rules will see packets as they look
| after any addresses and ports have been translated. "
^^^^^
