A friend at a mid-sized UK company asked me to help review their Cisco PIX configuration this month. PIX is the dominant commercial firewall in enterprise deployments — most UK organisations of any size have one or more. I have used PIX intermittently before but never really got into the configuration weeds.
The fortnight has changed my opinion of the product. Some things are better than I had assumed. Some things are notably worse. Worth writing down before the impressions fade.
What PIX is
PIX — Private Internet eXchange — is Cisco's hardware firewall product. It runs a custom operating system (PIX OS, sometimes called Finesse), is configured via Cisco IOS-style command-line interface, and is sold as a dedicated appliance rather than software you install.
The target market is enterprise: organisations with non-trivial budgets that want a firewall they can buy, configure, and largely forget. PIX competes against Check Point FireWall-1 (software, runs on a generic OS) and WatchGuard (similar appliance approach).
The core capability is stateful packet filtering, with NAT, basic IDS-like features, and some application-layer awareness for specific protocols (FTP, H.323, SIP, etc).
What I like about PIX
Three things, in roughly increasing order.
The stateful inspection is solid. PIX's connection-tracking state is well-thought-out. The model is essentially what netfilter's stream4 does, but mature and battle-tested over years of deployment. Connection setup, teardown, and timeout handling all work reliably under load.
The performance is genuinely good. A modest PIX (mid-range) can sustain hundreds of megabits per second of throughput with thousands of concurrent connections, with low CPU and bounded memory. The dedicated hardware shows.
The configuration is auditable. The CLI is, despite all my complaints below, declarative and complete. You can dump the running configuration with show run, store it as text, version-control it, diff it against history. Every aspect of the firewall's behaviour is in the running configuration; nothing is hidden in opaque state.
What I dislike about PIX
Four things.
The CLI is hostile. The Cisco IOS command-line is famously terse, abbreviation-friendly, and full of context-dependent commands. PIX's CLI is similar but with PIX-specific differences from "real" IOS that are subtle and easy to get wrong. A configuration that looks like it should work often does not, for reasons that require reading the documentation carefully.
A simple example: configuring NAT. The command is nat, but the syntax depends on whether you are doing source NAT, static NAT, port forwarding, or NAT for traffic between specific interface pairs. The nat command takes a different second argument in each case. Worse, the precedence between nat rules, static rules, and global rules is non-obvious and changed between PIX versions.
My friend's configuration had a NAT rule that had been working for two years. After a recent PIX OS upgrade, the same rule produced different behaviour because of a change in precedence. Diagnosis took an afternoon.
The licensing is byzantine. PIX features are gated by license. The base unit comes with a basic license; specific capabilities — VPN tunnels, more interfaces, higher connection counts — require additional licenses. Each license is hardware-locked and tracked through Cisco's licensing system.
The operational consequence is that the same hardware may or may not have a given capability depending on what licenses are installed. Migrating a configuration between two PIX units becomes complicated when the licenses differ. The licensing model also encourages organisations to leave capabilities disabled when they could be useful, simply because activating them requires a procurement cycle.
The logging is rough. PIX writes log messages to syslog (good) but the format is verbose, inconsistent, and hard to parse mechanically. Each message has a numeric ID and a free-text description; the format of the description varies between message types in ways that are not always documented.
Converting PIX logs into structured form for downstream analysis is a per-message-type parsing exercise. There is no canonical structured format. Operators end up either accepting the unstructured logs and using grep heuristically, or writing per-deployment parsers.
For a product whose value depends on its logging being usable, this is a real gap.
The application-layer fixups are sometimes wrong. PIX has "fixups" for several application-layer protocols — FTP, H.323, RTSP, SIP. The fixups are supposed to make the firewall transparent to these protocols, which use multiple connections in ways pure stateful filtering does not handle.
Most of the time the fixups work. Occasionally they do not, and when they fail the failure modes are baroque. A specific FTP client's data connection may or may not work depending on which mode it negotiates and which fixup version PIX is running. Diagnosing application-layer firewall issues through PIX's logs is, in my experience, harder than it should be.
What I have come to appreciate about open-source firewalls by comparison
A short reflection. After two weeks of PIX, working with iptables feels different.
The iptables configuration is more transparent. Every match, every action, every modification is in the rules — visible to the operator. PIX has a substantial amount of "smart" behaviour built in (the fixups, the default protocol awareness, the implicit rules for established connections) that is correct most of the time but is harder to reason about when things go wrong.
The iptables logging is more uniform. The kernel writes log entries via netlink in a structured format. Each log entry is parseable mechanically. Custom logging targets are straightforward to add.
The iptables performance is sufficient for most deployments. Not as good as dedicated hardware, but for the typical small-to-medium business that does not push gigabit, it is more than enough. The cost-performance tradeoff favours iptables on commodity hardware below a certain scale.
The iptables configuration is text. Version-controllable, reviewable, easily reproducible. PIX configurations are also text, but the format is Cisco-specific and the tooling around it is correspondingly less rich.
What this means for new deployments
My general recommendation, after the fortnight, has shifted slightly:
For organisations that need gigabit-plus throughput, PIX is the right choice. The dedicated hardware genuinely outperforms commodity-Linux alternatives at high traffic levels.
For organisations that need commercial support contracts, PIX is the right choice. The Cisco support relationship is a real value proposition for organisations that need someone to call when things go wrong.
For everyone else, the commodity Linux firewall on netfilter is genuinely competitive. The open-source stack is at the point where it is operationally credible. The cost is roughly an order of magnitude lower. The audit trail is better.
My friend's organisation is going to keep their PIX (the migration cost is not justified). Their next firewall, when the existing one comes up for replacement, is going to be a netfilter-based commodity Linux box. The decision will save them about £30,000 a year on licensing and hardware refresh.
A small note on my own infrastructure
I run OpenBSD for my home perimeter, with pf rather than netfilter. The pf configuration is similar in spirit to iptables but with notably better syntax, in my view. The OpenBSD perimeter has been running without incident for over a year.
I am not going to change it. The PIX experience has confirmed for me that, for my scale of deployment, the OpenBSD/pf combination is the right answer. The choice of which open-source firewall is a smaller decision than the choice of whether to use one.
More on the year as it develops. The next post is going to be a midyear reflection — six months in, what is happening, what has surprised me, what to do next.