Ah, so at the console menu directly? Hmm

Nice

Yes it's still the safest way. If I were upgrading something something very remote with no recovery option I would remove all the packages first. But it's almost always a memory exhaustion issue and the 1100 is most likely to hit it with 1GB. I've seen the 3100 hit it with 2GB when it's running lots of packages but I upgrade mine here with Snort and pfBlocker still installed. I have limited lists and signatures loaded though. On a 4GB box it's unlikely to be a problem unless you really tried hard to exhaust the RAM with all the Snort signatures and every pfBlocker list! In any case I would always have a backup of the config and a recovery media available just in case. It's often quicker to reinstall anyway so it's huge deal for me.

DOH! I meant to put 2.7.2. Thanks for the replies.

@stephenw10 Thank you for your help so far. I will wait for your feedback to see if there is a solution. Perhaps I will simply downgrade to version 2.7.2 for the time being in order to keep my installations operational.

Could be a subnet conflict if they both have the same LAN subnet. That will be an issue when you try to tunnel traffic between them also if so. Change the LAN subnet on the new device to something unused. Otherwise nothing special should be required there. The default WAN setup as DHCP should work fine behind another pfSense install.

@stephenw10 Well the good news is I haven't been able to reproduce this at all. But also wish I knew what the actual cause was lol. This was enough to check off my "incident report" but would be nice to dig deeper, just not sure where to go from here with the logs I have so I guess that's that. I've made some changes similar to what I did when this happened (aliases, rules, IPsec tunnels, etc...) and nothing went wrong.

@stephenw10 BINGO !! Thanks again as ever. My ISP recently changed the behaviour on the fibre accounts. The upstream gateway showed offline - I changed the monitor IP and - all working - thanks so much!!

It looks like what actually triggered that 'crash' though was trying to open a 600MB file in Diag > Edit.

Oh you mean you have the PPPoE session running on the CARP VIP? Not the VIP on the PPPoE? That makes more sense. That's what was used in an HA setup previously. But that is not a supported setup. if_pppoe cannot run on a CARP VIP in the same way. I believe there is a user script being developed in another thread as a workaround.

@detox The "ver" command line program shows: C:\>ver Microsoft Windows [Version 10.0.26100.6584] The Windows command "winver" works also. I was asking if you see that in NtopNG since I have no idea. We don't identify that at the router because for our clients we have records of the PCs and most have our ITS TeamCare agent on them anyway, so we have all sorts of automated reporting.

Unless you're somehow tunneling traffic to somewhere else in pfSense then that message is nothing to do with pfSense. It's the server telling you the source IP you're using (the pfSense WAN address) is not allowed to access it. For some reason. Now if you have a VPN setup in pfSense it could be tunnelling your traffic to some remote source IP that's in a completely different region. But where is the VPN server your client VPN connects to that then allow the connection?

@TTWE can you post the logs around the 2:00 event?

@stephenw10 Yes, after reboot no issue. Good, but strange.

@maverick_slo Noop. I said : I can image and gave some examples. Only had a coffee or two this morning. Look at what has changed over the last 10 years. Chances are that things keep on changing. Our VPN needs will change also. Another example : 4096 bits deep CA/certs will do the job nicely today. It's secure enough. Then a major AI / quantum technology breakthrough will make this "4096" encryption way to dangerous. Like : "RSA" will fade away, it must be "ECDSA" or whatever will be invented in a near future. Your bet is : this won't happen in the next 10++ years. And I hope your right, but I won't place any bets on it though. The contrary will probably happen, as this is what the past told me. @maverick_slo said in CA cert renew: Openvpn is being ditched by Netgate? Like this : OpenVPN is open source today. Like MySQL was in the past, and Javascript. Then it get sold to some company - and now it needs to get monetized = you have to pay for it. In that case "OpenVPN" will most probably lose it's place into a product like pfSense. Your 10+ scale is, for me, a huge time scale when you deal with security software. edit : but were getting off topic here. Your question isn't that special actually. I'm pretty sure it has been asked before. Dig (search) into this forum, and you will find equivalent question and more meaning full answers.

@cheapie408 said in Pfsense drops internet every few days: ... and it goes back immediately so I don't think this is an ISP issue True, it could be as simple as "x.x.x.x " decides not to reply on ping (ICMP) anymore. Or, as ICMP is a low priority protocol, the packets would get ditched. The result is all the same : if ping packets don't come back, dpinger, as a default action, will 'reset' the WAN interface. You can test this situation : Disable the monitoring action ( System > Routing > Gateways > Edit ). If the only issue is that ping packets don't come back anymore but other traffic is flowing normally, then there is no real need to reset the interface, no need to rebuild the connection. Another possible solution : pick another IP to ping .. ?!

Some of those APC UPS network cards can be pricey, but if you have one already might as well use it. I simply connect my UPS directly to pfSense via USB and NUT. All TrueNAS clients powered by the same UPS, poll UPS status using NUT from pfSense. I believe NUT is available on UGreen proprietary OS.

@Wylbur I also block IPv6 on my WAN interface, all fine, doing only IPv4 in my Lan and to my WireGuard VPN Provider, no IPv6 @ all... LOL... All is working fine, wish you good luck!