pfSense 25.11RC does not like IPv6 turned off?
-
@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.
-
@luckman212 Does it throw the same error against that file if you try to load it at the CLI?
pfctl -f /tmp/rulesdebug -
@stephenw10 Yes, it does.
Interestingly, when run with the dry-run (
-n) flag, it does not error at all. -
@stephenw10 I can't figure this one out. Any advice?
I posted the
rules.debugfrom this unit (which is running 25.07.1) to a gistAgain, it's odd that dry run reports no issues but trying to actuate the rules results in the
DIOCADDRULEerror 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) -
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 runpfctl -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.
-
@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) -
@luckman212 And that's on 25.11, right?
-
@kprovost No, this affected unit is still on 25.07.1. Do you want me to update to 25.11 and re-test?
-
@luckman212 Run
uname -aon 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. -
@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 armNow I've definitely got some questions for the admin who asked me for help on this one! sheesh...
