The GUI management for the NetScreen-500 was done via a Web browser. The advantage of this is that management can be done from any client OS that has a Web client. SSL is used to protect the data and passwords. The disadvantage is that this setup offered no centralized control. For example, we couldn't save backup configurations, as we did with Lucent's LSMS. This is important because when you make changes to a firewall, it's helpful to have a good trail and to be able to revert back in case the changes cause problems. In addition, if you wind up managing multiple firewalls, a Web GUI won't be of much use because it can deal with only one firewall at a time. If you have only a few, however, this won't be as much of an issue.
The NetScreen-500 included a CLI, which we found ourselves resorting to often because there we could clearly see the configuration all laid out. Also, there are some tasks that can be done on the CLI only. NetScreen did claim that it has a better management product in the works but was unable to get it to us in time.
The virtual firewalls on the NetScreen were called "virtual systems." By "entering" one virtual system, changes to the policy could be made in such a manner as to clearly impact only that virtual system and its associated VLAN. Changes could be made via the Web interface as well as at the CLI. This feature definitely makes administering multiple firewall policies for multiple customers a manageable task. As on the Brick, administrators could be set up with multiple levels of access. This means that customers could change their policies and not hurt anyone else's, although this privilege should be dispensed carefully. A better solution might be to let customers view policies but not change them. This will head off some help desk calls, when there are questions about filtering rules, while also avoiding the nightmare that would arise if someone messed up the rules.
Things That Made Us Say Hmmm
Virtual systems could be set up only when the firewall was doing routing or NAT. They could not be set up when in bridging or transparent mode. NetScreen had no explanation for why this is, and the Lucent product did not have this limitation. It was also difficult at times to tell if the NetScreen-500 was running in transparent mode. For example, adding an IP address to one of the interfaces would turn off transparent mode and bump us into either routing or NAT (network address translation) mode. Changing all the IP addresses to 0.0.0.0 changed the device back into transparent mode. When this was done, the option to add virtual systems simply disappeared. There were other times when we made a change to the configuration from the Web interface and then were unable to get back in via the Web interface, even though we did not change the policy or address of the management interface that had been providing us access.
Setting up and maintaining redundant firewalls was a lot more difficult with the NetScreen-500s than with Lucent's Bricks. We had to configure each device separately, save the "master" configuration to the "slave," and then reset the slave in order to make this work. We also found we had to manually perform this process every time a change was made to the configuration. The Lucent product automated this process for us, as we would expect a collocation-class firewall device to do.
The 500's screen for adding rules was laid out in an easy-to-understand tabular format, like Lucent's, but it didn't offer nearly as many editing capabilities. Rules could be temporarily disabled, as with the Lucent Brick, but there was no way to insert rules or reorder existing rules.
Logs were viewable via the Web interface as well, but our tests didn't find that very useful as it presented a flat view of the most recent entries, with no ability to sort or filter them. Entries could be offloaded to a syslog to a syslog server, and logs were compatible with WebTrends' Firewall Suite software. You will have to employ some third-party or in-house software to crunch through the syslog files if you want to get any meaningful data from the logs.
NetScreen, like the Brick, took about 3 seconds to hand off control from one firewall to another when set up in high-availability mode. NetScreen was also comparable to the Brick in its ability to handle TCP connections, with both appliances handling more than 200,000 connections.
NetScreen-500, Price: See //refer to features chart//, NetScreen Technologies, (408) 730-6000, (800) 638-8296; fax: (408) 730-6100. www.netscreen.com
Peter Morrissey is a full-time faculty member of Syracuse University's School of Information Studies and a contributing editor and columnist for Network Computing. Send your comments on this article to him at ppmorris@syr.edu.
|
Vendor Resources
Customer Profiles
White Papers
Certification
|