pfSense 25.11RC does not like IPv6 turned off?

luckman212

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!

JonathanLee

IPv6 is far more widespread today than many people realize—often hiding in plain sight. For example, Apple devices use utun interfaces, which are IPv6-based containers that support features like Private Relay and iCloud. These services even run iMask DNS over DoH inside those tunnels. In short, IPv6 is much more prevalent in modern systems than most people think.