[c-nsp] Telnet FROM a PIX Appliance?

C. Jon Larsen jlarsen at richweb.com
Fri Jul 4 10:29:47 EDT 2008


Ted,

Peder is correct. Cisco bought the company that made the pix (NTI) because 
NTI was one of the first companies to have a decent working NAT overload
implementation. NAT was a big deal back then - around 1995/1996 and Cisco 
routers did not have NAT in the IOS until 11.2 I think. At that 
time UUnet and many other SPs were tossing out a full /24 for every t1, 
but the smaller ISDN and frac t1 based connections started coming with much 
smaller allocations, and PAT was something everyone (small customers) 
started wanting badly. There was a smattering of non cisco boxes that 
could do a little nat, but customers wanted  solid state hardware that was 
easy to configure or at least flexible enough to be able to configure for a 
variety of wan service offerings - smds, atm, frame, isdn, x.25 was still 
here and there, and on the lan side decnet, ipx/spx, netbeui etc were 
still in play.

Cisco, Proteon and Wellfleet and 3com to a lesser extent 
were the big router players but none of them were addressing the 
emerging NAT market very well.

NTI was a small company with good engineers that wrote a 
custom kernel that did what few others were doing. I saw a few customers 
that actually bought the NTI box or were going to buy the box BEFORE cisco 
bought NTI. When Cisco bought NTI and threw their marketing behind the 
PIX, and started pushing it to resellers, it took off because it was a 
good box that fit a niche market very well. In fact the original NTI boxes 
were again more of a nat box that a firewall. When you installed a pix you set 
the screening router (a cisco of course) up as the dmz firewall with its 
acl capability to protect the dmz hosts and the pix had the outbound nat 
config and the conduits for the inbound flow to the inside network. The 
original pixes were pretty limited as a firewall and of course had no 
capability for a 3rd or 4th interface. They were strictly used for the 
corporate/inside network interface/connect point.

Customers bought PIXes at that time because they were easier than having 
to figure out how to setup a linux or Sun bastion host / proxy toolkit or 
fiddle with ipmasq for most companies that did not have in house un*x 
talent. Customers were running out of IPs to number their PCs (and MACs 
- remember the need to browse the internet killed appletalk and localtalk) 
that and the ISPs were not handing them out (/24s) like candy anymore.

As far as firewall feature set on a router goes ... I had to laugh. I have 
always considered that somewhat fiddly / buggy. Good way to make a solid 
product (a cisco router) into something that needs more attention and is 
slightly less reliable - especially when implemented on low end hardware 
like 800s, or 16xx, or 17xx, 2610s, etc. I have seen at least 3 or 4 fw 
feature set implementations on routers that were backwards - i.e. 
inspecting traffic in the wrong direction. There is also at least one 
config for the fwfs on cisco.com's website that has it backwards too that 
I ran across.

As far as cisco discontinuing the pix ?? Thats plain wrong. The PIX 
lives on, it just has a new name (ASA) so cisco can move upmarket 
and charge more for the same code base :)

Of course the cpus are much faster in the ASA boxes, and it has a more 
extensible/modular hardware architecture than the pix and you can plug in 
the IDS/IPS modules, etc. The ASA boxes usually have a celeron cpu in the 
2Ghz range whereas the pixes started of as 486 dx2 66MHz chips (yes 
really, with like 4MB or maybe 8MB of main DRAM) and worked their way up 
to 300 or 400Mhz PII chips in the beefier models.

Cisco has no interest in migrating any customers from PIX/ASA to routers. 
They want to sell you BOTH and a few Cat switches while they are at it :)

And finally, Peder is correct again about the Centri. Centri was a flaming 
pile of junk. It ran on windows nt server (workstation was also 
supported I'm pretty sure).

Of course it was terrible (the centri) - windows nt was a terrible product 
that never really did get stable enough for use as a reliable pc server 
much less as a critical piece of network gear. Centri did have some 
really "impressive" guis tools for managing firewall configs. At that 
time the pix was popular but hard to configure for end customers who 
typically have net admins on staff and not network engrs (times 
really have not changed have they :). Customers wanted to manage their 
own boxes and not have to call an integrator every time an acl needed a 
tweak. Thus the pretty gui of the cenrti appealed (in theory). I never saw 
one get sold and work though. Couple of demo/evals, and it usually died 
there in the sales process :)

It would have been near impossible for anyone to build a firewall based 
on windows 3.1 technology. Windows 3.1 did not have a true kernel or built 
in (native) tcp stack. Remember Chameleon anyone ? trumpet winsock ? 
Those DOS TSR-based "tcp mini kernels" as they were called were so 
unstable that a windows 3.1 or 3.11 based firewall would have keeled over 
the minute it saw real use. Those stacks were barely functional as a 
client, much less a server or firewall.

I dont remember any vendors coming out with windows based "firewalls" 
until win nt 4.0. Windows in all its versions just was not stable enough 
until then and recall that Windows 3.5 and up are not the same product at 
all as win 3.1. Win 3.1 was 16bit dos with a gui command shell and a 
gui api. Win 3.5.x and up was Cutler's 32bit rewrite of VAX and 
Microsofts first true operating system :)

