Manageability problems

Our woes with Network and Security Manager began when we tried to use it to manage the SRX 5800. With eight years of experience using NSM in Opus One's labs, we were looking forward to the unification of JunOS and ScreenOS management. We started out needing to change IP addresses, a common enough task. For a ScreenOS system, this takes three clicks: two clicks to see a summary interfaces and IP addresses, and third to begin editing.

The SRX 5800 was not so simple. It's impossible to get something as simple as a list of interfaces and their IP addresses. You have to find the physical interface, and then click through a series of submenus just to find out what the IP address is -- nine of them. And if you know the IP address but can't remember which port it's connected to, you might as well give up and use the command line to figure it out, since NSM would make you click through eight levels of menus just to see each IP address.

Where NSM does excel is in security policy definition. We were relieved to see that the normal NSM tools for creating and editing policy could be applied to the SRX 5800 – that is, until we tried to turn on network address translation (NAT). Now, you can turn on NAT in the security policy and push that policy with NSM, but it doesn't actually do anything on the firewall. No error message, no warning and no NAT neither. We only discovered NAT wasn't working when we started doing packet dumps to debug a different problem.

The SRX 5800 does support NAT, but you have to go back to the nine-levels-deep style of configuration. The experience is about as pleasant as poking values into an SNMP-managed switch by hand — and, of course, about as error-prone and difficult to document. We ended up using shortcuts provided by Juniper's engineers, putting the NAT configuration in using the JunOS command line, and then re-importing the device into NSM.

We then tried to create an intrusion-prevention system (IPS) policy, and ran into another problem in NSM: inconsistent databases. We selected Juniper's "Recommended" security policy and tried to push it to the SRX 5800. Immediately, NSM threw back errors — the SRX 5800 had a different set of policy elements than NSM thought. We had to go through the policy by hand and re-craft it so that the signatures missing from the SRX 5800 were not being selected in order to get a clean policy download.

The final nail in NSM's coffin, at least for this version, came when we wondered how well the IPS was working. In a normal ScreenOS deployment, there is a nicely designed workflow which feeds back information from the IPS into the NSM console. This lets the security manager see how the IPS is performing, and then immediately and easily make policy changes. With the SRX 5800, this workflow is broken: security alerts cannot be sent to NSM.

Instead, Juniper told us that we should send security alerts to a SYSLOG server (something else which no wretched mortal could configure in NSM). We found that answer unacceptable: When the alerts are sent to a SYSLOG server other than NSM, the workflow process is broken, and managing the IPS policy and interpreting its results becomes an impossible task. Centralized logging has to be coordinated with NSM, especially in the area of intrusion prevention. In the past, we've lauded Juniper for the value that NSM brings to an IPS deployment. With the SRX 5800, Juniper takes a giant leap backward in IPS management.