pfSense 25.11RC does not like IPv6 turned off?

gniting

Upgraded to 25.11RC and post install reboot, no connectivity for lan devices. The pfSense box itself (a vm on proxmox) was able to talk to the Internet properly, but no luck for devices on the LAN. They could ping each other, but no traffic was coming or going to the Internet.

Error msg that I got was:
There were error(s) loading the rules: pfctl: DIOCADDRULE: Protocol family not supported - The line in question reads [0]: @ 2025-11-21 08:59:10

Digging around I found out that this is cause I had "Allow IPv6" turned off under Settings → Advance → Networking. I don't use/need IPv6 on my LAN. Everything was running peachy prior to the update.

Apparently, in newer versions of FreeBSD, the pf module becomes very strict. If the configuration generates a single line of logic referencing inet6 (IPv6), but the kernel has been told "IPv6 is disabled," the generic pfctl loader crashes with DIOCADDRULE: Protocol family not supported. This crash then causes the entire ruleset to fail, defaulting the firewall to a "Block All" state for safety.

Ouch.

So now it looks like I need to leave IPv6 on?

Bob.Dig

@gniting No problem here, I just tested this.

kprovost

@gniting Do you by any chance have nat64 rules?

gniting

@kprovost said in pfSense 25.11RC does not like IPv6 turned off?:

@gniting Do you by any chance have nat64 rules?

Nope, I do not.

gniting

@Bob.Dig said in pfSense 25.11RC does not like IPv6 turned off?:

@gniting No problem here, I just tested this.

So you were able to upgrade to 25.11RC while having "allow IPv6" off?

stephenw10

Hmm, can't replicate that so far.

Unsetting that doesn't disable IPv6 in the kernel. It just removes the default IPv6 rules that pass traffic.

Can you see exactly what rule is generating that?

gniting

@stephenw10 said in pfSense 25.11RC does not like IPv6 turned off?:

Hmm, can't replicate that so far.

Unsetting that doesn't disable IPv6 in the kernel. It just removes the default IPv6 rules that pass traffic.

Can you see exactly what rule is generating that?

How do I go about that? Also, I am assuming you are recommending I turn off "Allow IPv6" and then try to hunt down the rule?

stephenw10

Yes, if you can replicate it in 25.11RC by simply disabling allow IPv6. Look at the system logs for errors. Try running Status > Filter Reload and see where it errors.

I still can't generate that error here even on systems with NAT64. So it seems likely you have some other unusual rule.

Are you able to upload your ruleset to us for testing? If so please upload the /tmp/rules.debug file here: https://nc.netgate.com/nextcloud/s/cFFWNHnLdm3rXtQ

luckman212

@stephenw10 I'm getting this too on a 3100 running 25.07.1

I've skimmed over the rules.debug but don't see anything that jumps out. Also tried disabling Allow IPv6 on Advanced settings but it had no effect, the error still presented.

My settings...

I uploaded the rules.debug to the same drop:

(Happy Thanksgiving)

gniting

@stephenw10 said in pfSense 25.11RC does not like IPv6 turned off?:

Yes, if you can replicate it in 25.11RC by simply disabling allow IPv6. Look at the system logs for errors. Try running Status > Filter Reload and see where it errors.

I still can't generate that error here even on systems with NAT64. So it seems likely you have some other unusual rule.

Are you able to upload your ruleset to us for testing? If so please upload the /tmp/rules.debug file here: https://nc.netgate.com/nextcloud/s/cFFWNHnLdm3rXtQ

Disabled "Allow IPv6" and rebooted.

All is well! I am stumped now.

stephenw10

@luckman212 Does it throw the same error against that file if you try to load it at the CLI?
pfctl -f /tmp/rulesdebug

luckman212

@stephenw10 Yes, it does.

Interestingly, when run with the dry-run (-n) flag, it does not error at all.

luckman212

@stephenw10 I can't figure this one out. Any advice?

I posted the rules.debug from this unit (which is running 25.07.1) to a gist

