@steveits good call! I just restarted php-fpm via putty and that fixed things. I'll keep that in mind in the future. Mar 13 14:28:00 sshguard 14600 Now monitoring attacks. Mar 13 14:52:00 sshguard 14600 Exiting on signal. Mar 13 14:52:00 sshguard 64545 Now monitoring attacks. Mar 13 14:55:02 sshd 6145 Accepted keyboard-interactive/pam for redacted from redacted port 62482 ssh2 Mar 13 15:09:13 rc.php-fpm_restart 2292 >>> Restarting php-fpm Mar 13 15:09:13 check_reload_status 3473 check_reload_status is starting. Mar 13 15:09:36 php-fpm 3013 /index.php: User logged out for user 'redacted' from: redacted (Local Database) Mar 13 15:09:50 php-fpm 2514 /index.php: Successful login for user 'redacted' from: redacted (Local Database)

@steveits said in Upgrade to 23.01 3x memory usage: @scottlindner said in Upgrade to 23.01 3x memory usage: It is happening due to some default OS Cron jobs starting things pfEense doesn't need. The cron jobs did get enabled again, however, that's just a trigger. It's my understanding any disk activity will grow the ZFS ARC cache as noted ("1/2 RAM or the total RAM minus 1GB, whichever is greater"). Whether that actually causes a problem or is just cosmetic is situation dependent. "ZFS will yield this RAM if other processes require more memory, but it may not give up memory fast enough for every use case." For sure. I think it's more, "Something changed, is it bad?"

Following the logs is as good as you'll get over SSH. Kernel message output can only go to a console, and SSH terminals are not eligible to be considered consoles in FreeBSD. Any tricks you could normally play with consoles with things like stty, conscontrol, or redirecting things in syslog won't work against SSH terminals.

@octopuss if your having issues with your ISP dns, try one of the major player quad9, google, cloudflare.. Or just try resolving vs forwarding. 1.7 seconds to look up something from your ISP is a bit long..

@mappe that would be a good test to validate your setting of the IP to static, answers when asked about that IP. you could send the sniff to your ISP, and say look here - it answers a arp probe for the IP you gave me.

I'm going with hardware, we have an identical box in HA with this one as the failover and it hasn't had any issues. Replacements are on the way. Thanks for the help.

@ajaxous said in 23.01 upgraded from 22.05 appears to be causing cable modem on WAN port to lock up: Arris TM3402A https://approvedmodemlist.com/intel-puma-6-modem-list-chipset-defects/ Try changing your WAN mac address to get a different IP to rule out someone sending the packets that can trigger this particular chipset to lockup.

@rcoleman-netgate Hi Ryan, thank for the reply. i did end up fixing it, by mirroring repo files and cert files from my working node. im back up and running now! but good to know that there is a way to clear the cert and start over, ill keep that in mind if i ever get stuck and just cant get going. thanks!

@daduls I rarely leave feedback and it just leads to bad feedback from the seller. No point.

@paulk201270 said in 23.01 crashing frequently. IPSEC connections constantly dropping and respawning. Unable to access http over VPN, address constantly times out.: @jimp Many thanks. Looks like that is the root cause. Have set the tuneable and have not seen a subsequent reboot. Could this also be a cause of the listed error on the 6100 in the Bug database?? No, that's a completely different crash/backtrace.

@bfu Hello, I am having the same issue. Were you ever able to find a solution?

@johnpoz Thanks. I wasn't fully aware of the usefulness of alias before. Indeed, blocking RFC1918 is a more convenient way. I've reconfigured my firewall and it's running well. Also thanks to @SteveITS

@lnguyen @stephenw10 that did the trick, thanks much for helping me out, it was GE25 on which pfsense upstream cable was in.

[Solution] There were some outgoing port rules in the VMWare Esxi firewall (outgoing ports) that prevented traffic on ports 80 and 443. I disabled these rules and updating Windows and Linux worked, as well as accessing the http sites. Thanks.

@defunct78 Adding more details to my post. tcpdump on the inside shows the ServFail as stated. Enabling TLS causes these errors. Again, DNSSEC has always been disabled. 13:48:47.739211 IP (tos 0x0, ttl 64, id 57751, offset 0, flags [none], proto UDP (17), length 59, bad cksum 0 (->dab3)!) 192.168.X.254.53 > 192.168.X.24.63104: [bad udp cksum 0xbe9f -> 0xb98a!] 11684 ServFail q: AAAA? i.ebayimg.com. 0/0/0 (31) and IPv6 13:32:22.688367 IP6 (hlim 64, next-header UDP (17) payload length: 41) XXX:XXX:XXX:30::1.53 > XXX:XXX:XXX:30:f470:14f5:f634:1308.55800: [udp sum ok] 5238 ServFail q: AAAA? ssl.gstatic.com. 0/0/0 (33) I am not seeing errors on the WAN side, though that data is encrypted so it is a bit harder to see the content. I have tried Quad9 and Cloudflare both. Also disabled IPv6 on the client side just to isolate the issue, none of these seemed to have changed the behavior.

@mrewers I had a similar problem with one of mine. Put in a ticket; tech support had me send it in. They pulled it apart and verified everything, reinstalled the software and I'm not sure what else and returned it. Zero problems after that. I suggest you contact them.