@gertjan Partial reset : LAN : [image: 1678780919365-418dd979-67f2-4ce9-ad40-db4105d7312a-image.png] edit : or a total reset of all counters, and IPv6 is 75 % of all outbound traffic

@steveits Thank you, Steve. I appreciate it. It's very encouraging.

@steveits Thank you. I'll take a look at that.

Got it figured out. Under Firewall/Virtual IPs/ I had created a virtual ip to my offsite pbx server set to wan. I had followed instructions somewhere that said to do that. Once I turned that off the phone lit green and works! I was able to remove ALL nat port fwd's, 1:1. I kept the "Outbound" as "Hybrid", Firewall optimization set to conservative. Thanks @stephenw10

@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.