pfSense 25.11RC does not like IPv6 turned off?

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!

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.