A L2 cache collision in the CPU I dont think will show in the CPU utilisation, nor will any caching done by any nics with onboard processing capabilities like intel nics. Have you tried packet capturing using a separate bridged device between pfsense and your workstation to see whats actually going on with the packets across the network, you can get a better idea of what the packets are really doing then? Might also be useful. http://blog.serverfault.com/2011/03/23/performance-tuning-intel-nics/

@jahonix: I don't want to open Pandora's box as far as wireless speeds etc. is concerned … Understood. My statements of performance are based on real world site surveys of my property, using NetSport Pro.  So my numbers are actually tests - not manufacturers spec.  I can share heat maps and documents if you're interested…  ;)

Snort is useful, but I'd also make sure as you dont/cant use vpn's of sorts, is put the devices that need open ports on their own isolated vlan or network interface (optX). This way firmware like for some webcams cant be updated and then be used to start probing and attacking your network from within as the brute force approaches becomes easier if the next hop from the compromised device is just to your firewall and another of your network segments. Also make sure those devices have explicit rules to prevent them from logging into pfsense if on your lan interface, at the very least. If you know that access to these devices is only going to be taking place with ip addresses from a certain provider, like say the ip address blocks assigned to your smart phone provider when you access your webcam, you can also put blocks in places to stop any ip address not assigned to your smart phone provider from accessing your webcam. At the very least pfblockerNG which blocks ip addresses at the country level could be useful if noone overseas is expected to have access. However I will say, as it invariably occurs, if access from abroad is going to take place like for a business trip or holiday, more common in Europe than say the US by virtue of land mass, you can still use pfblockerNG to allow access to those countries. I've done this for customers going on business trips abroad, but always make sure you know if they are taking any connecting flights in a foreign country as they will invariably check email, office cams whilst waiting for the connecting flight so making sure you know the IP address of the airport(s) is useful. This can also be automated with your own apps thats control the pfsense or a simple cron job in some cases depending on how you approach it. Food for thought….

Check the following logs when the problem happens again: System log Gateway log RRD Graphs - Quality

@Alixy: Are crash dumps saved anywhere on nano?   If yes, how would I access them? No they are not. Saving crash dumps requires swap space and NanoBSD doesn't have swap space (to keep disk writes low). @Alixy: If not, is saving the serial output the only way to see any crash info on nano? Yes that's the only way.

The gateway on an interface configuration page does a couple things: 1. Tells pfSense to treat that interface as a WAN 2. Defines were traffic exiting that interface should go (usually a WAN/ISP gateway address) If the interface is a WAN/Remote connection, it would be your next hop, typically an ISP address, CPE, upstream router, etc. For local/LAN type connections there would be no gateway specified on the interface.

It all depends on hardware, NICs, etc. There isn't any one rate to tell. The only way to know the rate for a given installation is to test it on that hardware with your ruleset.

yes you are right… i didn't test that command thoroughly enough.. thanks again

You're right, I did it again and it worked this time. weird. I think it might have been because I left off the #!/bin/sh, don't know.

@walbog: From the description of the original poster mike_of: i'm almost certain, it's a nessus-message…. thats why...  ;) Well, that too. ;) Yeah it is Nessus. Not that any other vulnerability scanner is better in that regard, they all seem to report their fair share of absurdity.

MBUF was high because of the Intel Quad NIC. I added kern.ipc.nmbclusters="1000000" to the loader.conf.local file and now the MBUF is down to 2% Thanks for that catch.

I just wanted to let everyone know I just reset everything back to factory defaults. Seems to be working. I was hoping to find out what the actual problem was. Thanks for the advice.

@BlueKobold: My lan is assigned to a bridge between the wireless and one of the ethernet interfaces. If he inserts a WiFi miniPCIe card into the SG-xxx unit and he creates a new interface for the WiFi card that must be bridged to an LAN Port! Actually, it doesn't have to be bridged - you can assign an IP to the wlan port and then have one wireless network segment and a second wired network segment. But, I wanted the wireless clients to be able to see the wired devices on the network (ie, tablets able to play media to wired media players) and for me it was much, much easier to bridge the networks. @BlueKobold: If you reboot, and many settings were lost, you could also try out to set up those things in a /bootloader.conf.local to not loose them all, as I see it right. The same is coming with updates and upgrades, please don´t forget this. I have no problem with settings persisting through reboots.  I've most often been rebooting due to dumb moves on my part or to be 100% that a non-working vpn config isn't trying to reestablish - ie, roll back to a backup and then reboot. @BlueKobold: For sure it would be even the best to go with external WLAN APs related to a proper and smooth running pfSense box. I hope this isn't an accurate statement.  I purchased the 2440 from pfsense with the wlan card installed. They did not offer a discount on the model with wireless added due to it being an inferior design :)

@doktornotor: Hmmm… it's doing some stupid countdown. Not really sure how to change it. If there's nothing configured, the first option value (32) will be selected. <select name="subnet" class="formselect" id="subnet">when you create a new opt interface and go to put an IP on it, it defaults to /32 vs /24Have seen multiple threads where the IP is set to /32 vs whatever mask they want because it default to this in the dropdown list.[/quote] for ($i = 32; $i > 0; $i--) { echo " <option value="\&quot;{$i}\&quot;" ";<br="">if ($i == $pconfig['subnet']) { echo "selected=\"selected\""; } echo ">" . $i . "</option>"; } ?></select> The countdown is just filling the SELECT drop-down control with a list of values from 32 down to 1.  The way SELECT controls work in HTML is that the first value in the list is "default selected" when the control is displayed unless a specific entry is marked with the "selected" tag when it is added to the list.  One way to fix this is to add a string like "Select a netmask" or something as the first entry added to the combo-control, and then adding the countdown values after it.  If you did this, then some extra validation code would need to be added to the PHP code processing the SAVE button command. Bill

Hi Steve Thanks for the detailed reply. I'm going to work on this tonight in a VM (the WG is too loud for the current room it's in) and I'll let you know how far I get. Thanks again.