Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Has anyone DIYed a *BSD/Linux based firewall that can handle gigabit traffic, running reliably for years? There are quite some software solutions but is there a hardware baseline to achieve reliable gigabit firewalling?

Some one at Open source firewall or commercial firewall claimed

"take a look at a Juniper SRX. You're never going to get the same amount of performance with pfSense on a Dell."

He doesn't mean pfSense on a Dell can't even match the $480 SRX100, right?

share|improve this question

closed as primarily opinion-based by David Schwartz, HBruijn, ewwhite, Chopper3, Wesley Jul 20 '14 at 22:36

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise.If this question can be reworded to fit the rules in the help center, please edit the question.

He's probably referring to hardware vs. software.

View from above

Yes to a certain point all hardware firewalls are software but given the right hardware you can reprogram the hardware. That is usually quite an expensive operation but once the hardware is reprogrammed the firewall can operate at line speed.

Performance in Linux

We had a DDOS attack on one of our sites with a GBit uplink. Under normal circumstances we were perfectly able to deliver nearly at wire speed. The attack however was a simple SYN-Flood and we couldn't take it.

The reason was a "crappy" card with only a single receive queue. That meant the only a single core was used by Linux to get the packages from the card. This resulted in a single core running at 100% usage which was too slow to process all the packages. So the servers behind the firewall were all bored but the one single core was maxed out (Yes we had SYN-Flood protection on, but since there were just to many incoming packages to the card -- before Linux even knew about it -- we couldn't take it)

Once we upgraded the hardware (only the network card, not anything else in the server) to a network card with more receive queues we saw more cores getting used and that was enough for our case. Hardware was (IIRC) 16 Cores CPU wise, 8 queues on the network card. All of a sudden we had 8 times the performance and that was enough.

That being said:

There's nothing you can do against a sufficiently large DDOS attack -- we were just lucky that it wasn't larger and the new setup could take it.

I'd always go for a hardware firewall if it implies better cover-your-behind: Leaving the technical specs aside it's just a matter of risk management. Get any Cisco/Juniper/whatever hardware and a decent support contract and you'll have someone to call who has to fix the problem or pay for the losses in case it doesn't do what was promised. Of course you'll need to get the budget for such a thing, but at a certain point the money for the investement is likely to be a fraction of what the expected income is. Also having a support contract and someone else to blame is a nice cover-you-behind tactic :)

EDIT: Missing if in the last paragraph.

share|improve this answer
Cisco/Juniper will pay for your losses if their product fails? – Alex Holst Sep 21 '11 at 7:47
That was badly stated. I know a lot of support contracts that have parts in it where the provider has to pay for losses if the platform doesn't work... – Server Horror Sep 21 '11 at 9:09
"I'd always go for a hardware firewall" - certainly if you need a separate firewall controlling up to OSI level 5, then a hardware box will probably outperform a BSD/Linux box - but for anything else, the software solution gives you a lot more bang for your buck. – symcbean Sep 21 '11 at 12:08
missing "if clause" sorry – Server Horror Sep 21 '11 at 12:57
A "hardware" firewall exceed at lower layers because it is using (usually) a hard rtos which give a v. small latency per packet compared to linux. As it goes up on the layer the things get worse since is has high prio switching tasks stalled by the low prio inspection taks. The only room in which linux will not enter very soon is the "core routing" where dedicated hw rules. As Mr. S. Horror pointed, it is a good ideea to cover-you-behind with a hardware equipment. – migabi Sep 21 '11 at 13:31

I'm going to offer a counter-point to Server Horror and expand on what migabi said. For small to medium range setups, I really like OpenBSD with the constantly evolving pf, CARP and friends. As far as I know, FreeBSD (and hence pfSense) are lagging behind in getting the latests pf and CARP updates over.

Granted, you have to be willing to do your own testing and find decent systems with decent network cards and be aware of the limitations of pf, but in my experience, all setups have their limitations. Enabling one particular inspection feature in a hardware appliance can some times cut throughput performance in half, or worse. And would you really deploy a commercial solution in production without considerable testing to verify the manufacturer's claims?

Many times you can get two decent boxes for failover, plus a third for testing for less than you'd have to pay for a commercial alternative.

And lastly I'm just really uncomfortable paying a sum of money for support when it doesn't obligate them to document properly, cover losses or fix bugs in their product. I'm feeling that particular pain right now, and pain without source code just isn't my thing.

share|improve this answer

You have kind of answered your own question here.

Yes it is possible to build a high bandwidth firewall that will give years up-time, and high through-put but you can't just use junk hardware, to get good you have top pay the bucks!

If you get a HP DL360 G6 (for example, a similar spec Dell or IBM would be fine) with dual PSUs, SAS drives (or use a USB stick plugged into the mainboard) and put it on a decent UPS system that config will sit up for years and easy clear Gig traffic (the on-board NICS support TOE if you want to licence that) but if you use a domestic mainboard with a realtek Nic and an i3 you got from the bottom drawer of your desk, you may have trouble.

Also be aware decent firewall device use FPGAs to do a lot of the sums, that is wire-speed logic, no software solution can ever approach that for efficiency, spinning up 2 x quad core Xeons for 3 years will have a cost in energy!!

The above config is cheap of the re-furb market, if you are hang an enterprise off this firewall you need a HP gen8 (or equiv) with a full on-site warranty and probably 2 of them clustered for failover...

share|improve this answer

Welp, TIL Juniper's Junos is based on FreeBSD and that's what goes on their routing equipment. That being said, you would probably save money and a little headache going with a juniper appliance, because if the hardware fails you can get support for it. However, there are companies that make appliances designed to run PFSense, all you would need to know is how much traffic roughly you plan on passing through it.

Software issues are debatable, PFSense for example has a wide usage even in enterprise environments, so their are forums chocked full of information, and you can always drop by for PFSense help.

share|improve this answer

I have some running master/slave using 10 Gbit throttled to 2Gbit via softare going for 1 1/2 years now.

They are dual CPU 6 core Xeon with Intel NIC's. The Intel NIC's that we chose back then were important, but I forgot the exact reason why. I know it had something to do with the drivers and the way interrupts were being distributed among cores.

We also had the requirement to route a different interface type. Something you couldn't buy in a hardware firewall, so this was a very cost effective solution.

So yes it's very possible to do this. Use server hardware though.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.