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?

link|improve this question
feedback

2 Answers

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.

link|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
feedback

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.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown

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