pfSense Crash "Fatal trap 12: page fault while in kernel mode"
-
You're not using IPv6 inside the tailnet though? Or explicitly as a tunnel endpoint?
-
@stephenw10 No, but it assigns IPv6 to a client by default and I'm not really sure you can disable that in tailscale.
-
You should be able to disable that in tailscale but it shouldn't make any difference since it's tailscale itself that's binding to it.
-
@stephenw10 Yeah, I don't believe that is possible for the Tailscale network. Is this an issue with pfSense or with the Tailscale package?
-
It appears to be a bug in FreeBSD/pfSense. It's just that the tailsale daemon hits it more often than anything else because it always binds to every IP address.
Just to confirm you saw this randomly in runtime? Not during boot?
-
@stephenw10 Yes, this was during runtime.
Also, I'm not sure if that could be connected, but quite a lot of users joined the Tailscale network that day when the crash happened. We also advertise several routes from the pfsense in the Tailscale package to allow some users access to internal services but there is nothing else really special in the configuration.
-
I don't think new users should trigger this since the daemon doesn't bind to it's own internal addresses. More likely this was some address change on another interface locally.
The only other thing we have seen recently was ntpd not starting due to an IPv6 local address being ,marked as duplicate. But as far as I know that can only happen at boot.
-
Would there be anything I can provide to help you find the bug that causes these crashes? Or are there some fixes already being implemented that should mitigate this issue? I'm just trying to find out what my options are right now.
-
Are you able to trigger this reliably at all?
The biggest issue we have fixing it is that we haven't been able to replicate it locally and users who are seeing it do so only sporadically. So getting data is difficult.
-
@stephenw10 It seems I can't replicate it on demand; it has to be something very specific happening since I have only seen it crash like this once more since I reported it originally.
-
One thing we can try here is to enable a full core dump in the event of a panic. In this particular case it may or may not help but there's a chance it would provide all the answers.
Are you able to set that up on the firewall hitting this? If so do you have a SWAP partition configured and how large is it compared to the RAM?
