Informal Comparison of Cisco Pix vs Sonicwall Pro

This is a largely off-the-cuff response I sent once to someone who requested a comparison of the Sonicwall Pro firewalls that I had been using previously to the Cisco Pix firewalls that they were replaced with. It has been cleansed of any personal details.

This is a pretty complex question, and I don't know if Sonicwall has gotten around to fixing most of my problems that we had with our previous units. (Sonicwall Pro, circa 2000ish vs Cisco Pix, circa 2004 - Ed)

and so...

Before we did the upgrade cycle, we had these problems (among others)...

• Aging hardware was beginning to fail. We would have lots and lots of unprovable mysterious problems that were internal to the Sonicwalls (for instance, we had one IP address at one site that refused to work, despite there being no reference to it anywhere in any of the configuration screens anywhere in the sonicwall. Some were also starting to just get toasted... losing the ability of the flash memory to hold configuration changes and such). These were Sonicwalls that were (at max) about three years old.
• Lack of capacity in the rule sets. I ran into this first at the site which had the most complicated rules... the sonicwall model we had was limited to 100 rules in its policy. Ran into this really hard when we started to do egress filtering on the server network... There just weren't enough rules to properly define the limits on the traffic that we needed. On the Pix, on the other hand, the amount of entries you can have in an access list is only determined by cpu/memory concerns, and if you do a 'access list compiled' statement, it makes any access list longer than 18 (I think) entries just as efficient speed-wise as an 18 entry list. It pre-hashes and takes up a bit of memory is all.
• Lack of capacity in the connections table. I think the Sonicwalls that we had topped out at 4096? (or some similar power of two -Ed) simultaneous connections. So we would get a virus or something that constantly create outgoing connections that would very quickly (within a matter of minutes) use up the entire outgoing capacity and drop the site off of the map. This was regardless of there not being enough bandwidth for this to really happen effectively, since the Sonicwall was on the 100 mbit end of things. This was coupled with:
• Extreme lack of debugging information. With the old Sonicwalls, there was no method to actually see what those 4096 connections were. If it had been able to tell me that 192.168.x.y or whatever had been the local IP address for 4000 of those connections, I'd have been able to immediately turn around and pinpoint the troublemaker. As it was, I would have to truck out there, configure Ethereal on a laptop and try and figure out who the talkers were. (The alternative was the very scientific... turn things off/on one at a time to see when the problem starts, but that stops working very quickly once you have more than one infected machine). "Slow leaks" were almost impossible to track down (I had one that would increase by 1-2 connections every few minutes, slowly but inexorably. That turned out to be a Dell updating program trying to call home to a server that didn't exist, but the connection not being torn down properly. With the Pixes on the other hand, you type "show conn" and get something like this:

pix# show conn
827 in use, 2215 most used
TCP out x.y.z.v:80 in server:34731 idle 0:00:43 Bytes 124113 flags UIO
TCP out d.f.g.h :80 in server:58942 idle 0:00:09 Bytes 2322367 flags UIO
TCP out h.j.k.l:80 in server:60959 idle 0:04:39 Bytes 2754 flags UfFRIO

.... and so on for 850 lines in this case. There is a similar amount of transparency for just about any other internal metric that you want to look at.

I don't know the exact numbers of connections the different Pixes support offhand, but its at least in the hundreds of thousands.

The Sonicwalls were also hard to manage. I have a bias in that I greatly prefer the command line for a lot of these things, but some of these benefits are true even for command-line-phobic people. Inside of the sonicwall, there was always a lot of clicking back and forth, checking this screen or that screen and only ever getting sanitized user-friendly data. On the pix, I can use grep to look for settings, I can print out the whole config file to a tftp server in plain text so I can read through it (the sonicwalls config file was binary, I believe)... I can easily compare different versions of the config for a site to see what is changed, I can easily compare one site to another... all kinds of nice simple things like that. (The Pix *does* have a web GUI interface as well, but in my opinion it is worthless and cannot recommend its use at all. It is just as obtuse as the command line, so it isn't good for command-line-phobes, and doesn't give you any benefit (other than filling your config file with extraneous web-gui-only metadata).

The plain-text console also makes it very easy to cut and paste bits of config from one device to another, or to automate some things. For instance, I have a script that does a 'show conn' for me, then collates and groups the data (so you have lines like..... "tcp port 80 : 345 connections" rather than one line for each connection, which is very handy sometimes). (Here is the script' - Ed)

I'm also doing a lot of SNMP for graphing of various things in the Pixes. I'm not sure what the Sonicwalls supported in that regard though.

This might also be a particular model problem, but the Sonicwalls we had previously always had tons and tons of errors on the interfaces. It was so bad that we actually had a baby switch between our firewalls and (The ISP's) equipment. With the Pixes, all those errors went away.

Of course, my needs are likely to be very different than yours. I have several dozen sites spread out all over to support, so a lot of the standardization and ease-of-comparison features really stand out for me, where they probably wouldn't be as valid in your environment. The Pixes are significantly more complex to admin than the Sonicwalls were... you have to know what you are doing. This is a plus in my book (especially since it discourages meddling, which is sometimes common with web GUI's), but training is a significant issue that I don't want to gloss over. The Pixes definitely have a learning curve to them. However, lots of the problems that would take days to figure out are resolved almost immediately now.

But then again, I haven't worked with a recent Sonicwall.