I think I figured this out by installing pfsense in virtualbox VM, configuring it and then comparing pkg info commands between it and my live system. The live system always had a warning about pkg version 35 is newer than installed database 34 at the top, and there were a few other packages that were newer versions than the stock 2.4.4p3 system. The pkg version warning did not sit pretty with me so thats when I decided to blow away this new install and start over.

After I wiped the drive and did a reinstall, I reapplied my config file. The interfaces were different from the old system (re0, igb0). Therefore until I got to the physical console and fixed it, the packages never installed because it could not contact the internet. The second time around I edited my xml config file in notepad++ and altered the WAN and LAN with the proper igb0 and igb1 designations as they are on the new box. Next wipe I got it back up and restored config. This time since the interfaces were correct, when it restarted it had internet access and the system was able to automatically reach out and download all of the packages. At the top of the web ui in a yellow banner it said to hold off on any changes while packages are reinstalled from the internet. (This is the behavior I noticed in my VirtualBox install test).

The only one I had to manually install was bandwidthd (it was in the menu but the package wasn't installed). But after giving the system time installing all of these packages, I was able to install the Unifi controller using the github script. I then pkg lock these three packages:
boost-libs-1.71.0_2
icu-65.1,1
mongodb34-3.4.23

I then installed the command line packages for lsof and nano, and they installed and work without issue. Nothing was downgraded or removed. System is running smoother than it ever has.

I think the pkg database got messed up in the original install after importing the config, since the system was not able to contact the internet and complete the package install. There was no button in the UI to "retry" and reloading the config and just choosing package database did not seem to do anything. A clean install fixed it.

@magokbas said in Pfsense 2.4.3 Freeradius 3.x ldap problem:

With the same settings as FreeRadius2, FreeRadius 3 ldap (active directory) don't work. when activate ldap is did not work sql. sql started to work after last update but ldap still does not work.

This problem still persists.

@cdx304 said in Snort 4.0_8:

Snort does not want to start again .Was working fine ? Pfsense is latest 2.5 build .

I assume you mean Snort 4.0_8 has been working for you and then just suddenly started not working. If so, then read on.

This is almost always caused by a rule syntax error (or could be a required preprocessor is not enabled). Look in the pfSense system log and you should see a Snort error message that will tell you what's wrong.

When the rules update (usually twice each week) it is entirely possible for either a rule to be published or updated and have a syntax error in it, or a rule that was previously default-disabled by the Snort team might have been changed to default-enabled by an update. If that particular rule need a preprocessor enabled that you have disabled, that can result in a startup failure.

So check the pfSense system log to see why Snort is not starting. Post back here if are not able to identify the cause.

@vw-kombi said in What is the status of ARPWATCH package?:

I recently had to delete and re-create a vpn ouotbound connection, and arpwatch did not like this. In addition to the usual mesages, I am getting this with every cron execution - the interface mentioned in the email I get below does not exist anymore. It is not mentioned in the xml if I do a backup and edit either - I assume its in some sort of arpwatch database, but no amount of uninstalling and re-installing seem to rectify this email every 5 minutes :

X-Cron-Env: <SHELL=/bin/sh>
X-Cron-Env: <PATH=/etc:/bin:/sbin:/usr/bin:/usr/sbin>
X-Cron-Env: <HOME=/root>
X-Cron-Env: <LOGNAME=root>
X-Cron-Env: <USER=root>

Error: Unable to get interface "ovpnc3" statistics.

I don't know anything about the inner workings of pfSense, but is it possible that this is causing an interface to become visible/invisible, and arpwatch is "just doing it's job" in alerting that a "device" has appeared on the network (and not been marked as an allowed device), disappeared, and then reappeared. Every tine the device comes back, it generates an alert, and unless there is some way to mark the MAC address as "allowed" this behaviour will never stop.

Just a thought, I don't know if it has any merit.

@jimp Thank you, and to everyone else who replied here, too. I uninstalled v1.2_2 and installed v1..2_3, and everything worked as expected.

Not that it really should matter in terms of starting up, but you apparently have no rules selected for your LAN interface. That means Snort would not be really doing anything for you even if it started. At 10:11:19 in the log is a warning about "no text rules or IPS Policy selected for: LAN".

Your Snort Subscriber Rules are also failing to download. Notice the "Server returned error code 505" message in the log at 10:10:28. The most likely cause of that is a trailing space in your Oinkcode. Retype or paste in your Oinkcode again and be sure that is no trailing space at the end and that every character is correct.

So from the log, Snort appears to have started successfully. Does it still not show as running?

Open a CLI (command line interface) session on the firewall either directly on the console or via an SSH connection and see what the output of this command is --

Do you see any running Snort processes in the output of that command?

I also see a Gateway Alarm message in the log. If that happens often and if the gateway monitoring logs a "gateway down" message, that will trigger pfSense to issue a "restart all packages" command. If more than one instance of that happens in rapid succession it can result in the Snort process either getting clobbered, or sometimes, two duplicate Snort processes getting started.

That was just a cosmetic issue and is corrected in the repo, so when the next build happens, it will be fixed.

Remove squidguard and then try to get squid working alone first. If it still dies, check the System log for anything related.

Yeah would be nice to have an option.. My controller runs all the time, and wouldn't call it major ;)

You should be able to pick, or even have option of say if controller is offline the AP sends..