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.
--
Marko Cupać
