Startup: Error parsing /etc/pf.conf

[bitraptor]

Version 8.1
On startup following errors appear on the console:
/etc/pf.conf:4: could not parse host specification
/etc/pf.conf:5: could not parse host specification
no IP address found for lo1.network
DHCP active, network access functioning normally

[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

[dlavigne]

This has been fixed in 9.0.