Hope they resolve the issue for 2.2 as early as possible.

Yes, that was an Alix running nanoBSD. A switch back to boot from the old slice brought back 2.1.5 untouched. That is the big benefit of the nanoBSD 2-slice system - you can mess up whatever on the upgrade and then go back really easily. If the upgrade booted far enough to run the config upgrade scripts, then you might have to put your old config back, depending what features you used that had config changes in the upgrade. But you do not have to remove the media and rewrite a good image on it.

Not sure why the cpu usage display was disabled, but it seems to work fine when re-enabled. Edit the following… folder: /usr/local/www/widgets/widgets/ file: system_information.widget.php on or about line #97, change from: jQuery("#cpuPB").progressbar( { value:false } ); to: jQuery("#cpuPB").progressbar( { value: } ); save the file and refresh the status dashboard. Jay.

@cmb: If you DIY, you may need to change things like that or otherwise have a less than optimal install experience. People who buy them from us don't have that concern and have a very easy means of initial install, and an easy means of re-flashing if necessary. No minefield at all if you buy from us. If you want to DIY, you have to expect you might be in for some challenges. The price premium going that route is double. Can you not have some cheaper monetization path that is software only? Perhaps letting people buy the super to easy install version, or having some very clever nag screens in the menus or the dashboard? The main barrier to entry for a much wider audience is the install process. Thank you for listening to my pleas. :)

Never put any local networks in your OpenVPN config like that, routes are for destination networks to be reached via that path, not source networks. You'll want to assign your OpenVPN interface and configure policy routing accordingly to send traffic sourced from those IPs out the VPN. You can more or less follow the interface and rules part of this. https://forum.pfsense.org/index.php?topic=29944.0

Here is one of a few previous posts from others regarding Infiniband support: https://forum.pfsense.org/index.php?topic=71317.15

Fixed it! Thank you cmd! By pointing me to the states I was able to troubleshoot the problem! An alias was entered that was specifying IP's not port numbers shooting ALL traffic to my mumble server. MY alias's have been renamed, but they never Dynamically changed in my NAT policies. I will make a metal note when you change alias names they don't auto change in NAT policies like they do firewall rules.

It wasn't mandatory in 2.1x, but in some circumstances it was possible to configure either way and it'd work. It shouldn't have been configured that way, our documentation has always shown "none"/"none" there. https://doc.pfsense.org/index.php/Using_IPv6_on_2.1_with_a_Tunnel_Broker The v4 gateway will just be there for now. We'll clean that up some point post-2.2 so it only shows gateways for protocols that are enabled on that interface. It won't hurt anything in the mean time.

As cmb pointed out before on another topic, this isn't the right fix for squid 3.x. It works, but there are symbolic links that were never created when the package is installed. Once they are created/corrected, it should work. Only issue i've found so far is with c-icap not starting even after after creating a bunch of symbolic links based on errors when trying to start it manually from the shell. I didn't try transparent mode or ssl mitm as I have no need for it Lightsquid uses perl and is experiencing the same issue where no symbolic links were created from what I can tell. I'm also think its missing some options when it was compile.

It won't show anything useful, what is it you're looking for exactly?  This is almost certainly a BSD bug, replying to the thread on there would be the best way to troubleshoot this.

There's a similar issue when one creates an interface with static IPv6, then later changes it to Track Interface… DHCPv6 will continue to run, even though DHCPv6 settings cannot be modified when the interface is configured as "Track Interface". RA settings are also likely affected too. Basically, changes to one area (interface) that affect another area (DHCPv6 and RA in this case) are not actually being changed in the affected area, allowing it to continue functioning even though its settings can no longer be modified. Of course, the issue I mention could also be resolved if feature 3029 would be implemented, but that still doesn't solve the OP's issue.

thanks everyone!

Ok, I just reinstall the whole system. Those``` Fatal error: Call-time pass-by-reference has been removed in [...]

I just submitted another one and saw briefly something to do with ipsec. Anyway downloading latest version so will see how thats goes.

It sounds like freebsd works the opposite way to the windows swap files, in that windows will use swap irrespective of ram, but with freebsd it sounds like its used only when physical ram is exceeded, and Linux does a bit of both with the swappiness option. Just wanted to make sure I was not inadvertently prematurely ageing my firewall. Thanks for the info.

Just updated, Using the latest: 2.2-RC (amd64) built on Tue Dec 23 05:11:07 CST 2014 FreeBSD 10.1-RELEASE-p2 Doing Status -> IP SEC It looks a lot better, missing descriptions, but way closer than before. As far as the Dashboard, still still 0 for active, inactive and mobile.  

Thanks for the tip.