Again, it's odd that dry run reports no issues but trying to actuate the rules results in the DIOCADDRULE error and an empty resultant ruleset.

[25.07.1-RELEASE][root@r1.lan]/root: pfctl -n -f /tmp/rules.debug
(no error)

[25.07.1-RELEASE][root@r1.lan]/root: pfctl -f /tmp/rules.debug
pfctl: DIOCADDRULE: Protocol family not supported

[25.07.1-RELEASE][root@r1.lan]/root: pfctl -vvsr
(empty)

kprovost

No luck reproducing that here, and to make it even more fun this error (EPFNOSUPPORT) is an error code pf simply doesn't use in 25.07.01 (and in later versions only if something is wrong with a nat64 rule).

Run this dtrace command while you're trying to set the failing ruleset:
dtrace -n 'fbt::pf_ioctl_addrule:return { printf("=> %d (@%#x)", arg1, arg0); }' -n 'pf:ioctl:function:error { printf("function %s Line %d error %d", stringof(arg0), arg2, arg1); }'
(Terminate with Ctrl+C after you've run pfctl -f /tmp/rules.debug)

That'll at least let us confirm that we really are getting that error from the kernel, and might give us a hint about where it's coming from.

luckman212

@kprovost Interesting. Ok, here it is

# dtrace -n 'fbt::pf_ioctl_addrule:return { printf("=> %d (@%#x)", arg1, arg0); }' -n 'pf:ioctl:function:error { printf("function %s Line %d error %d", stringof(arg0), arg2, arg1); }'
dtrace: description 'fbt::pf_ioctl_addrule:return ' matched 1 probe
dtrace: description 'pf:ioctl:function:error ' matched 1 probe
CPU     ID                    FUNCTION:NAME
  1  28362          pf_ioctl_addrule:return => 3241561984 (@0xf84)
  1  28362          pf_ioctl_addrule:return => 0 (@0x164)
  1  28362          pf_ioctl_addrule:return => 3241561984 (@0xf84)
  1  28362          pf_ioctl_addrule:return => 0 (@0x164)
  0  31078                   function:error function pf_ioctl_addrule Line 2177 error 46
  0  28362          pf_ioctl_addrule:return => 0 (@0x106c)
  0  28362          pf_ioctl_addrule:return => 46 (@0x164)

kprovost

@luckman212 And that's on 25.11, right?

luckman212

@kprovost No, this affected unit is still on 25.07.1. Do you want me to update to 25.11 and re-test?

kprovost

@luckman212 Run uname -a on that machine for me.

That error line matches perfectly on 25.11, and doesn't make any sense at all on 25.07.
I suspect you've wound up with a 25.11 kernel and a 25.07 user land. Which might also explain your actual problem. The kernel is supposed to be backwards compatible with userspace, but clearly not perfectly so.

luckman212

@kprovost Well I'll be damned. You're right! (disclaimer: this is a system I don't manage myself. So I didn't even think to check this) But, alas...

# freebsd-version -ku
16.0-CURRENT
15.0-CURRENT

# uname -K
1600001
# uname -U
1500029

# uname -a
FreeBSD r1.lan 16.0-CURRENT FreeBSD 16.0-CURRENT #34 plus-RELENG_25_11-n256497-084b5f7b7bcd: Tue Nov 18 17:24:40 UTC 2025     root@pfsense-build-release-aarch64-1.eng.atx.netgate.com:/var/jenkins/workspace/pfSense-Plus-snapshots-25_11-main/obj/armv7/JG6bvqZ0/var/jenkins/workspace/pfSense-Plus-snapshots-25_11-main/sources/FreeBSD-src-plus-RELENG_25_11/arm.armv7/sys/pfSense-3100 arm

Now I've definitely got some questions for the admin who asked me for help on this one! sheesh...

luckman212

@kprovost just circling back to thank you for the help. Updated the unit to 25.11RC and all is well again. The dtrace wizardry you used to debug this is quite impressive!