"Operation not permitted" on 9.0-BETA1 firewall (PF) about 1 hou
I recently upgraded a firewall from a March-ish 9-CURRENT to 9.0-BETA1 (csu=
p run August 21 around 12:00 AM EDT). Since then, after approximately an h=
our after it boots, the firewall stops passing any traffic (IPv4 and IPv6).=
OpenVPN, for example, logs the following errors:
write UDPv4: Operation not permitted (code=3D1)
Quagga, for another example, logs something similar:
ripd[1696]: can't send packet : Operation not permitted0
ospfd[1702]: *** sendmsg in ospf_write failed to 172.30.0.3, id 0, off 0,=
len 76, interface tap0 mtu 1500: Operation not permitted
If I try to ping something from the console, I get the same error message:
# ping 4.2.2.2
ping: sendto: Operation not permitted
I've tried both my current (unmodified and working prior to the upgrade) an=
d experimental PF configurations, neither of which have any effect on the p=
roblem. Reloading the PF configuration (/etc/rc.d/pf reload) or restarting=
PF altogether (/etc/rc.d/pf restart) also have no effect. Only if I shut =
down PF completely (/etc/rc.d/pf stop) do I regain network connectivity - I=
can do things like ping hosts (IPv4 and IPv6), browse the web, and pass tr=
affic that's just routed through the firewall (i.e., not requiring NAT). A=
s a workaround, I'm rebooting the firewall automatically every hour.
The kernel I'm currently running has debugging disabled for performance tes=
ting purposes, so I am building a proper debug kernel now. In the meantime=
, has anyone encountered similar problems with PF? What additional trouble=
shooting can I try? I looked through the various information available in =
pfctl, but to be perfectly honest, I don't know what I'm looking for. I di=
dn't think to check overall memory utilization, like what netstat -m would =
show you, so the next time this happens I'll try to collect that data.
Best wishes,
Matthew