hardware issues with your storage device seems to be what is indicated. plug in a standard sata drive and reinstall, see if it resolves the problem. if it does, get a 2.5 inch drive and squize it in there ;)

Thanks Supermule. Been looking at Squid's Reverse Proxy, but I have no luck figuring out how to make Squid take care of the SSL part for my internal HTTP sites. I tried both Squid3 and Squid3-dev but still can't get it to work. Am I missing something or is there a guide somewhere to set this up?

For me it happen so infrequently that I can't be bothered spending the time to fix it.  Plus, I only use VirtualBox as a play lab.  For my real production work, I use vSphere 5.5 and I have never had this issue with VMware.

@imperialdrive: @imperialdrive: Just upgraded from 2.1.1 to 2.1.4… our office moved into a new building and the PFS install there was 2.1.4... after years of great performance, we quickly noticed RDP disconnect before a minute, every time, when going over a VPN connection handled by an internal MS RRAS server.  I went through everything I could think of before finally hooking our previous office PFS device and BOOM everything worked just fine.  So, now I'm thinking, ok let's upgrade to the latest version while I'm at it... now the constant RDP disconnects return. Downgrading now, but hey I feel your pain.  If there's anything I can do to help troubleshoot this for others, let me know. OK, I spoke too soon.  Still had issues.  Downgraded to 2.1.0… STILL ISSUES... went through the following settings with success - disable gateway monitors, clear invalid DF bits, disables firewall scrub, bypass firewall rules for traffic on same interface, unchecked the private networks options under wan, disabled all offloading under network interfaces under advanced After all that, and a full reboot... everything is working.  I'll keep an eye on it and slowly undo some of the changes to narrow it down. Upgraded to 2.1.1 and still running, also crossed the following off the list (offloading under network interfaces can be default, checksum offloading enabled, gateway monitoring can be enabled, disable PF scrubbing does not have to be checked, clear invalid DF bits does not have to be check) which just leaves the bypass firewall rules for traffic on same interface and the unchecked block private networks optoin under wan. I'll upgrade to 2.1.2 later this week and report back more findings.

I would like to point out for anyone else looking at this. If you take the reported average and divide it into the total transferred, it would indicate that the window was only 30 minutes, which makes no sense.

Linux/FreeBSD fundamentally treats RAM differently than on lets say… Windows. The operating system is designed and configured to page/cache as much as it can, and then expire/kick out the less important stuff when the need arises (squid cache, VPN, heavy outbound NAT, lots of states). We have a CARP pair in a data center acting as a reverse proxy which has 12GB of ram. Last time I checked we were using about 95% of total system RAM there. The main firewall pair has 4GB, supports up to 3,000,000 states, serves as VPN headend and NAT, and has about 10% usage. It all depends on your application and how you use the box. :)

The idea of using a separate WiFi access point is (in my mind) based on the idea that the AP has to handle the "wireless" part of the connection in the external box or the internal card, no matter which setup you choose. The advantage of the internal card is you theoretically get more control of the cards internal properties - although support for the cards is sporadic in some cases.  Integrating the network forwarding and routing control is done like any other interface. The external AP is already designed to be "self-supporting" and the internal config has to allow config of the wireless part.  The networking issues are normally handled through the simple expedient of disabling the AP's DHCP and any forwarding functions, UPnp, etc.  Doesn't DD-Wrt have an AP only mode? Personally I have no problem setting up AP's in this mode and treating them like an "extension switch" on my LAN networks with the ability to rely on pfSense for the rest of my firewalling/routing control. Just my $.02  ;)

What is your LAN interface setup? Do you have an internal router or layer3 switch? Any reason you're not running 2.1.4? Steve

@dmad: …they put the sim card in backwards... Ha.  ::) Doesn't make it easier when you're dealing with that level of competence! Steve

FYI I just updated to the latest alpha 2.2 built on Mon Jul 28 12:22:20 CDT 2014 and I still have the problem. I remember reading something about the apinger in the forums a while back.  I just did a search for "apinger" and see that lots of people are having problems with this. I'll disable apinger for now and watch the forums for a fix. Thank you very much for your time, KOM!  And thank you, developers, for pfSense! –EDIT I renamed this forum thread to attract less attention now that I believe we've found the problem.

