@TieT: Is it also fully enabled on the WAN or LAN ? Services - snort - interfaces - the little arrow is green ? WAN Enabled.

Hopefully the package reinstall has finished by now. If not, then go to Diagnostics->Backup/Restore and press the "Clear Package Lock" button. Then look in the logs for error messages about what went wrong during the package install. Then (re)install your packages.

The bug report is the way to go… last i knew there was no real maintainer for vnstat2.. Its been worked on by different people.. I was going going to fix the paths this morning but someone beat me to it :-)  Other packages have the same issue with the paths being wrong

Yup i'm glad pfsense finally moved to freebsd 10.1 ! that freebsd 8 was so legacy it made the project look "outdated" ;-) I was able to upgrade one of my boxes just fine and the installer re-installed the packages automagically and all works except unbound … but, i hope somebody replies to my "unbound" post soon :) I'm just excited that i get to use VMXNET3 now since Freebsd 10 supports it ( on my home machine that sometimes has to deal with 1GBPS routing between VLANs ), other than that ... i guess a "multi core" pf with freebsd 10 is good too !

Update:  So I rebooted again and now ssh does auto start? Not sure if it fixed itself, or if running the commands below helped.  Found them in a post about ssh problems with the prerelease 2.2.  There was a quote from the script that I assume is part of the clean install process. https://forum.pfsense.org/index.php?topic=83333.msg456428#msg456428 /usr/bin/ssh-keygen -t ecdsa -N '' -f /etc/ssh/ssh_host_ecdsa_key /usr/bin/ssh-keygen -t ed25519 -N '' -f /etc/ssh/ssh_host_ed25519_key So at this point I think am working.

No worries, we've all done it.  ;) Steve

squidguard is broken in 2.2 this may help for squidguard but squid2.7 i believe is broken from other reports on the forum. try squid3? https://redmine.pfsense.org/issues/4216

@kdillen: But I do know that some things get corrupt when importing a 2.1.x file into 2.2 In my case I had the following problems with corrupt files: ssh host key files unbound: root.key  (auto-trust-anchor-file) That's absolutely not true. Those two things don't even exist in the config. It's always safe to restore the full config from an older version to a newer version (but going backwards, say restoring 2.2 to 2.1, is not possible). Trying to snip out pieces of an old config backup and paste them into a new config isn't a good idea unless you really know what you're doing, as those pieces may require config upgrades when migrating to a new version that they won't get if you're pulling in partial config bits.

2.2 omits localhost from resolv.conf if you aren't binding on it, to prevent that from being an issue. That'll cause a timeout in earlier versions if you have the system configured to use localhost as a DNS server, but aren't actually binding it there. Make sure if you're selectively binding DNS Forwarder, localhost is one of the selections unless you disable its use under System>General Setup.

Ha! I'm all about Easy Editing. I've been stuck in some obscure vi mode too many times.  ::) Steve

Thanks for the suggestion to restore from the config backup.  :) I wasn't aware I could selectively restore stuff, but then chose to restore only the rrd data. I was logged in through ssh during the whole process and it was actually fun to watch it upload the data, incorporate it into config.xml, then write out the /var/db/rrd, and remove it from the config file. Before rebooting, it saved the /var/db/rrd data into rrd.tgz, and unpacked it again after the reboot. So, my data is back, with only a short missing piece during the upgrade process. Roman

I see how that isn't the expected behaviour from your point of view.  :-\  A box showing the current update URL would perhaps help there. That's the correct behaviour though, there's nothing wrong with your install. Steve

Sorry, was clearly too late last night when I replied!  ::) Your WAN is receiving an address in the 192.168.1.0/24 subnet but that is the same subnet that the pfSense LAN interface uses by default. You cannot have two interfaces in the same subnet, it breaks routing. Change the LAN interface to use a different subnet, for example: 192.168.100.1/24. You should then be able to connect to the webgui on that address from a client connected to the LAN interface. Steve

see https://forum.pfsense.org/index.php?topic=87269.0 and https://redmine.pfsense.org/issues/4270 None include fixes (yet). just figured I'd share. are you running i386 too? or amd64?

粪 - Fen - pronounced "fun" - Loose translation "crap"