[Trac-bugs] [PC-BSD Trac] #334: Startup: Error parsing /etc/pf.conf

PC-BSD trac at pcbsd.org
Sat Jul 24 20:13:26 PDT 2010


#334: Startup: Error parsing /etc/pf.conf
----------------------------------+-----------------------------------------
 Reporter:  bitraptor             |       Owner:         
     Type:  System Defect         |      Status:  new    
 Priority:  minor                 |   Milestone:         
Component:  System Configuration  |     Version:  8.1-RC1
 Keywords:                        |  
----------------------------------+-----------------------------------------

Comment(by MSK61):

 I've almost run into the same problem. For me, it was due to a line I
 added to /etc/pf.conf to define a table containing addresses referenced by
 interface names. The table definition looked something like this:
 table <acceptAddr> const { em0, em0:broadcast }

 During boot, I saw that same error message complaining this time of
 em0:broadcast. The problem here is that pf is started before the DHCP,
 hence the interfaces don't have associated network addresses when pf is
 started.

 However after boot, when I check pf, I found it already started(although
 the error message showed that it wasn't started due to the errors parsing
 /etc/pf.conf). I dug after the problem for a while and found out that pf
 is actually started twice, once at the very beginning with network
 initialization and some time later during the startup procedure(can't tell
 where exactly). It's that second time when pf is successfully started(as
 the network interfaces have acquired addresses by that time).

 The problem now is that both times of starting pf is really controlled by
 the pf_enable variable in /etc/rc.conf(or /etc/rc.conf.local if it's
 defined there). So setting this variable to "NO" will disable starting pf
 completely in both times, while setting it to "YES"(as it's by default)
 will start pf twice, with the first time showing the error messages.

 I even tried removing my table definition from /etc/pf.conf and injecting
 them dynamically later in /etc/rc.local, but I found that /etc/rc.local is
 executed AFTER the first time and BEFORE the second time, so any dynamic
 table injections in /etc/rc.local will be overridden when pf is started
 for the second time.

 The final workaround I concluded was to add/edit a line in
 /etc/rc.conf.local to be
 {{{
 pf_enable="NO"
 }}}
 and then start pf manually in /etc/rc.local(creating the file if it
 doesn't already exist)
 {{{
 /etc/rc.d/pf onestart
 }}}
 Add a corresponding stop command in /etc/rc.shutdown.local(again creating
 this file it doesn't already exist)
 {{{
 /etc/rc.d/pf onestop
 }}}
 Note the use of onestart/onestop instead of simply start/stop as issuing
 the latter pair won't work after we've set pf_enable to "NO".

 I found the following links useful in reaching this conclusion:

 * http://erwan.lemonnier.se/docs/openbsdwireless/openbsd3.0-firewall-pf-
 nat-dhcp.html pertaining to openBSD but applies pretty clearly to freeBSD
 and PCBSD.

 * http://lists.freebsd.org/pipermail/freebsd-pf/2009-September/005329.html
 a post on freeBSD mailing list addressing a similar problem, with the same
 root cause

-- 
Ticket URL: <http://trac.pcbsd.org/ticket/334#comment:1>
PC-BSD <http://trac.pcbsd.org>
PC-BSD Project Management


More information about the Trac-bugs mailing list