pfSense Kernel panic even on new hardware
-
Seems like AES.
AES_CBC (256)
HMAC_SHA2_256_128
PRF_HMAC_SHA2_256
MODP_2048On the status-page under SAD, I found these 4 variants active:
aes-cbc (enc algo)
And these auth algos:
hmac-sha1
hmac-sha2-512
hmac-sha2-256Is it some of these I should standarize on, just to be sure?
-
Well I would avoid SHA1 if you can but all that should work fine. Nothing there is particularly obscure.
AES-GCM will be significantly faster at P2 if you can use it.Steve
-
@stephenw10 Instead of just dumping full backup and restore on new hardware like I have done before, I have now prepared like this:
Configured pfSense from scratch (basically only set up WAN and LAG-interface consisting of LAN1/LAN2) on different machine
Import NAT, Firewall Rules, Alias and IPSec (and only those 4 sections, not a single more)These are the only packages/things I need/use today. I also have pfBlocker package, but can do without.
Can there really be some mistakes (by me) based on only those four configs that could crash pfSense/BSD?
At least this would rule out any advanced settings done in the past outside the config-files exported/imported, but of course if it is a mistake in a NAT fw rule, alias or IPSec somehow it wouldn't help.
Anything else I can do to track down this?
PS: This forum is so annoying. I had to switch IP in order to post. It gave just "Error" when tried to post the content above. No reason, nothing..
-
@fireix said in pfSense Kernel panic even on new hardware:
PS: This forum is so annoying. I had to switch IP in order to post. It gave just "Error" when tried to post the content above. No reason,
Happens frequently for me. The solution I use is:
-
Click on the web browser refresh button. (Doing so retains the post I'm creating in my experience but I sometimes copy it first just in case).
-
Click on the forum post "Submit" button (again)
-
The post is accepted without error
-
-
That will be a good test.
It's either something in the config triggering some unusual code path or something in the hardware. The hardware seems very unlikely since that's basically the same device we shipped for years without issue.
Steve
-
@stephenw10 Yeah, I have basically used this server since 2017 and the new of same model in 2018 (just for spare), so I have actually had it trouble free for 4 years before this started happening. What I did a year before this started was to convert it from transparent-mode to a more normal setup (different network on WAN/LAN) with 1-1 NAT. Didn't notice any issues for months. And adding 2 IPSec tunnels, instead of using OpenVPN. That is the only change in 5 years, it has been pretty stable. So very weird this should start now. I have also deactivated one IpSec tunnel I'm no longer using, so until I can shedule a downtime to switch over to the one I have prepared now, that can be a test also.
-
@stephenw10 After I removed the LACP-lag I have had for ages (two ports in LACP against two stacked switches, configured for LACP on both sides, with good status), the problem stopped. No more kernel panics or issues since.
-
Ah, well that's a good catch! Hmm, interesting. Nothing there really indicates lagg or lacp directly so I guess enabling that is somehow touching some other code...
