>> If you want PF, go back and read about it. Learn to handle it in the
>> way it was designed, don't try to blend it to whatever you used
>> before. It useless if you do that.
PF has evolved over time to fit in with what developers have needed...
Not to say that's something _anyone_ can do, but it's not set in stone
"you can only use it as designed" :)
On 2018-05-09, Martin Gignac <martin.gig...@gmail.com> wrote:
> I get your point, I really do. I'm just trying to figure out a way
> *not* to have to specify each and every subnet behind a firewall
> interface as these will change dynamically over time and be learned
> via OSPF. That's why I was looking for a way to express filtering
> rules for forwarded traffic based on a combination of ingress and
> egress interfaces for cases where this is considered enough (i.e.
> specific subnets don't have to be expressed in the rule).
Not sure if it's going to be any use for your particular setup, but if
these are coming in as AS External LSAs ("ospfctl sh da ext") and you
have a way to get an "External route tag" set on them, you can have
ospfd tag the routes with a route label, and then PF can match addresses
on route labels. See "rtlabel" in ospfd.conf(5) and you can match with
"route <label>" in pf.conf where you would normally use an address or
prefix.
Another possibility would be if these subnets could be fed by BGP
instead of OSPF. You can use any of the usual match rules (so criteria
can include things like community, peer, nexthop, prefixes within a
certain range, etc) to match incoming updates, and feed them straight
into a PF table.
Obviously it's not as simple as being able to do something like
"pass received-on vlan123 sent-on vlan456" (if there was code to support
such a thing) though..
