There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy

[stephenw10]

Same question as the OP here. Anything logged? Any 'exotic' rules? Anything else unusual?

[mangelot]

Same issue here, almost every day (some times twice a day)

06:30:00 PF was wedged/busy and has been reset.
06:30:00 There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]:

system general log
Aug 26 06:30:00 php-cgi 51879 rc.filter_configure_sync: New alert found: There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]:
Aug 26 06:30:00 php-cgi 51879 rc.filter_configure_sync: New alert found: PF was wedged/busy and has been reset.
Aug 26 06:28:00 sshguard 54936 Now monitoring attacks.
Aug 26 06:28:00 sshguard 55063 Exiting on signal.

[stephenw10]

Is there anything else logged? An alert shown in the system?

Can you replicate it by running Status > Filter Reload?

[mangelot]

Only the warning in GUI and by email (twice a day)

yesterday
16:15:00 PF was wedged/busy and has been reset.
16:15:00 There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]:
19:00:00 PF was wedged/busy and has been reset.
19:00:00 There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]:

monday:
06:30:00 PF was wedged/busy and has been reset.
06:30:00 There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]:
01:30:00 PF was wedged/busy and has been reset.
01:30:00 There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]:

Q: Can you replicate it by running Status > Filter Reload?
A: Cannot replicate the error, no issues when running filter reload, all rules are loaded normally

I can provide the status_output file from the GUI

[a.dresner]

Happened for me again 3x, on a different pfsense box..

pf_busy

PF was wedged/busy and has been reset. @ 2024-08-08 16:20:11
PF was wedged/busy and has been reset. @ 2024-08-13 06:44:50
PF was wedged/busy and has been reset. @ 2024-08-21 14:50:18
Filter Reload

There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-08-08 16:20:12
There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-08-13 06:44:51
There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-08-21 14:50:19

[stephenw10]

You can upload a status file here: https://nc.netgate.com/nextcloud/s/fLa8Rr8Km5Bq4rt

[mangelot]

@stephenw10 uploaded the status

[stephenw10]

Hmm, nothing obviously an issue there.

You have a lot of bad requests against the pfSense GUI from a single IP. If that's not a scan of some sort from an internal IP you should check that you don't have open ports to the WAN.

One in stance showed just after em2 disconnected. But only one.

It looks like you have lcdproc installed but misconfigured.

[mangelot]

@stephenw10

bad requests against the pfSense GUI from a single IP?
Can you tell me which IP? or which log file?

It looks like you have lcdproc installed but misconfigured.
I'm running lcdproc on a watchguard xtm550, the lcd is showing the correct info?

[stephenw10]

An XTM5 you mean? In that case lcdproc is probably just trying to start multiple times:

Aug 26 19:56:41 firewall-home LCDd[98016]: sock_send: socket write error
Aug 26 19:56:41 firewall-home LCDd[98016]: sock_send: socket write error
Aug 26 19:56:41 firewall-home LCDd[98016]: sock_send: socket write error
Aug 26 19:56:41 firewall-home LCDd[98016]: sock_send: socket write error
Aug 26 19:56:42 firewall-home LCDd[98016]: sdeclcd: cannot release IO-permission for 0x378!
Aug 26 19:56:43 firewall-home php[92308]: lcdproc: Start client procedure. Error counter: (0)

Some of those are expected for sdeclcd since it's hard coded for the parallel port at 0x378.

I see you upgraded the CPU.

You have a bunch of arp movement logs:

arp: 192.168.2.187 moved from 52:04:aa:49:5d:ce to da:53:be:3f:8b:a7 on em1
arp: 192.168.2.187 moved from da:53:be:3f:8b:a7 to 52:04:aa:49:5d:ce on em1
arp: 192.168.2.187 moved from 52:04:aa:49:5d:ce to da:53:be:3f:8b:a7 on em1
arp: 192.168.2.187 moved from da:53:be:3f:8b:a7 to 52:04:aa:49:5d:ce on em1

If that's something known to share a MACs (internal teamed NICs etc) consider suppressing that logging as it's hiding other stuff:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/logs-arp-moved.html

