I would guess it's because you are policy routing traffic from LAN clients to a specific gateway. So that works even when the firewall has no default route.

@stephenw10 said in [Crash Report] - Crash after update from 2.6.0 to 2.7.0: Which is fixed in 2.7.2. Cool - thank you. As I just wrote in my edit I managed to upgrade it to 2.7.2, so it probably won't happen again.

@rhammondwtg It sounds like they're working on adding a check to look for routers with the small partition (referenced in your link) and stopping the upgrade. That will let everyone else upgrade safely. But in the meantime it's off, so those of us with early-release models aren't left with a non-functioning router. So, manual (re)install, or wait.

@william-mandell said in Unable to upgrade SG-1100 appliance to 23.01 - Kernel panic: @jimp No Jim , sorry, but no. Not an older version of pfsense plus at all. I was on the Newest version of pfSense Plus+ that was the release #, 'freshly' and (*natively) installed before > and updated to 23.01 obviously after 23.01 came out, but before I saw that it was being 'blocked' because of some problems going on. Those statements are contradictory. Either you installed 23.01 directly or you were on 22.05 and upgraded to 23.01. That said, I checked around and apparently it's a known issue that the 1100 and 2100 recovery installers are using an older ZFS version in the disk images. While you could run zpool upgrade -a and let it upgrade that, if it didn't properly update the loader when you updated to 23.01 then it may not boot properly after. If you did reimage it with 23.01 and not an upgrade, then it's safe to run. How and why would I want to boot it to the older version(s) ZFS boot environment , its has ZFS now. The 'old' environment always said it has an 'error' and shouldnt even running, but TAC said y'all had a special version, so it's fine. If you upgraded from 22.05 to 23.01 and had a problem on 23.01, you could use the boot environment to boot back into 22.05 without reinstalling. Can I ask again, how EXACTLY do I run a program that uses your special Chip' on board to verify and authenticate that my system is running authentic pfSense+ software. Does it need to be 'on'? Not sure if it's the same chip but whichever one displays whether it is on or not has always been off. Thought that chip was for VPN? Anyway, the trademarked pc sense chip to verify and authenticate - the software running. The device that handles the authenticity part is used by the device when accessing the package repositories for packages and updates (all automatic). That is the "thoth" security chip. VPN acceleration on 1100/2100 is handled by a different function, the SafeXcel cryptographic accelerator, which is unrelated.

@jimp I ran 'pfSens-upgrade' from the Shell and the world is now safe! Other than something in item #1, none of the other issues should have been a problem on my system. Here is what I have installed. [image: 1656589707610-b15b044b-06b8-4008-8a2a-22786ca6a1e2-image.png]

Your post is not entirely clear. Perhaps it is a language translation issue ??? Are you saying that now your pfSense box is behind some kind of double-NAT? You must eventually have a public IP in order to route traffic (not an RFC 1918 address). However, if your pfSense box now communicates with some upstream host that in turn provides a NAT to some type of public routable IP, then your Snort rules update should still work. I assume other Internet traffic through the pfSense box works?? Or do you really mean to say you have isolated this pfSense box from the Internet? If that is the case, then there is no method for an offline update in the Snort package. It requires Internet access to update its rules.

@steveits everything was connected. WAN, LAN, etc... All IP addresses were properly assigned. Had to manually install packages such as apcupsd, pfblocker, etc... The funny thing is that I did not need to configure them once installed. I guess the config backup had written their configurations in a location that did not get overwritten by the package installs.

@gertjan Thanks! Issue resolved by contacting support for the new version.

@faust said in Unable to check for updates, Package Manager not working: So, I may have found a solution. Files in /usr/local/share/pfSense/pkg/repos where all empty, so I have just recovered those files from another exact same pfSense version (and model). And everything seems OK now. this was the fix for me as well. good thing we had a similar netgate 3100 elsewhere!

Cool, thanks for confirming.

Hi jimp, some good news here. Your statement that "pkg can't reach the pfsense servers" pointed me to the right direction; I haven't understood it fully, but I found a way at least to unlock the pkg issue. In my case, it was due to a double stack IPv4/IPv6 issue: to solve it, I had to temporaly disable the network interface linked to the GIF port; removing IPv6 name resolution plus removing the IPv6 default gateway and firewall rules to route IPv6 traffic didn't suffice. I don't like to be so inaccurate in test results, but as IPv6 connectivity was actually working, defining this problem will require some more tests and I meant to find a quick workaround for everybody experiencing this kind of issue. Let me know if this rings a bell.