of the PIX
is Brantley Coile and in 1994 I co-founded,
with John Mayes, Network
Translation, Inc, to produce and market
our new creation: The PIX Firewall. We
sold the company to Cisco in 1995, and soon after I was no longer involved with
the day-to-day support of the PIX, but most of what you see in the PIX today,
A few weeks ago I bought a
copy of your excellent book. It is very nice to again see names that I created,
like PIX (Private Internet
eXchange, a play on Private Branch eXchange) and Finesse (Fast INternEt
a real thrill in knowing that people are still finding my work useful.
I would recommend your
excellent book to everyone who has a PIX. Great work.
And Now the History Lesson From
1990 John Mayes and I worked together to embed Unix into the Adaptive
STM18 DS3/DS1 intelligent MUX. He had
worked for NET, Adaptive's parent company, setting up the company's development network and was looking forward to getting into development himself. We really liked each
other and worked closely together.
1992 we had both left to pursue our own dreams.
I moved back home to Athens, GA and he was fast becoming the most sought after
systems admin consultant in the bay area.
About 1993 we had both hit a wall; he was working 19 hours a day and
falling behind, and I was finding the Atlanta market far behind CA in it's acceptance of consultants. We both, independently reached the conclusion that we must have
a product to sell other than simply ourselves.
the spring of 1994, John asked if I could solve a problem for one of his
customers: years before when the customer had installed Sun Systems they made
up their own IP addresses for their networks. They
never dreamed of being connected to the public.
Now they wanted to be on the Internet. I didn't see
why they couldn't if I changed the IP addresses on the fly using some sort of
appliance and fix up the checksums in the headers.
first this was going to be a program running under SunOS. I thought better of that and then it was going to be run under
BSDI. The more I thought about it the more it seemed to me to be unnecessary. The job just didn't need timesharing; it was
more like a router really. I decided to
write the code directly on commodity
was working on consulting contracts, so it took me a while to get serious about it.
I started pulling things together in the late summer. The actual coding wasn't the big effort. Keeping myself from
going off on a tangent was hard.
checked the RFC index as usual but couldn't find any reference to what I was
trying to do. There was an entry
reserved for RFC 1631 but it didn't show a title or any other information. Late in 1994 someone told me that there was
already an RFC about something called NAT.
I found a copy and was pretty excited. We
both had done almost the exact same things, run into the same problems and come
up with similar solutions. Theirs wasn't
concerned with security, so our PIX was truly new in
that respect. But it makes the solitary
programmer feel not quite as alone to see that someone else has also been in
the same mental space.
suggested the name PIX to explain how you could have more internal hosts than
public IP addresses. The global
addresses were like trunk lines and the local addresses were like
extensions. The analogy to the PBX
seemed obvious. John was torn until he
used it to explain what our box did for a group of lawyers. He called back saying the name worked
great! It was the PIX from then on!
In November 1994, we beta'ed at KLA instruments without a single
bug. (There were some, but
we found them before the customer did.) The PIX was one of Communications
Magazine's products of the year.
earliest PIX had the core features of today: adaptive security,
global address pool, static xlates, TCP/UDP fixups. It became
obvious that the PIX was also a firewall. The data structures that are required to do
NAT were perfect to implement what I called a connection diode. Next I added VPN with the private link. Just after we were purchased by Cisco I came
up with the idea of UnProxy--what is now called
failover scheme occurred to me during the beta test of the other Cisco product John and I did, the LocalDirector. The
customer would not put the LocalDirector in line with
their web servers for fear a failed LocalDirector
would take their site down. I had to
think of a way to do failover and get it to them in a very short time. Custom hardware was out of the question, and
that was the only way I had ever done failover.
So, I looked at what was left unused on the equipment and saw the extra
serial interface. The active could
reassure the standby by sending short messages over the serial cable. But how would it know if the other machine
had failed, or was just unplugged? The Cable I came up with worked and was
installed at the beta site in the next day or two. So, I now have a patent on a cable!
1995 we hired Rebecca Jepsen as VP of marketing and sales really started to grow. By late in the year we had sold several
million dollars of PIX and John met the CTO of Cisco at a party. In December I happily found myself Cisco employee
6877. I stayed with Cisco for the
required two years and left to continue pursuing new challenges.
story I like to tell is about when the folks at SRI in Menlo Park wanted to evaluate the PIX along with lots of other
firewalls. We packed them up a PIX and had it sent over. A few days later they called and asked what
were we going to do with this particular box when they were finished? We couldn't sell it now, could we? Might it be possible for them to keep
it? I asked what for? They said they wanted to use it as their
firewall. Can't get a better eval than that!
thrills me to see the PIX still kicking.
It was designed to do one thing well.
While it doesn't run on Unix, it is really the
Unix philosophy applied to the task. It
was meant to run as close to wire speeds as possible. It didn't have great numbers of settings. It was meant
to be easy to install (4 commands on the original), not require attention, and
just do it's job, quietly and effectively.
It was also meant to have a very simple policy model that was easy to
understand. How can one feel secure when the basic model is complicated. How can anyone feel secure behind a firewall
made from Unix or windows?
ran one of the original PIX here in my Athens, GA lab until last year.
The PIX didn't have PAT until late.
My version never had it. When my service provider said they could no
longer support my full class C network I had to replace the PIX with some new code I
wrote that just does PAT. I call it
NIX. PIX does NAT, NIX does PAT. NIX is not a product, it's just for me.
left lots of stuff out of this. I'm
working on a new storage product, like everyone else it seems. Still I don't worry. There were firewalls before the PIX. Just not ones like the PIX.