@SteveITS said in 2.8.0 fails to save SMTP Notification password: The test button text does say, "The last SAVED values will be used, not necessarily the values entered here." Ah, but that's not what actually happens. The just-entered new password IS used for the test, but then forgotten by the time you scroll down and "Save".

@stephenw10 Thanks. Just finished the reinstall and have Plus.

Ok, thanks for the suggestions. It's a Netgate 3100 and running in production. I will try to update this weekend. (The old firewall rules do appear to be in operation - whew!)

@stephenw10 My connection dropped tonight. ISP logged it as a "Planned PPP restart". I uploaded a log to the link here. Maybe it's helpful? It was only my CityFibre connection which did not reconnect. FTTC reconnected OK. Both use PPPoE and both are with A&A. Rebooting the appliance brought it back up.

Hmm, you should be able to check that. When you add a server there it should be added to /etc/resolv.conf. If it has a gateway set for it you should see a static route added for the server IP via that gateway in the routing table (Diag > Routes).

Yes both nodes would have to have the same WG config.

@ebcdic What software/hardware are you using to publish? If you haven't looked at WeeWX, you might give it a try as it would certainly address the issue. Just a thought.

@stephenw10 This was definitely not a button push on ours either. Both units are in locked cabinets in a colo. Any access to the facility is logged. @SteveITS As for it going to standby or hibernating, the person who went on site the LEDs were normal. Nothing indicating a state change or issue.

@sigulete You solved my problem, thank you !

@JonathanLee Would be nice if squid 7 came to pfsense, if squid is discontinued from pfsense then i guess a docker container running squid could be an option.

@jhg Read also Alternate Remote Backup Techniques.

@NetRunner8050 said in PHP Fatal error: Allowed memory size of 536870912 bytes exhausted: my reputation isn’t high enough yet Solved that.

@SteveITS Thanks, as I think you clarified a simple mistake I made. After you said "add/configure" the interfaces I realized I made a miscalculation of how simple it is to refresh these. The NAT/FW/DHCP tables only utilize WAN and LAN assignments and those assignments are programmed to the physical hardware. WAN currently being re0 would be igb0, LAN from re1 to igb1. So this would only take about 5 minutes. Silly of me. Thank you sir, the obvious eluded me.

OP, if you follow this you cannot go wrong, plain and simple: https://docs.netgate.com/pfsense/en/latest/recipes/virtualize-proxmox-ve.html

Mmm, that could be a gui bug only since the IPs are the same. Edit: Yup I see that here too. Digging...

Yup you would only see states while they're still active. So if you are not seeing attacks that often you'd have to get lucky to catch it. But you should see those by filtering for: 22 [image: 1753575304735-screenshot-from-2025-07-27-01-11-58.png] What rules do you have on the VPN interface(s)? It would be unusual to see connections being forwarded to you there though.

@Gertjan ok, thanks for the nudge, I've worked it out. I set the FritzBox to do the PPPoE and act as a router (not that I'm using the routing bit). I Fritzbox has a 192.167.178.x subnet. Give my pfSense a static IP address on that subnet. Make sure WAN interface allows "local" IP addresses. Set the "Exposed Host" setting on Fritzbox to forward all internet traffic to the pfSense box. With just the netgate doing evertyhing I was getting 560 down 900 up. With this config I'm getting 685 down, 850 up. Which feels better. Thanks for the help.

From the ntp doc: 8. Authentication Four commands require authentication to the server: config-from-file, config, ifstats, and reslist. An authkey file must be in place and a control key declared in ntp.conf for these commands to work. If you are running as root or otherwise have read access to the authkey and ntp.conf file, ntpq will mine the required credentials for you. Otherwise, you will be prompted to enter a key ID and password. Credentials once entered, are retained and used for the duration of your ntpq session.

Yes as long as it matches the traffic against a rule that's above the policy routing rule that will work.

@hansolo77 Checking what pfSense does every hours sharp - or some other regular moment, is a good start. But don't stop there ! Check also : all devices connected to your pfSense LANs ! as these can all do something at that very moment. ISP love to sell you numbers. Like 'a 1 Gbit/sec connection just for you'. If the country where you live has some enforced consumer rights movements, these ISPs add now at the bottom of the contract "... or whatever we have avaible for you". After all, ISP tend to hookup up entire roads, cities, etc to one main equipment with, guess what, a limited, up front determined throughput. For example : you all share the same 100 Gbits very expensive router/switch. If more then 100 clients are hookup up to this expense router, then ... you get it : what happens when every all these clients, all their devices, do 'something' at xx sharp ? So you have to check all of them (which you probably can't do) - or disconnect them all while you are testing. You can even go one level higher, and check all the POP of your ISP .... Inspecting the cron list is one thing. You still have to use the console or better, the SSH access, and use menu option 8, and type 'top'. Make sure the list is sorted at 'CPU usage'. Use also this command : ps aux and look for the process that mention minicron, these are also timed processes. On my pfSense : [25.07-RC][root@pfSense.bhf.tld]/root: ps aux | grep 'minicron' root 89370 0.0 0.1 13980 2484 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 240 /var/run/ping_hosts.pid /usr/local/bin/ping_hosts.sh root 89826 0.0 0.1 13980 2480 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 300 /var/run/ipsec_keepalive.pid /usr/local/bin/ipsec_keepalive.php root 90216 0.0 0.1 13980 2500 - I 18Jul25 0:00.17 minicron: helper /usr/local/bin/ipsec_keepalive.php (minicron) root 90313 0.0 0.1 13980 2476 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 3600 /var/run/expire_accounts.pid /usr/local/sbin/fcgicli -f /etc/rc.expireaccounts root 90699 0.0 0.1 13980 2500 - I 18Jul25 0:00.01 minicron: helper /usr/local/sbin/fcgicli -f /etc/rc.expireaccounts (minicron) root 90868 0.0 0.1 13980 2504 - I 18Jul25 0:00.20 minicron: helper /usr/local/bin/ping_hosts.sh (minicron) root 91166 0.0 0.1 13980 2480 - Is 18Jul25 0:00.00 /usr/local/bin/minicron 86400 /var/run/update_alias_url_data.pid /usr/local/sbin/fcgicli -f /etc/rc.update_alias_url_data root 91830 0.0 0.1 13980 2504 - I 18Jul25 0:00.00 minicron: helper /usr/local/sbin/fcgicli -f /etc/rc.update_alias_url_data (minicron) root 84792 0.0 0.1 14076 2688 0 S+ 08:49 0:00.00 grep minicron The "/etc/rc.expireaccounts" is an hourly process, and afaik it doesn't communicate, and takes a split second to execute. Normally, with a vanilla pfSense (no addons, no pfSense packages) there is no 'download every hours xx Mbytes' process. pfSense will update some small files ones a month, will check up with the Netgate update servers to see if there are pfSense or package updates avaible, but this will not create big loads of traffic, and last probably for a second or two.