Re: Want some examples why NSM is a piece of junk?

Actually, I couldn't care less what they add after I've seen Space SD. By the time NSM 2012.1 will be released, we will also see Space Security Design 12.1, which will be ready for prime time (well, 12.2 and 12.3 will be the real deal, but 12.1 looks very promising already). The only thing that really really bugs me about Space is the lack of logging. If anyone is interested in switching from NSM to Space in the future, you better also ask for STRM pricing.

Re: Want some examples why NSM is a piece of junk?

I had a chat with a product manager and he said they might add some lightweight logging but I shouldn't hold my breath - it's not officially on the roadmap for any 12.x release. He said logging is just too much stress and doesn't scale well if you think of the massive log amount that the SRX is available to produce. They are thinking of integrating with STRM somehow. That "single node" stuff is just odd. Typical Juniper.

Does anyone object if I split this thread to a new discussion? The topic is revolving around Security Design vs NSM (NSM comments can continue on the original thread, but customers might otherwise miss important Security Design discussion)

Re: Want some examples why NSM is a piece of junk?

I need a helping hand getting this installed. I am at home with a Mac OS X machine, with a choice of VMWare Fusion or Parallels Desktop. Neither support OVF file format of the virtual appliance version. I tried VMWare's ovftool to convert it, but that tool is throwing errors at me:

Virtual machine has 8192 megabytes of memory, which is outside the range of 4 to 3600 megabytes supported on the host. This may be a general limitation of the host software, or specific to the guest OS selected for the virtual machine.

My Mac has 32 GB of RAM so it must be the tool.

Any thoughts? Could I just use the image version of Space which is designated for USB stick installation on the physical hardware?

Re: Want some examples why NSM is a piece of junk?

The OVF file uses VMWare hardware version 4 (quite old). Could we use newer versions instead (thinking 8)? Also, there are no VMWare tools installed in the virtual machine as far as I can tell. Can we install them to enhance performance?

Re: Want some examples why NSM is a piece of junk?

My feedback so far on Security Design (and only that, I am not speaking about the whole Space platform) is this: It's a huge step forward. The interface is so much better than NSM. It's fast, it's easy, it's less complex, it's modern. It has a fantastic search engine built in (think Google for your address object, firewall rules etc.). People knowing other firewall management systems will feel right at home. It has some very nice features.

I immediately fell in love with the object merger, which finds duplicates and offers you to merge them into a single object. This is great for "housekeeping". I also like the fact that you can export and import objects in CSV format, which is great for bulk operations. Automatic device re-sync is another feature I noticed. If you enable that, it will automatically re-import devices that you have configured out-of-band (e.. through CLI). No more competing configs!

It's those little details that give you the impression that Juniper have done their homework.

Security Design has an option to import your NSM configuration. I tried it and it worked really good. Do a database export on NSM, import the resulting xdiff file into Space and voila, you have all your objects and firewall policies. Really well done.

The fact that the user interface is basically HTML doesn't feel like a drawback. The interface is quick, even on 500+ rule policies. I am not a web expert, but I guess they are using things like AJAX or HTML5. You do have right-click context menus everywhere. The only thing that is missing compared to a native GUI client is drag and drop support. Maybe that's coming at a later date, who knows (and it never really worked in NSM anyways).

Note that these observations were made in a lab and not in a production environment. I can't say much about actual device management, although the process of pushing firewall and NAT policies to devices seemed straight forward.

There are a couple of things that I am missing though:

Space does not have a logging module, which is a huge drawback in my eyes. People with high end SRXes are probably logging to STRM or something else anyways, but as usual, Juniper does not seem to have the small to mid-size business in mind who have limited ressources and need an integrated solution. In my eyes, that's something Juniper really needs to address. Sooner than later.

The other thing I didn't quite like was the fact that you can not manage "legacy" firewalls, e.g. ScreenOS (SSGs). There is a huge SSG install base out there and those devices are left in the dust. I really don't understand that move, given the fact that at least in Space 11.2 there was a ScreenOS adapter which let you manage those beloved "netscreens". I hope Juniper will allow this in future updates (the DMI schema repository in Space 12.1 still lists ScreenOS 6.3 so who knows....). ScreenOS support would also mean that migrations from ScreenOS to Junos could be made easier.

One other thing I believe needs improvement is device configuration outside of Security Design. If you open a device in Space you are basically presented with a raw XML tree of the device configuration. Not very intuitive and very tedious to work with. Need to change the IP address of 15 interfaces? You're in for a bad afternoon. That part basically looks the same as on NSM (although it is much faster in terms of interface resposivness).

Oh and one more little thing. It's really not important, but the design of Space looks a little dated in some areas. For example, you have dashboards wth widgets that you can drag around like windows. The window borders are blown up and use fat gradient colors. This could use some cleanup. Make the whole design less fat, flatten it. But again, this is just eye candy so it's not important.

All in all I can say I am very impressed so far and despite the lack of logging and ScreenOS support, Space SD is a huge step up compared to NSM. In it's current state (12.1) it already has the potential to completely replace NSM if you have a separate logging solution. In other words: I love it so far.

To Juniper: If you will offer some sort of upgrade path for NSM users in terms of "special pricing", I think you can win back a lot of customers. I think NSM users deserve to get an upgrade to Space as in free beer. *hint*.