No way would cisco have purchased or built or sold or recommended 
to clients anything based on win3.1 other than maybe a terminal emulator 
to attach to a cisco serial console :)

I remember a customer that badly wanted to migrate off of netware to 
"save" licensing $$. Remember this was before CALs and such and windows 
3.5.1 was almost free as a network server. They had to boot the 3.5.1 
server every nite so it would not crash the next day. The netware 
3.12 server had been up for like 3-4 years at a time :)



On Fri, 4 Jul 2008, Peder @ NetworkOblivion wrote:

> What!?  The original PIX code was < 500k as the first versions from Network 
> Translations only had 512k flash moodules in them.  There is no way that it 
> was based on Windows, not even 3.1.  I think you are thinking of the Centri 
> (or whatever it was called) that was windows based that they bought many 
> years ago.  I actually worked at Cisco when they bought the PIX and the 
> Centri and then they killed the Centri shortly thereafter.  I think the 
> Centri ran on Windows 95, but I am not 100% sure as that was 10+ years ago.
>
> IMO, the reason that so many people use(d) the PIX is that they just work. 
> You set it up and forget it for two years.  You rarely even need to update 
> the software on it as there are so few bugs that are show stoppers.  Now, the 
> ASA is a different story.  There is a lot more stuff in it and hence a lot 
> more bugs.
>
> Ted Mittelstaedt wrote:
>> Rubbish.
>> 
>> The reason the PIX doesen't allow Telnet is that the original
>> PIX devices were built on a Windows core, Windows 3.1 as I
>> believe, with the GUI and most of the command line utilities
>> stripped away.  Because the PIX was an early out-of-the-hole
>> firewall, it captured a customer base of customers who needed
>> a firewall but frankly didn't understand much about what they
>> needed.  ie: dumb bunnies in cash-rich organizations willing
>> to buy sub-par technology that was hyped up to rediculous
>> amounts.  It's an old story in technology.
>> 
>> This was a very valuable customer base which is why Cisco
>> purchased the PIX product line.  Cisco had little interest
>> in the lame firewalling technology of the PIX and has
>> spent at least a decade of careful work grooming the PIX
>> customers off PIXes and on to Cisco router platforms.  To
>> accomplish this they were -extraordinairly- careful to
>> preserve the PIX interface and limitations over the years.
>> But as anyone who works with PIXes knows, Cisco has really
>> not improved the basic technology of the PIX over the years.
>> 
>> That is why the current Cisco IOS-based firewalls have
>> a firewalling feature set that knocks a PIX into a cocked
>> hat.
>> 
>> It is also why Cisco has finally felt comfortable enough
>> that they have migrated the PIX customers worth keeping
>> over to their own product line, to announce that they were
>> discontinuing the PIX product line.  As they did recently.
>> 
>> Ted
>> 
>>> -----Original Message-----
>>> From: cisco-nsp-bounces at puck.nether.net
>>> [mailto:cisco-nsp-bounces at puck.nether.net]On Behalf Of Ziv Leyes
>>> Sent: Monday, June 30, 2008 5:31 AM
>>> To: Joerg Mayer; Aaron R
>>> Cc: cisco-nsp at puck.nether.net
>>> Subject: Re: [c-nsp] Telnet FROM a PIX Appliance?
>>> 
>>> 
>>> I guess it's more as a "working right" educational purpose, so you won't 
>>> use your firewall as a debugging client.
>>> In newer versions there's the packet tracker that can help you debug 
>>> connectivity problems.
>>> Ziv
>>> 
>>> 
>>> -----Original Message-----
>>> From: cisco-nsp-bounces at puck.nether.net 
>>> [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of Joerg Mayer
>>> Sent: Monday, June 30, 2008 2:21 PM
>>> To: Aaron R
>>> Cc: cisco-nsp at puck.nether.net
>>> Subject: Re: [c-nsp] Telnet FROM a PIX Appliance?
>>> 
>>> On Mon, Jun 30, 2008 at 06:30:59PM +0800, Aaron R wrote:
>>>> It is disabled as a security feature. I have also wanted to do 
>>> the same for
>>>> troubleshooting purposes.
>>> And why exactly is this a security feature? What is the *gain* in 
>>> security?
>>> 
>>>  Ciao
>>>   Joerg
>>> --
>>> Joerg Mayer                                           <jmayer at loplof.de>
>>> We are stuck with technology when what we really want is just stuff that
>>> works. Some say that should read Microsoft instead of technology.
>>> 
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>> 
>>> 
>>> 
>>> 
>>> 
>>> ******************************************************************
>>> ******************
>>> This footnote confirms that this email message has been scanned by
>>> PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
>>> viruses.
>>> ******************************************************************
>>> ******************
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>>   ******************************************************************
>>> ******************
>>> This footnote confirms that this email message has been scanned by
>>> PineApp Mail-SeCure for the presence of malicious code, vandals & computer 
>>> viruses.
>>> ******************************************************************
>>> ******************
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>> 
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>> 
> _______________________________________________
> cisco-nsp mailing list  cisco-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-nsp
> archive at http://puck.nether.net/pipermail/cisco-nsp/
>
>


More information about the cisco-nsp mailing list