2009/3/8 Jason Dixon <ja...@dixongroup.net>: > On Sun, Mar 08, 2009 at 04:01:57PM -0700, Hilco Wijbenga wrote: >> Hi all, >> >> I have pf running on my firewall box and I'm experiencing some strange >> behaviour. After several hours (this may even be 24 hours) of >> functioning normally, pf seems to reload its default rules which means >> that from that point on all traffic is blocked. A simple "pfctl -f >> /etc/pf.conf" fixes the problem but it is very annoying. > > There's nothing in OpenBSD or pf that reloads any configurations > "automagically".
:-) Yeah, I didn't think there would be. >> I don't see anything relevant in /var/log/pflog or /var/log/messages >> but I'm not sure what I am looking for so I may have missed something. >> >> Do you have any idea why this is happening? Do you have any tips for >> debugging this? I'm running a stock OpenBSD 4.4. > > You could start by showing us "pfctl -sr" before and after this supposedly > takes place. B And "uptime" to prove it hasn't been rebooted. B And "grep > pf /etc/rc.conf.local" so we can see how you're starting it. > > In other words, *useful information*. I'll get the "pfctl -sr" when it happens again. In the meantime, I'd like to point out that rebooting loads the rules correctly. So both pfctl -f /etc/pf.conf and reboot "solve" the problem. # grep pf /etc/rc.conf.local pf=YES # Packet filter / NAT # uptime 5:39PM up 9 days, 19:44, 1 user, load averages: 0.10, 0.09, 0.08 # pfctl -sr scrub in all fragment reassemble block return log all pass out quick inet from 192.168.151.1 to 192.168.151.0/24 flags S/SA keep state pass out quick inet from 192.168.1.64 to any flags S/SA keep state pass out quick on sk0 inet6 from fe80::21c:f0ff:fe9f:e13 to any flags S/SA keep state pass in quick on sk1 inet from 192.168.151.0/24 to any flags S/SA keep state As you can see I haven't rebooted this box for 9 days. I think I've reloaded pf.conf 4 or 5 times. I'm quite curious what pfctl -sr says the next time it happens. There is one other strange thing that's being logged every now and then: acpitz0: THRM: failed to read _TMP acpitz0: THRM: failed to read temp (See my other email specifically about this.) It doesn't seem related but who knows so I thought I'd mention it. Cheers, Hilco
