Just posting because it might help others: Friend of mine had failed update as well; upgrade from gui but following on console. Seems file system was read-only? (Could this be something left over from nanobsd days?) Attached the screenshot I got from him… (no credits here) [image: update243.JPG] [image: update243.JPG_thumb]

@LanceD: Just forced the update again like described here https://www.netgate.com/docs/pfsense/sg-4860/reinstall-pfsense.html Everything workes fine.  :) Did the same.  At least the machine works again now. This was not so nice. Monitoring logs are lost apparently. However, the config could be salvaged as described above. I still have no idea, why the update failed.

There's a post with a redmine ticket here. For what it's worth, I've hit this bug too.

Today is the day I reply to myself. My current workarround:  disabling the umass driver with a device hint /boot/device.hints add the line  hint.umass.0.disabled="1"

That setting takes all unsolicited traffic coming into its WAN and forwards it to a specific IP address on the inside. That would be pfSense's WAN address.

@stephenw10: You can test it against a single client by adding a firewall rule to pass traffic from just that one IP at the top of the LAN list and setting it's gateway to the BT WAN directly. Steve Thanks that worked!

I can not access anymore the webinterface What does "can't access" mean?  You get an error message?  It times out?  Your login fails?  The page only half-renders?  What have you tried to fix it?  Did you clear your browser cache?  Have you tried a different browser?  Did you go to console and select option 11 or 16?

Hi ! I have solutionned my problem. Thing is that my old install was on an unknown VM system, so the Integrations options in advanced features for proxy server was : redirect_program /usr/pbi/squidguard-amd64/bin/squidGuard -c /usr/pbi/squidguard-amd64/etc/squidGuard/squidGuard.conf Not only redirect_program was deprecated, i change for url_rewrite_program /usr/local/etc/squidGuard -c /usr/local/etc/squidGuard/squidGuard.conf cause that's what i found on Internet. But it doesn't work. And when I'm trying to launch Squid without squidguard integration there was no problem. So, i keep integration option blank, uninstall SquidGuard, then reinstall squidguard. And installation did the job and find the right way : url_rewrite_program /usr/local/bin/squidGuard -c /usr/local/etc/squidGuard/squidGuard.conf

The most straight forward approach would be to backup your current config, install fresh from USB stick and reapply your config afterwards. Don't forget to backup your config first. ;)

Thank You! I will give that a try.

The operating system enumerates the ports. It has to do with the PCI bus they are on, etc. Every motherboard is different. You need to look at the MAC addresses and be sure you're talking to the correct port.

Yup.

Most likely, your other tables (like bogons) are taking up space first and that one happens to fail loading afterward. You can increase the Firewall Maximum Table Entries limit under System > Advanced, Firewall & NAT tab. It defaults to 200,000 but the IPV6 bogon list recent increased past a point where that amount is insufficient to hold it all during a reload. We are increasing the default to 400,000.

If you can get to the console, you can disable that check pfSsh.php playback disablereferercheck Or try accessing it using another IP address on the firewall (e.g. your WAN IP address), you can still hit those from the LAN.

There is an updated ntopng package available for testing on 2.4.4 snapshots which should address this problem. Give it a try there and see if it works for you.

See https://forum.pfsense.org/index.php?topic=145990.0 I have it on 2.4.2-p1 too /Bingo

The elixir to every I.T. problem: REBOOT. :D

check duration: 1001ms Well your testbox took longer than 1 second to respond.. And did so 3 times in a row. So either the url its checking does a lot of processing and is already close to that 1 second regularly. Or perhaps the webapplication got restarted and needed to load its configuration from disk again or some memory garbage collection happening.. Just guessing here.. Anyhow there was a period of time that the webserver was unable to respond properly.. Making the health checks span more time than the default 1 second works to avoid the 'down' syslog message, it doesn't fix the underlying problem. Perhaps enable the "Log checks" on the backend, then it will log a bit more around when the state of the health is changing. And might tell how often one or two checks are failing..