The logs showing the potential scan attempts are in the main system log like:

Aug 28 23:56:22 firewall-home nginx: 2024/08/28 23:56:22 [error] 67396#100121: *36847 open() "/usr/local/www/.env" failed (2: No such file or directory), client: 78.153.140.151, server: , request: "GET /.env HTTP/1.1", host: "81.x.x.55"
Aug 28 23:56:22 firewall-home nginx: 2024/08/28 23:56:22 [error] 67396#100121: *36849 open() "/usr/local/www/.config.yaml" failed (2: No such file or directory), client: 78.153.140.151, server: , request: "GET /.config.yaml HTTP/1.1", host: "81.x.x.55"
Aug 28 23:56:23 firewall-home nginx: 2024/08/28 23:56:23 [error] 67396#100121: *36851 open() "/usr/local/www/.env.bak" failed (2: No such file or directory), client: 78.153.140.151, server: , request: "GET /.env.bak HTTP/1.1", host: "81.x.x.55"
Aug 28 23:56:24 firewall-home nginx: 2024/08/28 23:56:24 [error] 67396#100121: *36854 open() "/usr/local/www/.env.example" failed (2: No such file or directory), client: 78.153.140.151, server: , request: "GET /.env.example HTTP/1.1", host: "81.x.x.55"

That is an external device at 78.153.140.151 sending requests that are hitting the pfSense webgui. It's looking for files that might be present in known vulnerabilities. They aren't on pfSense so it throws an error but that traffic should never be allowed to reach the webui.

It looks like you have some floating rules in place that pass all traffic that is not subsequently blocked but you don't have any block rules so everything is passed!

anchor "userrules/*"
pass inet from any to any ridentifier 1609758534 keep state label "USER_RULE" label "id:1609758534"
pass inet6 from any to any ridentifier 1609758534 keep state label "USER_RULE" label "id:1609758534"

You almost certainly don't want that! Disable or remove that rule.

None of that would cause that pfctl error though.

[coreybrett]

I was having the same issue with the "loading the rules: pfctl: DIOCADDRULENV" errors on my 5100. After I disabled one of my WAN interfaces, the errors stopped completely. (I was also having trouble with HAProxy, and that is fixed too) The WAN interface had a static IP and was connected to a Cradlepoint cellular modem.

[mangelot]

@stephenw10 thanks, I fixed the issues mentioned,
the issues with the Filter reload stille remains, cannot find out what it can be, manual filter reload doesn't give any errors.

There were error(s) loading the rules: pfctl: DIOCADDRULENV: Invalid argument - The line in question reads [0]: @ 2024-09-01 22:45:00
There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads [0]: @ 2024-09-03 03:45:01

[stephenw10]

Do those logs coincide with anything else?

In the logs they all seem to be on the 15min exact intervals so triggered by something periodic.

[mangelot]

@stephenw10

I've deleted OpenVPN client to server on pfsense and a VPN Interface assignment deleted,
So far no more errors with "PF was wedged/busy and has been reset." and "There were error(s) loading the rules: pfctl: DIOCADDRULENV: Device busy - The line in question reads "

[a.dresner]

@stephenw10 wondering if I can again upload a status up to you? I'm still experiencing some crashing. Thank you

[stephenw10]

Yup, the link should be valid again: https://nc.netgate.com/nextcloud/s/zQEwy6F9ADosFQm

Can you test a beta version?

[a.dresner]

@stephenw10 I would prefer not to test a beta... its a production environment.

[stephenw10]

There's nothing much shown in that status output you uploaded. Mostly because the system logs are completely spammed with:

Apr 13 15:42:11 bkk-fw upsmon[52386]: Poll UPS [apc] failed - Driver not connected
Apr 13 15:42:16 bkk-fw upsmon[52386]: Poll UPS [apc] failed - Driver not connected
Apr 13 15:42:21 bkk-fw upsmon[52386]: Poll UPS [apc] failed - Driver not connected

You should disable that if the UPS isn't actually attached.

You also have a number of arpmovment messages. If those are legitimate consider disabling logging those:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/logs-arp-moved.html