@Derelict: Running what throughput?  Looks like total overkill to me. If you're getting the quad NIC so you have ports to plug everything in, get a switch instead. Yes I have everything . Throughput of my wan is only 50mbits V

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?