What does the backtrace in the crash report show?

@dennypage said in NTP exposed to WAN by default: specifying the listen by interface usually isn't necessary. While I do agree here, I also think the ability to limit (when possible by the application/service) is a worth while security option to have. Should it be the number one priority - no prob not. And since pfsense is a firewall, you do have complete control of who can talk to what service that might be running no matter what the service does for binding to IPs the device might have. I mean quite often many services would be on device with only 1 interface anyway ;) So the ability to call out what specific interface/ip a service is bound to really becomes moot. And it just makes it easier to setup to know that hey that service will listen to whatever IP the device has. Back to the topic at hand, while ntp does out of the box listen on all IPs. Out of the box this would not be available via the wan no matter what IPs the service is actually listening on. Seems the OP clearly was not using valid testing methods (nmap to a udp port) - where nmap in layman terms reports I can't tell there was no answer. What I don't get is how you could interpret (not open|filtered) To you got a ntp response. Or any response at all. Nor did they follow up with validation of what they thought they were seeing before jumping to the conclusion that somehow pfsense left this service open to the wan even with default deny on all interfaces out of the box.. The only sort of exception to this is while the lan also has default deny, out of the box a any any rule is created to ease setup.

@stephenw10 I will not be able to get pcap as this is something that happened last week. It occurred over a period of a few days, and our logging server locked-out the pfSense for exceeding the storage quota. I will try to find what piece of office equipment was causing this. I know very little about IPv6, but will enlist chatgpt to help me.

FYI: Upgrading the pfSense to v26.03 fixed the issue, I was able to renew the certificate. I think one of the core files (specifically services.inc) was corrupted. This issue has been resolved. Thank you all.

@inferno480 said in Unable to automatically start PIMD: guess what, it's still broke in 26.03 final release. It's broken in upstream FreeBSD, and the FreeBSD maintainer appears to have gone awol. If you are only using pimd to bridge multicast between local interfaces (not actually using the PIM protocol), I would suggest using the mcast-bridge package as an alternative.

@GerrieJ said in pfSense keeps crashing: pfSense 2.5+ requires UEFI; legacy-only mode causes unpredictable freezes on FreeBSD. Not sure where Claude imagined this from but it's not true. I have numerous devices running legacy boot without issue. Including our own hardware. @GerrieJ said in pfSense keeps crashing: Dynamic frequency scaling causes scheduling instability on FreeBSD/pfSense. Run at a fixed clock. Also not true in general. I've never seen an issue enabling EIST here. Some devices may not support it correctly of course. I don't have any Gemini Lake hardware so..... @GerrieJ said in pfSense keeps crashing: pfSense 2.5+ dropped full legacy BIOS support Yeah no clue where it pulled that from but it's flat out wrong. AI at your own risk I guess. Anyway glad you found some settings that work with that device.

@stephenw10 if so then means the they are available via public - so what is the point of the vpn? Just not understanding they are wanting to actually accomplish other than complexity. If I want to resolve stuff on the other end of a vpn, I put in a domain override to go ask the the ns there for the domain at that site, done.. I am not understanding what exactly they are trying to accomplish here.. The use case makes no sense to me.

I've just taken delivery of a Sophos XG 330 Rev2 with an i5-6500, so back looking at this. Picked up the XG unit mainly for 10Gb connection options.

@stephenw10 Absolutely that was the first thing I did and I'm very glad I did to that or I would be in a right mess.

@stephenw10 Glad to know this should be resolved shortly, also facing the same concern here had to downgrade back to 25.11.1 for now from 26.03

@stephenw10 thank you, will test, currently running 26.03

Hmm, if you have aliases generated by pfBlocker that are not populated yet it can cause issues loading the ruleset. Though it should just ignore any rules using those aliases and load everything else. If the rules are actually invalid it may prevent the ruleset loading at all which would make any new rules appear to be failing. You see alerts for that though. Darkstat doesn't have anything to do with rules so it's hard to see how that could be tied in.

Hmm, that's also slightly different. Backtrace: db:1:pfs> bt Tracing pid 2 tid 100084 td 0xfffff800028b8000 kdb_enter() at kdb_enter+0x33/frame 0xfffffe010699eb30 panic() at panic+0x43/frame 0xfffffe010699eb90 trap_fatal() at trap_fatal+0x40b/frame 0xfffffe010699ebf0 trap_pfault() at trap_pfault+0x46/frame 0xfffffe010699ec40 calltrap() at calltrap+0x8/frame 0xfffffe010699ec40 --- trap 0xc, rip = 0xffffffff80cefaa8, rsp = 0xfffffe010699ed18, rbp = 0xfffffe010699ed30 --- chgsbsize() at chgsbsize+0x28/frame 0xfffffe010699ed30 sorele_locked() at sorele_locked+0x8c/frame 0xfffffe010699ed50 tcp_close() at tcp_close+0x167/frame 0xfffffe010699ed90 tcp_timer_2msl() at tcp_timer_2msl+0xf6/frame 0xfffffe010699ede0 tcp_timer_enter() at tcp_timer_enter+0xf4/frame 0xfffffe010699ee10 softclock_call_cc() at softclock_call_cc+0x16d/frame 0xfffffe010699eec0 softclock_thread() at softclock_thread+0xe5/frame 0xfffffe010699eef0 fork_exit() at fork_exit+0x7b/frame 0xfffffe010699ef30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe010699ef30 --- trap 0x7f157f15, rip = 0x9fbe9fbe9fbe9fbe, rsp = 0xb0efb0efb0efb0ef, rbp = 0x8e1b8e1b8e1b8e1b - I would expect to see nearly identical backtraces if this were some software bug. Maybe some hardware offloading. In every case this looks to have happened after the openvpn client connection went down and came back up. How do you have that configured?

@stephenw10 said in pfSense LDAP Auth Source Shell Login Issue: Not as far as I know. Let me check with the devs. I don't have anything convenient with LDAP setup right now to test against myself. It might be better to open a bug report for this to track: https://redmine.pfsense.org/ https://redmine.pfsense.org/issues/16799

Mmm, I guess it could say 'unpopulated' or 'invalid' or similar since it's not a resolution issue here.

@dhpo5683 Ah, ok, lol. You could even use your own gmail mail here.

That does seem to be expected. It only lists assigned interfaces and localhost. enc0 is not an assignable interface.

Humblest appologies ... I have confused the release numbers between CE and plus and only just realised. I am in fact on plus (26.03), but for some reason thought that was a CE release number. Sorry to have led you on a wild good chase. Hopefully, someone else will benefit from my stupidity by reading this and going 'Oh Yeah'. I've learnt in my time working with some very smart people that everyone can do dumb things at times - just my turn now :-)

As @stephenw10 mentions not being able to do dns to anywhere from any client behind pfsense would not be an out of box sort of thing. So you are either blocking/redirecting it causing the problem, you are routing all traffic out a vpn that is messing with it. Or you have say pfblocker with some lists, and one of the lists is blocking 8.8.8.8 (it has been seen before) Can you even ping 8.8.8.8? Lets see your query, what sort of response do you get? timeout, nx, servfail?

@stephenw10 thank you, will do that!