On Wed, Dec 02, 2015 at 01:37:52PM -0200, Giancarlo Razzolini wrote:
> Macros need to be present in each anchor file. Tables don't need to. I
> have a little script that copies all my macros after I edit /etc/pf.conf
> to the anchors. I use commented marks on /etc/pf.con to know where to
> begin copying and where to end. But you get the point.
> 

I think it's always been this way. This may have changed but if you
specify filter conditions in your anchor definition the screening you
get is combination of the screen on the anchor from the base pf.conf
file and the filters specified in the anchor file itself. I use
anchors on FreeBSD which is using an older version of pf but I got
around the issue this way:

--- /etc/pf.conf -------------------------------------------------------
...
anchor imapd in on $ext_if from any to ($ext_if)
load anchor imapd from "/etc/pf-anchor-home/imapd.conf"
...

--- /etc/pf-anchor-home/imapd.conf -------------------------------------

imapd_ports="{ 143, 993 }"

pass in proto tcp to any port $imapd_ports keep state

------------------------------------------------------------------------

That's a simple example. It would honestly be better without the
anchor since using the anchor divides the rule up into two places. I
do it that way because I can easily split firewalling up across two
puppet rules. As Giancarlo wrote, the anchor can use your tables. He
didn't mention that the anchor can define it's own macros. The net
result of this is:

     pass in on $ext_if \
         from any \
         to ($ext_if) port { 143, 993 } \
         keep state

-- 
Chris

      __o          "All I was trying to do was get home from work."
    _`\<,_           -Rosa Parks
___(*)/_(*)____.___o____..___..o...________ooO..._____________________
Christopher Sean Hilton                    [chris/at/vindaloo/dot/com]

Reply via email to