I won't pretend to be a FreeBSD memory expert. 😉

However if you want that value to include only Free memory you can just edit that file so the line is:

You can include that as an auto-installing patch even if you wanted it to survive updates.

Steve

@manilx For what it's worth: Fixed by reflashing and restoring saved backup.

BTW: https://docs.netgate.com/pfsense/en/latest/solutions/netgate-8200/reinstall-pfsense.html states that

"If there is an existing installation on this device, the Recover config.xml option will attempt to mount the existing installation drive and copy the previous configuration, including SSH keys. Choose that option first, then proceed through the install as usual."

Did not happen, it just installed as factory default. Had to reassign interfaces/IP's to get access to the web console an then restore backup.

After that smooth sailing.

Took me 15min, a lot less time than fiddling around trying to fix/locate the issue.

@jabren said in Synology Package Manager Issue:

so I’ll be adding my previous configurations one by one to see what may have caused it.

Thats a good idea. For each configuration you add back wait a day before adding the next one.

@JonathanLee Hi,
This would probably be as good too. My rule above is Any for all my interfaces. It seems to work as intended, all traffic goes to pfSense as is now. But will remember this to try in case of issues in the future. Thanks :)

@stephenw10 Possible

DPD must be enabled on both ends or it will not be enabled when the tunnel negotiates.

If the DPD response fails the existing SADs are removed and the tunnel attempts to renegotiate.

See: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/configure-p1.html?highlight=dpd#advanced-options

Steve

Open a feature request: https://redmine.pfsense.org/

I recall some discussion of it in the past.

@stephenw10 thank you for your reply and for the link you provided.

Thank you to all of you, guys, for sharing with me your experience.

Mauro

@stephenw10 Fair enough. Appreciate it man.

@tkronic , it works much better than the old 5268AC. But I am not sure is the pfSense working better or bwg320-500. It is probably the pfSense because I actually never used the bwg320 as the router. I went directly to the pfSense. Here are the basic stat difference that I have measured.
For 5268AC, ping to 8.8.8.8 averages 3ms, pfSense is 2ms.
For 5268AC, rings lose connection usually less then 2 minutes. pfSense still happens but it is far more stable, every couple of days.
Speedtest comparison is not relevant as I upgraded from 500 to 1gb. However, I get 975mb up, and 982mb down.

My pfSense is a white-box: 2.5GbE Firewall Appliance Mini PC, 12th Gen Intel N100(up to 3.4GHz) Fanless Mini Computer Router with 4xIntel I226 Nics 8GB DDR5 Ram 128GB

The only note I will say is that rebooting pfSense does not always survive the public ip binding. Rebooting the ONT, bwg320 and pfsense all together will take a few minutes but it will always come up. My pfsense has been up for 8 days running the acme, arpwatch, notes, ntopng and openvpn. Works well for sure.

@Gertjan @TAC57 @SteveITS There seems to be some good news: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=270912

"Jaap Akkerhuis 2023-06-01 12:41:18 UTC
A fix is developed by upstairs. There will be a new release within weeks with this fix. For the inpatients among us, a prerelease is made available https://github.com/NLnetLabs/unbound/issues/887#issuecomment-1570136710."

@Ivan-70 said in Automatically create .xml full backup:

Is there a way to automatically create a full backup of pfsense every day (or at a predefined time)?

You can with CRON.

In the online documentation there are a number of options covered that are supported. https://docs.netgate.com/pfsense/en/latest/backup/remote-backup.html

@TAC57 said in 22.05-RELEASE (amd64) Unable to check for updates?:

Like this?
WAN tcp 96.46.xx.xx:31132 (192.168.30.112:45300) -> 8.8.4.4:53 FIN_WAIT_2:FIN_WAIT_2 4 / 4 277 B / 409 B

Not like that. That's a connection from a LAN side client that's being NAT'd. Unbound would be using the WAN directly with no NAT.

The only issue with Unbound I'm aware of only applied to DoT only so disabling that would have removed it.
https://redmine.pfsense.org/issues/14056

You can try the workaround there: https://redmine.pfsense.org/issues/14056#note-6 However I wouldn't expect it to do anything to a default resolver config.

Steve

Nice catch! Odd though, I wouldn't have expected those errors to reach pfSense.

@johnpoz said in Can PFsense handle 10/10 Gbe Internet?:

yeah if you want to run at gig across a 10G link that would make sense.. ;)

In my case it is running a 10 Gbit link on an SFP+ DAC from the 6100 to my first switch.

☕️

No problem I should have been clearer. Yes, the console is however you operate directly on the firewall. So either a serial console, if the hardware has one, or the 'vga console', using a keybiard and monitor dircetly.

It looks like the problem wound up being one of name resolution. Once I gave pfSense the DNS IP addresses that Comcast gave me, things started working. The weird thing was, it wasn't set on the main pfSense box either and it was working. Now, one thing that changed in the middle of all this was that the Comcast cable modem was replaced; there was a lightning strike nearby that apparently fried the one of four functionally identical Ethernet ports on the back of the modem (with cable plugged in, pfSense reported "down" for that jack but "up" for any of the others) and screwed it up in other ways so that even plugged into a working jack in the modem pfSense wasn't getting out. So I'm good for now (am continuing to run on the aux box) and have a process for moving configs from one box to the other. Now I need to build out the config more so that I've got externally-reachable boxes on one of the other quad NIC ports.

I am also using IPv6 over IPv4 here, so that makes sense.

I ended up moving back to 22.05 and restoring my backup from before that upgrade for now. This error was annoying, but what pushed me was a spent a day trying to get multiwan failover that was working before working in 23.05 and just couldn't get it to actually fail over like it should. worked instantly in 22.05 . maybe after a few more releases I'll give 23.x another shot, but for now I just need this to work as expected.

@SteveITS I did a clean install

@JKnott which is exactly what I was saying as well ;)

The correct fix for the OP problem is not to be running ntop on his wan - have no idea why anyone would want to do such a thing, it makes no sense to do that..