Of course this is possible with pfSense, but you may need to invest time (and money) to make it work properly. In my experience, most WIFI adapters won't work (properly) in pfSense. I guess this is because of the FreeBSD base. FreeBSD doesn't seem to support WIFI adapters as good as for example Linux. The solution I'm using is to use WIFI routers in "Client Mode", and use the LANs of these routers as WANs in pfSense (this means "Double NAT", which isn't a real problem IMO). My setup is working like this: one ADSL line (main WAN), and two TP-Link Archer C7 v2 with DD-WRT in Client Mode as Load Balance/Failover WANs. All of these are connected to a switch with seperate VLANs for LAN and each WAN. In pfSense several Gateway Groups are setup to utilize the different WANs, and traffic is forwarded to these Gateway Groups with firewall rules. The system is working very well, but it's a rather complicated (and expensive) setup because of the many different devices involved. On the plus side, it's easy to change the WIFI networks the routers connect to, or swap the routers for other models (3G/4G routers for instance).

Also, when the user edits an old rule that has no 'ipprotocol' tag in the XML, the ICMP types listed in the XML are not automagically selected on the rule edit GUI. So the user can easily press Save without noticing and lose the previously-selected values. Issue: https://redmine.pfsense.org/issues/7300 PR: https://github.com/pfsense/pfsense/pull/3573

I would just set the Comcast gateway to bridge mode and disable its internal firewall (or setup a rule to pass all if it can't be disabled). That way you just have pfSense manage everything.

My username is accepted at the Portal. Everything is in lowercase So that is NOT the problem.

@doktornotor: The way to fix this is to do a clean install and restore config.xml. The Snort widget sure like hell does not contain SquidGuard XML, your filesystem is toast. I got it to work! You gave me a clue that I had overlooked. Thanks! PHP is a foreign language to me since I don't do any web programming. Before I jumped into the frying pan and do a complete new install I tried something. Since the file seemed to be corrupt I deleted it (/usr/local/www/widgets/widgets/snort_alerts.widget.php).  I then tried the web interface again. The stuff in front of the dashboard was still there, but all of the menu items could be selected. I selected system –> package manager and deleted snort. It never came back and told me that it was deleted so I did a back space and checked to see if SNORT was still there and it was gone. The stuff in front of the dashboard disappeared and every thing seems to be to normal. All the function on the menu selections appears to be working correctly. I have not reinstalled snort yet, but it should work. I have not done a reboot. Could be a bad idea! What would have caused this? any idea?

I am connect to my home network through OpenVPN running on pfsense and can watch TV served from my HDHomerun Prime anywhere I go.

I just tried the same procedure here on a 2.3.3 firewall and there was no problem at all. Does that happen even before you press Apply Changes, or after? From the console, before putting that in place: cp /tmp/rules.debug /root/rules.debug.before Then re-create the issue and run: cp /tmp/rules.debug /root/rules.debug.after Then once you regain access, grab both files and compare the two using diff or similar, see what shows up. Like this: diff -u /root/rules.debug.before /root/rules.debug.after Normally you'd only see additional pass rules and they wouldn't affect anything on your local network.

"what is the default layer 2 routing protocol? " Layer 2 does not have a concept of routing as such.  VoIP does not really care how packets are routed either.  Perhaps you would be better off describing what your problem really is or what you are trying to achieve.  Either way, this is the wrong forum. Cheers Jon

After a clean install of 2.3.3 on my backup APU I made another attempt to upgrade the currently active unit from 2.3.2_1 to 2.3.3; this time I did it via the serial console, command "pfSense-upgrade". Not surprisingly, it worked perfectly this time  ;)

I also encountered this error, but in my case there was a circular link causing it: ls -alFh /root/var/cache/ total 4 drwxr-xr-x  2 root  wheel  512B Sep 28 20:10 ./ drwxr-xr-x  4 root  wheel  512B Apr 12  2016 ../ lrwxr-xr-x  1 root  wheel    24B Sep 14 14:21 pkg@ -> ../../root/var/cache/pkg (In case others stumble upon this thread.)

Indeedy clearing the browsing data does reset the graph. Than Johnpoz :)

It is interesting to read about all your views about Secure Boot and security concerns but If I understand it correctly freeBSD and therefore also pfSense have no support for Secure Boot yet so even if there are some benefits of using it the discussion is purely academic from a pfSense perspective. Does a strong BIOS password offer protection even against attacks with no physical access? Perhaps this is an option to be considered?

I don't know why you would say that.  You got: biting, sarcastic comedy the actual answer that you and everyone else suspected was the case opinion slightly related to the original topic and all at no extra charge  :D

One more question: I have two boxes in failover config. Will there be any problems if one is running Nano while the other is on Regular? Thanks so much for the help!

Thanks a ton jimp, was worried about that one. :) Greets