@Gertjan Do you know what token I should use here ? https://github.com/pfsense/FreeBSD-ports/blob/487258ae7cbd1039621b5dc5ac625f23d5519f39/security/pfSense-pkg-acme/files/usr/local/pkg/acme/acme_command.sh#L96 Where I can find it?

If you run that script it enables that option, so you would see it checked after no matter what it was before. Look in the config history to see what changed in the configuration when you ran the script. Do a diff from the version before to that version and see what it altered.

https://redmine.pfsense.org/issues/13983

Somehow Virtual IP of WA2 was created. Just removed it and all back to normal Thanks!

almost 3 days of uptime, no page faults so far!

@steven81 said in pfsense, google wifi and port forwarding: current info is that the port forwarding is no longer needed. And what does that have to do with you sending traffic from can you see me and not getting it?? You either sent it to wrong IP, but they no what IP you are talking to the website for. So either vpn or proxy so they have wrong IP, or there is something blocking traffic to your IP upstream of pfsense.. Or you just not sniffing correctly? Either way I would figure it out - what about the next thing you need to setup a port forward for?

@tse-0 hmm.. no time right now to examine further but the code does seem to validate old IP vs new: if (!is_ipaddr($oldip) || ($curwanip != $oldip) || file_exists("{$g['tmp_path']}/{$interface}_upstart4") || (!is_ipaddrv4($config['interfaces'][$interface]['ipaddr']) && ($config['interfaces'][$interface]['ipaddr'] != 'dhcp'))) { .... <package restart here> ... Could be one of the other conditions here I guess... Might hack in some debug code for the log so I can see what's going on ...

Thank you! Your reminder that ESXI has command line capability enabled me to finally get to the pfsense console and restore a configuration. I had to shutdown the pfsense server Startup an old firewall that had a DHCP server This finally gave my computer the ability to get to the ESXI webpage. From here I could start pfsense and use the console. There are probably better ways to resolve this, but this is what I did and it is working. Thanks again!

I don't know what I did wrong previously, but I re-attempted it and managed to get it to work with the same thought processing in mind. I created a backend that will be my local web server: [image: C3hzf.png] My http/https offloader (front-end) defines a path rule and redirects to such backend if we have an ACME challenge: [image: HEQWW.png] [image: XpqGP.png] [image: ulstK.png] Maybe it was the ordering of the actions, maybe it was the naming. I was pretty confident that I tested my previous setup with 127.0.0.1 as well, but this seems to work and I don't know why it did not work previously. Now it was very easy to confirm the configuration is right when using postman. Say you have the domain example.org, you should do a GET request to two different URLs to validate their response: http://example.org/foobar: Should return a Location header with the https version of the URL, so confirming the offloader works http://example.org/.well-known/acme-challenge/foobar: Should timeout! It must not return an error immediately, or the configuration is wrong. If the configuration is right, it will try to talk to the standalone HTTP server that only runs during the ACME challenge, so it will timeout with 503 Service Unavailable after 60 seconds or so, which means it will succeed if the standalone HTTP server is running. With this setup the "Standalone HTTP server" method will work.

It depends on the device and the image. Some do have specific firmware (especially true with different types of ARM devices). That said, the 5100 and 4100 both use the same serial memstick installer so it should work on both.

@jimp Fair enough at least im not missing something simple then. As I said it was an easy fix just wasn't sure if I was making it harder for myself.

Hi, Still having this latency. Maybe it's normal ? In your pfsense, do you have the same problem ? Does the ping increase slightly after pfsense ? Thanx

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