Why pfSense is not production ready
(Caveat: everything said below is applicable only to pfSense 1.2.3, since this is only version I ever used.)
pfSense is a great piece of software. Easy to install, easy to configure, very powerful, lightweight, stable. It’s no surprise that so many people use it when they need a software firewall or router. But after running it for about half a year in production, I have formed the opinion that it was a wrong decision to use it in a critical role. And here’s why.
Over this period, I had exactly three issues with pfSense. One of them, the breakage of CARP due to multicasts coming back over teamed physical adapters , is mostly VMware’s fault, and I’m not going to count it against pfSense. The other two, however, are clearly a reflection of the FOSS mindset (or rather lack of resources).
The first of the two is the default number of entries in the state table: 10,000. This number is fine for home use or a small startup’s web site, but any organization beyond infancy will have more traffic and will need to increase the table size. The change is simple and can be made on the fly, so it may not seem like a problem, but it’s easy to miss, and difficult to troubleshoot: connections just randomly timeout or take a long time to establish, while pfSense happily keeps its system logs free of any notifications. Considering that each table entry occupies just 1K of memory, it would make a lot of sense to set the default to a much larger number, or, better yet, implement dynamic table resize.
The second problem is much nastier. There’s something broken with IP fragmentation handling. In our specific case it affected EDNS responses (DNSSEC-enabled servers now return 2-3KB-long responses, which necessarily become fragmented). pfSense’s scrub feature would reassemble them for analysis, then send them down to the destination, again in fragmented form, and the second fragment would come in with broken checksum, which made the reassembly at destination or any intermediary firewall impossible. There are some hints that this may actually be a problem with em driver checksum offload, but at this point it’s irrelevant: if pfSense can’t do something as basic as IP fragment processing, regardless of the underlying drivers and hardware (in this case it was actually pfSense-distributed virtual appliance, so no compatibility issues should be expected), it doesn’t qualify as a production-ready firewall.
I expect it to be gone from our environment in about two weeks.
IT Infrastructure - The Infinite Source of Puzzles 
Dynamic state table sizing has been implemented for some time in the 2.0 branch. In the 1.2 branch this was left with the PF default setting as that release never truly targeted larger installations. As for FreeBSD driver bugs, it sucks you got bit by them, I’d recommend running one of the 2.0 beta releases and see if you have better luck. The base OS is running on the FreeBSD 8.0 branch vs the now somewhat outdated FreeBSD 7.2 release.
–Bill
Really absurd reasoning. You hit:
1) A VMware bug
2) A default of PF that’s very clearly documented on the front page of the web interface and easily adjustable, and now dynamically sized based on RAM
3) A FreeBSD driver bug
All 3 have nothing to do with pfSense, #1 isn’t even remotely related, 2 is easily noticeable in multiple places (front page, RRD graphs for historical, and elsewhere), and 3 is just a fact of life sometimes with operating systems of any sort.
Your end premise is absurd, you’re talking about one of if not the most widely deployed open source firewall solution, including very large, high throughput, mission critical environments. Many of those within VMware, so #3 even doesn’t add up.
Chris, I have an argument that trumps everything you’ve just said:
As a user, I don’t care why it happens.
I downloaded a packaged product. I expect it to work in the environment it was built for, with minimal tweaking. If it doesn’t, I’m not going to try and figure out who’s to blame. I’ll just stop using the product.
I heard about dynamic table sizing. I’m surprised you never backported it to the 1.2 branch. 2.0 sounds great, but as long as it’s beta I can’t accept it as a valid counterpoint.
You are using a free open source product. The only cost to you is to figure out how to make it work. Being open source, the implication is that if you have an itch, you scratch it, or wait for someone else with that same itch to scratch it for you. The current development team for pfSense isn’t interested in continuing to develop on the 1.2 branch, all effort is focused on improving the product and releasing 2.0. Were someone who really wanted 1.2 to stick around and improve to show up, provide patches and prove competent at being able to create builds for 1.2, I’m sure there would be consideration for a new release on that branch. At this time, there are simply no resources available for such a diversion as much as some people might want it.
Also, don’t forget that 1.2’s minimum requirements were to run on machines with 128M ram and the target audience wasn’t corporations. The focus of the 2.0 branch has been corporations from the beginning and as such you will see numerous features in it geared towards that audience.
I think the title of your article is somewhat misleading. It may not be production ready for your environment, but the defaults weren’t intended for a large environment either and as with most products, do expect the administrator to change some settings based on requirements.
–Bill
“I downloaded a packaged product. I expect it to work in the environment it was built for, with minimal tweaking. If it doesn’t, I’m not going to try and figure out who’s to blame. I’ll just stop using the product.”
You’re a pretty pathetic sysadmin then.
No. Just a very busy one.
“There are some hints that this may actually be a problem with em driver checksum offload, but at this point it’s irrelevant: if pfSense can’t do something as basic as IP fragment processing, regardless of the underlying drivers and hardware (in this case it was actually pfSense-distributed virtual appliance, so no compatibility issues should be expected), it doesn’t qualify as a production-ready firewall.”
You’re saying that if I ran pfsense on a machine with a dodgy NIC it would be pfsense’s fault for not working?
If the problem with packet fragmentation were the fault of pfsense, it seems likely that it would be happening with any fragmented packet, not just those of one type or from one source. Unless you are absolutely sure (“may actually be a problem with em driver checksum offload”) that the packets are arriving able to be assembled AND all of the hardware LAN-side is working correctly, you can’t say that it is pfsense having the problem.
I’d have to agree with Ed, but if you routinely expect everything to work perfectly on default settings I’d have to add “lazy” to the “pathetic” part. Sysadmin is a job, not a title.
You’re ignoring one important detail: it was a virtual appliance, built by pfSense folks, with both the driver and the NIC (a virtual one) included in the package. The physical hardware is rock solid, there are hundreds of VMs running in the same environment with no issues. So my argument still stands.
This is going to be the last comment on this subject. We had a bit of constructive dialog in the beginning, but all the later comments have been personal attacks from people who deem themselves capable of judging someone else’s professional skills based on a single blog post. It’s just a waste of everyone’s time now.