# rcorder /etc/rc.d/* /etc/rc.d/natd /etc/rc.d/sysctl /etc/rc.d/dumpon /etc/rc.d/dnctl /etc/rc.d/dhclient /etc/rc.d/ddb /etc/rc.d/hostid /etc/rc.d/ipfw /etc/rc.d/geli ... Starting ipfw before we even have filesysems does not seem useful for more distinguished usecases. The problem comes from setting WITHOUT_PPP. In Rel.14 the rc.d/ppp was installed nevertheless, but this seems not the case anymore. And rc.d/ppp is the only thing that makes ipfw start later. I think we should add a require FILESYSTEMS to the rc.d/ipfw. Also, in rc.d/ipfw is this line triggering a warning for failed configuration elif [ "`ipfw list 65535`" = "65535 deny ip from any to any" ]; then but it seems this doesn't work anymore: # ipfw list 65535 65535 count ip from any to any not // orphaned dynamic states counter 65535 deny ip from any to any
Why should ipfw require FILESYSTEMS? All it needs to run is /sbin/ipfw and the scripts and rulesets, which are in /etc.
(In reply to Dag-Erling Smørgrav from comment #2) Well, in my case the configuration comes from a database, and it can dynamically change, so it needs some locking, and it just complained that it can not even write the lock.
Contemplating along, I just found another thing on an other machine: there I have suricata looped into specific link-relations via divert, and then it needs to be started like so: firewall_coscripts="/ext/etc/rc.d/suricata_starter" Ipfw can do so much more than just load a few rules from /etc. I am utilizing ng_ipfw, I use NPTv6, have ipfw integrated with dhcpcd, use traffic-shaping, and probably a bunch more I have forgotten about because it just works and there is a web interface to change things. Also, some of these are delicate things and should live in the encrypted filespace (the base OS is not encrypted here, for maintainability and as it is not a secret).