There are numerous posts from Bill Meeks (Snort/Suricata Package Maintainer) and others  which will help setup Snort. https://forum.pfsense.org/index.php?topic=61018.0 https://forum.pfsense.org/index.php?topic=64674.0 (and this one for Suricata) https://forum.pfsense.org/index.php?topic=78062.0 You can start Snort in "non-blocking" mode and weed out the False Positives. Then turn Blocking Mode on after that process. Snort/Suricata is not something you turn on and walk away. Also before you suppress, you need to determine what the Alert means. If the Rule is something that you never want to see, its best to "Disable" the Rule. If you want to still have the Rule Active but Suppress it for a certain website for example, that is when you should use a "Suppression". This makes the Performance better as Rules are Disabled instead of having the Alert and suppressing the output. Maxmind has a free GeoIP Database for Countries that is Updates each month and is 98% accurate. It needs to be formated so it can be incorporated into pfBlocker thou.

@razzfazz: @gravyface: Perhaps taking the opportunity to actual read through the request before responding with a hostile tone and we'd be that much farther ahead. That works both ways; your initial description wasn't exactly crystal clear. In any case, the way VLANs work in FreeBSD (and hence, pfSense) is that you have a parent virtual interface that will receive all untagged traffic (and only that), and then a separate child interface for each VLAN. In your scenario, you'd have vr2 as the physical parent interface; this will be your OPT1. This parent interface sends/receives untagged traffic only. You'd then create a child VLAN interface on vr2 (via interfaces -> assign -> vlan) for VLAN 20; this will create a new vr2_vlan20 network device that sends/receives only traffic with that particular tag. You will than have to create an OPT2 interface for this network device via interfaces -> assign -> interface assignments (the newly created VLAN interface should show up in the drop-down list) and set up DHCP, etc. as you want. If you want your LAN and OPT1 ports (i.e., untagged traffic on vr2) to be on the same L2 domain, you'll have to bridge them (interfaces -> assign -> bridge); in theory, you should be able to either create vr2_vlan20 and then bridge vr0 and vr2, or to create the bridge first and then create the VLAN with the bridge device as the parent; I'm not sure if the pfSense GUI will actually let you do the latter, but the former should work for your particular use case. Yes, I realized that I wasn't clear, which is why I clarified that in reply #9. I believe I'll need to do the latter, and thank you for replying (and actually reading the post!).

Triple nat? Oh dear, I'd buy you a beer if I could. Yes, tear everything out, and replace it w/ a pfSense. Make sure you document everything and fully understand all the firewall rules, port forwards etc. I'd like to say that although convenient, exposing 3389 to the world although convenient is not considered best practice. Try to push for a VPN tech (OpenVPN or L2TP, NOT PPTP!) which will put them on the internal network, they can then RDP into their machines. For an added layer of security, check out DuoSec as well for people RDP'ing into machines on your network. It's 2factor auth that's free for up to 10 users (basically it sends push notifications to your smartphone which you then approve/deny so even if the password is compromised it offers some additional security). With a bit of work DuoSec can be adapted for people dialling in via VPN as well – so when they hit 'connect', a SMS/Push Notification is sent to their device which must be approved before connection.

When you setup your new OPT1 interface, it will likely come with the standard Anti-Lockout rules (unless you have disabled these). Asides from that, all traffic will be blocked unless rules are explicity set to pass it (as is the default configuration of just about any firewall on the market – default block all). To allow traffic to host(s) behind the OPT1 interface, you will have to add rules manually. So say you setup a FTP server and you want it to be accessible, you will need to add a rule to allow this host. The parameters you'd use would be: Interface: OPT1 (packets must come in on this interface to match this rule) Source: Any Destination: Single host or Alias <ip address="" of="" the="" ftp="" server="">- Source Port Range: FTP Save & Apply. So you won't have to worry about firewalling off the bat.</ip>

I got it working – the issue was the firmware I was running on my modem (3.7.5.2) has a bug with PPPoE. Using firmware version 3.7.5 I was able to get it to work.

Thanks, but I don't have access into the GUI at all.  Thats why I wanted to know if there was another way to disable the REFFER check. UPDATE: I got this solved by going by using the following command:  pfSsh.php playback disablereferercheck The info was from here:  https://forum.pfsense.org/index.php?topic=56956.0