Snort/Suricata is anything but quiet and absolutely NOT something that "every user" would run. These IDS/IPS things are noisy, intrusive, paranoid, plagued with false positives and require weeks of careful tuning and babysitting. Absolutely NOT something an average Joe out there would do. Regarding Squid, I already pointed you to the proper forum concerning the Squid experience. Also asked about the use case for proxy there, no answer.

I disabled the rules I created in the Firewell>Rules>LAN and the I am now able to access HTTP websites.

OK I was just checking that you had specified the prefix.

Issue was caused by on board LAN. Once I disabled it in the BIOS, I can add as many PCI NICs of any speed and still get 150Mbps down though the proxy.  Thanks for your help!

so you got a /30 for your WAN and a /29 routed to WAN-address ?

Thanks for the reply. Since stopping the service I've not had a reoccurence of the CPU problem. I will see about upgrading shortly, though I have to be careful as this is a production system. I guess I'll have to just see whether the upgrade solves the issue eventually.

I'm prepared to offer a bounty to anybody who makes this happen. Bounty thread started for those who would like to contribute RFC 4638 (PPPoE 1508 MTU) - let's pitch in

I think I already got where the issue is coming from. I have three Gateways saved in System>Routing>Gateways, where two of which is running. I deleted the first two, and now I can ping and view websites from my computers. I just don't know why would this cause the issue.

@Derelict: So put a block rule for anything not that alias. Yes. But I was asking if there was any way to automatically create and maintain that alias, not about the rule I intend to use it in. If it's not, then oh well.  Was just a thought.

That's a bug in snort, not pfSense per se. I've done Nessus scans against pfSense that come up okay, so I wouldn't worry too much about this issue unless you have snort deployed.  Additionally, I recommend reviewing the snort change log and current version to see if this was addressed.

@charlesa920: @almabes: Ok…what if you wrote a PASS rule on your LAN interface for TCP traffic destined for any IP on ports 6881-6999 and set it to log.  Maybe that will help identify them. This sounds like a workable solution which is likely to find the majority of the clients I'm looking for.  Unfortunately I know no more about writing these rules than I so about snort.  But this sounds like something I can research and learn… Pfsense is versatile and powerful.  Even though I've used it for 5 years I feel like I only have a minimum knowledge and consider myself fortunate to be able to get it to do what I need.  Now that I need it to do more, I'll have to learn more. And that's a good thing. https://doc.pfsense.org/index.php/Firewall_Rule_Basics

Probably because someone worked around it in Linux kernel/some shitty Windows driver supplied with the MB to work around their junky BIOS/ACPI?

@arduino: You're connecting to the WAN address when using OpenVPN, right? Yeah right.

If I get the admin password figured out can be something be changed on the pfsense box to make it work?

I had a good experience migrating a customer firewall from a Soekris x86 box to a SG-2440.  I didn't have any of the queuing or shaping features configured on that box.  The upgrade went well. The webConfigurator is "braindead" according to doktornotor.  If you have configured manually in your x86 configuration to pull firmware updates from the x86 URL, then that configuration will persist.  Just make sure you review it before 2.2.3 is released, otherwise you have the chance of taking your 64-bit box back to 32-bit pfSense.  It's a pain in the butt.  There's a redmine ticket to fix it. Just for completeness… https://forum.pfsense.org/index.php?topic=86915.msg477115#msg477115

So I've now setup pfSense on my VMware ESXi, I've added to LAN's to the VM, one is my default LAN vswitch, and the second is a dedicated "WAN" uplink vswitch which plugs directly into my mikrotik, both vswitches are set with promiscuous mode enabled, I've then bridged my LAN and WAN on the pfsense server and have assigned an IP to the bridge, I've created a floating firewall rule for now which allows all traffic. Everything works except the vlan traffic, the physical switch connecting the port to the ESXi vswitch is set to pass the vlans. When I remove the pfsense bridge my vlan's work as intended, the moment I re-introduce pfsense in the middle the vlans stop, all other default vlan traffic is fine and passing. Under the interface options on pfsense I have added the vlan's however it does not allow you to select the bridge interface, it only lets you choose either the lan or wan nics, so I've added the vlan's to both. Any ideas? Anyone have any similar issue or could perhaps offer some help? Thanks Just to add to this, "block private addresses" are unchecked for all interfaces.