Sidewinder vs Netscreen as layer 3 firewall only.

Hi,

I'm trying to compare the performance of a Netscreen ISG1000/2000 firewall and a Secure Computing Sidewinder 1100C **as a layer 3 packet inspector** rather than an application proxy ?

Regarding the Sidewinder, it might sound unusual to you that we may buy a firewall which is mainly sold as an application proxy / layer seven filtering device, in order to do stateful inspection, but one of our suppliers is trying to push them to us as the perfect firewall for our needs.

This is what we are looking for.. (this will look terrible on google if you don't use a fixed width font..)

internet | cisco 2821s | | firewall | | | +----+ redline | reverse | proxy internal | app servers/dbs | webservers

This is easy to visualise on the Netscreen firewall (3 security zones) and the Sidewinder (3 burbs) so as far as I can see, there's no logical reason why this would not work on both platforms.

The main differences I can see are :

• the Netscreen would give us IDS reports straight away, as soon as we buy the ids blade. * The Netscreen performance suffers, I am told, when IDS reporting is turned on (this might not be the case at all. :-) ) * the Sidewinder 1100C is much cheaper * the Sidewinder has a comfortable unix-style shell interface * The peer support community for Netscreen is 'probably' larger.

We simply do not want or need the application proxy stuff, so that's not an advantage, or ISP of the Sidewinder in this case.

How do the firewalls compare in this circumstance, please ?

[Michael Pelletier wrote in comp.security.firewalls]

Indeed. The Redlines we have act as an application firewall (even though that's not strictly their intended purpose.)

Which is why we don't want to duplicate the work by having a Sidewinder perform the same role. Especially as Secure Computing tell us that turning it off will give us the throughput performance we need..

Cheers

-a

I have never heard of a performance degredation regarding reporting. Reporting is handled by the management server which you'll have to implement for said reporting. On the ISG, you cannot install the management server on the blade like you can currently for the IDP

10/100/1000, and like always management is out of band. The management server runs on Linux or Solaris so if working in a shell is a requirement, then you can still have that option for the management server, but there is no shell on the IDP that is accessible. That's just the way it is.

Getting into the ISG would be a good idea in my opinion. You get the ScreenOS for stateful inspection and then with IDP blade, the ScreenOS makes calls to the blade inspecting traffic. Then, if you invest in NSM, when the new version is released management will be taken care of for both IDP and ScreenOS within NSM (which makes the management server well utilized).

Not that it matters much, but maybe you could play your cards a bit stronger, since you already have made the investment into Redline, you can tell Juniper or you reseller to give you a heavier discount. With the acquisition, I'm sure they will be interested in retaining your business. And another thought, you can bet they'll be rolling up the Redline into a blade, so that would be sweet as well.

I should actually correct myself. The IDP sensor and the IDP management server both have shell access to it. After I posted I thought about it and I was wrong.

Word.