Juniper NETWORK AND SECURITY MANAGER - S REV 3 Instruction Manual

Network and Security Manager Release
Notes
December 10, 2010
Revision 3
Contents VersionSummary....................................................3
NewFeatures.......................................................3
NeworChangedInformation...........................................3
BeforeYouInstallNSM...............................................3
Solaris Locales ..................................................3
Upgrade Considerations ..............................................3
UpgradingNSM..................................................3
DeprecatedOperatingSystem......................................4
Limitations .........................................................4
Important SSL VPN and Infranet Controller Instructions . . . . . . . . . . . . . . . . . . . . . 4
NSMServer.....................................................4
Setting Up NSM to Work with Infranet Controller and Infranet Enforcer . . . . . 6
Usage Guidelines for Applying NSM Templates to SA and IC Clusters . . . . . . . 8
Recommended ..............................................8
NotRecommended...........................................8
BestPractices.......................................................9
MaintainingtheNSMGUIServer....................................9
Creating a Self-Signed TLS Certificate Between the NSM Client and the
NSM Server .................................................9
AddressedIssues....................................................11
Release2010.3..................................................11
Release2010.2..................................................13
Release2010.1..................................................16
KnownIssues......................................................20
NSM..........................................................20
EXSeriesSwitches..............................................30
DevicesRunningScreenOSandIDP.................................31
Secure Access SSL VPN SA Series and United Access Control Infranet
Controllers .................................................32
SRXSeriesServicesGateways.....................................33
1Copyright © 2010, Juniper Networks, Inc.

Errata and Changes in Documentation for NSM Release 2010.3 . . . . . . . . . . . . . . 34
Errata.........................................................34
NSM Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
DocumentationFeedback............................................36
RequestingTechnicalSupport.........................................37
RevisionHistory....................................................39
Copyright © 2010, Juniper Networks, Inc.2
Network and Security Manager 2010.3 Release Notes

Version Summary
Juniper Networks Network and Security Manager (NSM) is a software application that
centralizes control and management of your Juniper Networks devices. With NSM, Juniper
Networks delivers integrated, policy-based security and network management for all
security devices and other Juniper Networks devices in your networks. NSM uses the
technology developed for Juniper Networks ScreenOS to enable and simplify management
support for previous and current versions of ScreenOS and now for Junos operating
system (Junos OS). By integrating management of all Juniper Networks devices, NSM
enhances the overall security and manageability of the Internet gateway.
New Features
The new feature in this release of NSM is support for configuring NAT on devices that
run on the Junos OS.
New or Changed Information
The following provides the new or changed information for this release:
•NSM supports management of SRX Series devices in packet and mixed mode.
•The wireless encryption configuration field, Static WEP (config > wlan > access point
> radio > virtual access point > security) has been renamed to Wireless Encryption.
•The Comment column of the firewall policy has been moved from the last position to
the third position from the last.
Before You Install NSM
Solaris Locales
Before installing NSM on a Solaris server, you must install a specific set of locales, and
make appropriate edits to the /etc/default/init file. For more information, see the Network
and Security Manager Installation Guide.
Upgrade Considerations
This section contains information about upgrading NSM and deprecated operating
systems.
Upgrading NSM
You can upgrade to NSM 2010.3 from the following versions:
•2008.2RX
•2009.1RX
•2010.1
•2010.2
3Copyright © 2010, Juniper Networks, Inc.
Version Summary

NSM 2010.3 supports:
•3000 low-end devices with 10 user connections
•300 high-end devices with 25 user connections
Deprecated Operating System
NSM no longer supports ScreenOS version 4.X. You must upgrade your devices to
ScreenOS version 5.0 or later. NSM no longer supports Junos OS Release 9.2 or lower.
Limitations
The following items are known limitations in this version of NSM:
•NSM does not support Junos OS downgrades. However, if you need to downgrade a
device, follow these steps:
1. From the device, use the CLI command to downgrade the image. For example:
root> request system software add <package-name> reboot
2. After the downgrade, from NSM, delete the device and then add it again.
•For Junos OS J Series and EX Series devices—NSM Configuration Editor cannot
completely validate the configuration that an NSM user has created before sending it
to the device. The device validates the configuration when the configuration is pushed
to the device as part of the Update Device job and may return validation errors to NSM.
•For SSL VPN SA and Infranet Controllers—Secure Virtual Workspace (SVW) settings
on the SA device cannot be managed with NSM.
•For EX Series switches—EX Series switches running Junos OS do not support snapshots.
Therefore, users should not select the “Backup the current filesystem(s) on the device”
check box in the final page of the Install Device Software wizard.
Important SSL VPN and Infranet Controller Instructions
This section contains setup instructions and template usage guidelines for SSL VPN SA
(SA) and Infranet Controller (IC) devices.
NSM Server
•There is no limit to the number of devices that can be simultaneously updated in NSM,
provided the configuration size on each device being updated is less than 5 MB. NSM
can execute updates in parallel across a maximum of eight devices while the remaining
update jobs are queued up.
•If the software version of SA/IC configurations exceeds 5 MB, we recommend a
maximum of four devices per job for an appropriately sized Linux or Solaris server
running NSM.
Copyright © 2010, Juniper Networks, Inc.4
Network and Security Manager 2010.3 Release Notes

•Due to hardware limitations on NSMXpress, the recommended limit is two devices per
job for SA/ICs running configurations more than 5 MB.
•The following files on the NSM software server must be edited as described below (no
changes are needed for NSMXpress):
•In /usr/netscreen/GuiSvr/bin/.guiSvrDirectiveHandler, change Xmx10248000000
to Xmx2048000000:
$LIB_DIR/jre/bin/java -DNSROOT=$NSROOT
-DgproGDM=$DEST_DIR -DNSDIR=$DEST_DIR/var/be
-DSTART_PATH=$DEST_DIR -DBE_CFG=${CFG_FILE}
-DLOG4J_CFG=${LOG4J_CFG_FILE} -XX:PermSize=64M
-XX:MaxPermSize=64M -Xms128000000 - Xmx2048000000
com.netscreen.devicecomm.GUIDirectiveManager -version -repo ${REPO_DEST_DIR}
-conf ${SVC_CFG_FILE}
•In /usr/netscreen/GuiSvr/var/xdb/data/DB_CONFIG, change the set_cachesize
parameter from 0 256000000 1 to 0 1024000000 4.
•Set the shared memory to a minimum of 1 GB (kernel.shmmax = 1073741824):
•In /etc/sysctl.conf, for Linux systems
•In /etc/system, for Solarix systems
•In /usr/netscreen/GuiSvr/var/xdb/specs/jax.spec, change Xmx512 to Xmx1024m:
:jvm-options (
: ("-DEMBEDDED_JVM=true")
: ("-Xms128m")
: ("-Xmx1024m")
•In /usr/netscreen/DevSvr/bin/.devSvrDirectiveHandler, change Xmx1024000000
to Xmx2048000000:
$LIB_DIR/jre/bin/java -DNSROOT=$NSROOT -DgproDDM=$DEST_DIR
-DNSDIR=$DEST_DIR/var/be -DSTART_PATH=$DEST_DIR
-DBE_CFG=${CFG_FILE} -DLOG4J_CFG=${LOG4J_CFG_FILE}
-XX:PermSize=64M -XX:MaxPermSize=64M -Xms128000000 - Xmx2048000000
com.netscreen.devicecomm.DeviceDirectiveManager -version -repo ${REPO_DEST_DIR}
-conf ${SVC_CFG_FILE}
The servers must be restarted after you change these parameters.
5Copyright © 2010, Juniper Networks, Inc.
Important SSL VPN and Infranet Controller Instructions

Setting Up NSM to Work with Infranet Controller and Infranet Enforcer
A ScreenOS firewall that is managed by NSM can also be configured as an Infranet
Enforcer in a UAC solution. To prevent conflicts between NSM and the Infranet Controller,
configure these firewall devices:
1. On the Infranet Controller, create the Infranet Enforcer instances:
a. On the Infranet Controller, select UAC > Infranet Enforcer > Connection.
b. Click New Enforcer.
c. Enter the information requested in the display.
d. Enter a password for the NACN password. You will use it again while setting up
the Infranet Enforcer. If you are setting up a cluster instead of a single box, enter
all the serial numbers in the cluster, one per line.
e. Click Save Changes.
f. Repeat Step 1b through Step 1e until all of your Infranet Enforcers have been entered.
2. If you do not have one already, create a CA certificate for each Infranet Enforcer:
a. Create a certificate signing request (CSR) for an Infranet Controller server certificate,
and use the CA certificate to sign the server certificate.
b. Import the server certificate into the Infranet Controller.
c. Import the CA certificate into the Infranet Enforcer.
3. On each Infranet Enforcer, create the Infranet Controller instance:
a. On the Infranet Enforcer, select Configuration > Infranet Auth > Controllers.
b. Click New.
c. Enter the parameters as prompted. The password in the second section must be
the NACN password you entered in Step 1.d.
d. Click OK.
e. Repeat Step 3b through Step 3d for all of the Infranet Enforcers.
f. On the Infranet Controller, select UAC > Infranet Enforcer > Connection and
check that all the Infranet Enforcers have been added.
4. On NSM, delete the Infranet Enforcer firewalls from the global domain:
a. In the global domain, select Device Manager > Devices to list all the devices.
b. Right-click each Infranet Enforcer firewall device and select Delete from the list.
5. On NSM, delete the $infranet instances from the Object Manager:
a. Select Object Manager > Authentication Servers.
Copyright © 2010, Juniper Networks, Inc.6
Network and Security Manager 2010.3 Release Notes

b. Right-click each $infranet_n object and select Delete from the list.
c. Select VPN Manager > VPNs, and check that you do not have any $infranet objects
under VPN Manager. These objects are usually deleted automatically when you
remove the firewall.
6. Create a new subdomain for the Infranet Enforcers:
a. Select Tools > Manage Administrators and Domains.
b. Select the Subdomains tab.
c. Click the Add icon.
d. In the New Subdomain dialog box, enter an appropriate name for the subdomain
so you know what it will be used for, and then click OK.
e. From the drop-down list at the top left side, select your new domain. The new
domain is empty, but it can use objects from the global domain. If you do not
remove the $infranet instances from the main domain, you risk having duplicate
$infranet names. In addition, add a Single Infranet Enforcer or Infranet Enforcer
Cluster.
f. Repeat Step 5 and Step 6 for every Infranet Enforcer or Infranet Enforcer Cluster
you need to add to NSM. When finished, you should see $infranet instead of
$infranet_# in each of the domains except global.
7. In NSM, add the Infranet Enforcer objects to the new domain:
a. Select Device Manager > Devices.
b. Click the Add icon, and then select Device to start the Add Device Wizard.
c. In the New Device window, provide a name for the device, a color for its icon in
NSM, and check Device is Reachable.
d. Follow the instructions in the wizard to add and import the device.
e. Repeat Step 7b through 7d for each Infranet Enforcer device.
You must reimport the configuration each time you use an Infranet Enforcer. Otherwise,
a NACN password mismatch is possible because the Infranet Controller dynamically
changes this password periodically. It is also good practice to do a “Summarize Delta
Config” and ensure that no $infra policies are present. If there are, the Infranet
Controller has changed something on the Infranet Enforcer since you last imported
the device configuration.
NOTE: If you choose not to reimport the configuration, be sure to update the
Infranet Controller and Infranet Enforcer at the same time.
7Copyright © 2010, Juniper Networks, Inc.
Important SSL VPN and Infranet Controller Instructions

Usage Guidelines for Applying NSM Templates to SA and IC Clusters
SA/IC cluster configuration data is composed of Cluster Global (CG), Node-Specific
(NS), and Node-Local (NL) data, which are abstracted in NSM as cluster objects and
cluster member objects. The cluster object contains only CG data, while the cluster
member object contains NS and NL data. Template promotion and application to clusters
should be compliant with the cluster abstraction.
Recommended
•Templates that are applied to cluster objects should only include CG data. Templates
that are applied to cluster member objects should only include NS/NL data. These
guidelines apply to templates that are created from scratch or through promotion.
•To replicate the configuration from one cluster (source) to another cluster (target)
through templates, promote the configuration from the source cluster object to a
cluster template, and then apply that template to the target cluster object.
•To replicate the configuration from one cluster member (source) to another cluster
member (target), promote the configuration from the source cluster member object
to a member template, and then apply that template to the target cluster member
object.
Not Recommended
•Do not apply any template that contains NS/NL data to a cluster object. Application
of a template that contains NS/NL data can result in unexpected UI behavior and
update results (such as, NS/NL data from the template being ignored or NS/NL data
in cluster objects is invisible).
•Do not apply any template promoted from a cluster object or a standalone device to
a cluster member object. Node-specific settings in the template appear in the member
object but do not appear in the delta configuration. As a result, these settings appear
in the template but are not pushed to the back-end cluster node.
The following list shows the NS and NL configuration settings. All other settings are CG.
Node-Specific (NS) Configuration:
<nsm:path>/ive-sa:configuration/system/log/snmp</nsm:path>
<nsm:path>/ive-sa:configuration/system/log/events-log-settin gs/syslog</nsm:path>
<nsm:path>/ive-sa:configuration/system/log
/user-access-log-settings/syslog</nsm:path>
<nsm:path>/ive-sa:configuration/system/log
/admin-access-logsettings/syslog</nsm:path>
<nsm:path>/ive-sa:configuration/system/log/sensors-log-settings/syslog</nsm:path>
<nsm:path>/ive-sa:configuration/system/network
/network-overview/settings</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/external-port</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/internal-port</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/management-port</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/vlans</nsm:path>
<nsm:path>/ive-sa:configuration/system/network/network-hosts</nsm:path>
Copyright © 2010, Juniper Networks, Inc.8
Network and Security Manager 2010.3 Release Notes

<nsm:path>/ive-sa:configuration/system/network
/network-connect/network-ip-filter</nsm:path>
<nsm:path>/ive-sa:configuration/system/clustering/properties/
configuration-settings/collection-of-network-settings</nsm:path>
<nsm:path>/ive-sa:configuration/users/resource-policies/network-connect-policies/
network-connect-node-specific-configuration</nsm:path>
<nsm:path>/ive-sa:configuration/authentication/auth-servers/collection-of-auth-server/
union-of-ace/active-directory-winnt/
settings/advanced/computer-names/ive-name</nsm:path>
Node-Local (NL) Configuration:
/ive-sa:configuration/system/configuration/dmi-agent/enabled
/ive-sa:configuration/system/configuration/dmi-agent/deviceid
/ive-sa:configuration/system/configuration/dmi-agent/hmac-key
/ive-sa:configuration/system/maintenance/push-config/acceptpush
Best Practices
This section contains information about recommended practices when using NSM.
Maintaining the NSM GUI Server
For optimal NSM server performance, follow these maintenance procedures every few
months.
On the NSM GUI client:
•Delete old entries from the Job Manager in each domain.
•Purge old database versions using Tool > Database Versions.
If the size of the NSM database in /usr/netscreen/GuiSvr/var/xdb continues to increase
considerably despite the recommended practices, you can manually remove all domain
versions using the procedure documented in KB11731. For details, see
http://kb.juniper.net/KB11731.
Creating a Self-Signed TLS Certificate Between the NSM Client and the NSM Server
A self-signed certificate is a certificate that has not been signed by a third party, such as,
a well-known Certificate Authority (CA).
To create a self-signed certificate between an NSM server and an NSM client:
1. Download the file CreateCerts.zip from
http://kb.juniper.net/library/CUSTOMERSERVICE/GLOBAL_JTAC/BK14949/C
reateCerts.zip
2. Copy the file to the NSM server and unzip it.
#unzip createCerts.zip
9Copyright © 2010, Juniper Networks, Inc.
Best Practices

3. Edit the file createCerts.sh and modify the section Default certificate generation
fields to update your current installation and the corresponding contact information
of your organization.
0.organizationName_default - <Name of Customer’s
Organization>stateOrProvinceName_default - <State>localityName_default -
<City>countryName_default - <Country>emailAddress_default - [e-mail]
4. Run the shell script #sh Createcerts.sh
NOTE: The script produces a certificate with a timestamp that is nearly
10 years beyond the current date.
The following is an example of the output when the script is executed:
root@nsm/]# sh createCerts.sh
Enter NSM installation path[/usr/netscreen]>
Generating RSA private key, 1024 bit long modulus
....................++++++
...........++++++
e is 65537 (0x10001)
Using configuration from cfg/openssl.cfg
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :PRINTABLE:'State'
localityName :PRINTABLE:'City'
organizationName :PRINTABLE:'Name of the Organization'
commonName :PRINTABLE:'NSM'
emailAddress :IA5STRING:'[e-mail]'
Certificate is to be certified until Aug 3 22:41:04 2019 GMT (3650 days)
Write out database with 1 new entries
Addressed Issues
Data Base Updated
Using configuration from cfg/openssl.cfg
Check that the request matches the signature
Signature ok
The Subject's Distinguished Name is as follows
countryName :PRINTABLE:'US'
stateOrProvinceName :PRINTABLE:'State'
localityName :PRINTABLE:'City'
organizationName :PRINTABLE:'Name of the Organization'
commonName :PRINTABLE:'NSM'
emailAddress :IA5STRING:'[e-mail]'
Certificate is to be certified until Aug 3 22:41:04 2019 GMT (3650 days)
Write out database with 1 new entries
Data Base Updated
Certificate was added to keystore
Copyright © 2010, Juniper Networks, Inc.10
Network and Security Manager 2010.3 Release Notes

Certificate was added to keystore
[root@nsm/]#
This step creates four files: root.pem,server.pem,truststore.ts, and keystore.ts.
NOTE: The files truststore.ts and keystore.ts consist of private keys and
must be protected.
5. On the NSM GUI server, copy the files root.pem and server.pem to
/usr/netscreen/GuiSvr/var/certDB/TrustedCA/
6. On the NSM client, copy the file trustedtore.ts and keystore.ts to
NSM_GUI_INSTALLATION/security directory. (The default directory is C:\Program
Files\Network & Security manager\security.) Note that this must be executed on all
systems where the client is installed.
7. Restart NSM GUI server services for a new certificate to be used:
#/etc/init.d/guiSvr restart
If using a high availability environment, execute: #/etc/init.d/haSvr restart.
Addressed Issues
This section includes issues addressed for NSM, ScreenOS, Secure Access SSL VPN SA
Series, Unified Access Control (UAC) Infranet Controllers, and SRX Series Services
Gateways. These release notes contain only NSM-related issues. For a complete list of
addressed issues for each device, see the release notes associated with the device.
Release 2010.3
This section describes the addressed issues in 2010.3:
•403809—Policies cannot be edited as NSM displays a locked by another user message
even though another user is not logged into NSM.
•407764—With NSM, the logs of a subdomain cannot be saved on the first try. The
workaround is to quit NSM and then try saving the logs again.
•413166—NSM displays an error when a MIP with an IP from a different subnet as the
interface IP is added on a firewall device.
•459994—In NSM 2007.3r5, DevServer Manager crashes when a PCAP retrieval operation
is performed on logs.
•465850—Uploading of the IDP 5.0 image fails in NSM after an upgrade from the
2008.2r1 to the 2008.2r2 release.
•477726—Using templates to activate an SSG5 device results in the creation of tunnel
interfaces with blank names. Because of this, the device cannot be updated.
•481066—SRX Series IDP severity level log information is displayed incorrectly in the
NSM Log Viewer.
11Copyright © 2010, Juniper Networks, Inc.
Addressed Issues

•482421—The BGP neighbor configuration in a ScreenOS cluster without VSD is not
accurately synced in NSM.
•482988—The NSM calculation of the estimated disk space required for DevSvr logs
is inaccurate (Administer > Server Manager > Servers > Disk and Log Management).
•482995—DevSvr logs are not getting purged after the specified time interval if you set
this interval using the NSM GUI (Server Manager > Servers > Device Server > Disk and
Log Management > Number of days to retain logs).
•483416—Accessing the policy options of an existing policy causes the NSM GUI client
to lock up, which prevents you from making any further changes.
•486787—You cannot import or manage SRX Series devices after an upgrade. Also, the
GuiSvr core dumps if any changes were done using the NSM GUI.
•489258—The DevSvr crashes while viewing the IDP logs in Log Viewer.
•491015—An inconsistent export of DevSvr log data to csv format occurs when using
the devSvrCli.sh log2action utility.
•495737—When updating the device software for an imported ScreenOS cluster device,
a warning message appears stating that the configuration in NSM and the actual device
configuration are not in sync, even when they are.
•503179—Logs are not getting parsed because of file header corruption, resulting in a
devSvrManager crash with core.
•503231—A sub-interface cannot be created on a serial interface on the SSG-20 platform
as the interface is not displayed in the NSM GUI.
•505169—In NSM, the log filter is getting created only for the group and host address
objects and not for the network address object when you create the filter by
right-clicking the source or destination address column within a log.
•507098—A GuiServer Manager core dump occurs when compiling IDP policies.
•512215—When editing an imported firewall cluster configuration, even if the VR is shared
NSM displays the following error message on the zone: “Shared zone must be in shared
VR” .
•513335—During an IDP firmware upgrade, if an error occurs, the upgrade process
continues indefinitely and cannot be stopped. With the 2010.3 release and later, a
timeout option is provided to stop this process.
•513985—During an import for a ScreenOS cluster, the BGP neighbor configuration is
imported to cluster level instead of member level.
•514579—PIM-SM settings or any dynamic routing protocol cannot be configured on
an imported firewall because the NSM GUI does not display the Protocol section under
interfaces when SOS devices are added in Cluster mode.
•516433—NSM displays an out-of-sync message when the primary device in an SRX
Series virtual cluster goes down and the secondary devices takes the primary role. The
workaround is to reconcile inventory.
•517009—A Global MIP object cannot be created on the subinterface of a cluster as
the subinterface (redundant1) is not being listed in Object Manager.
Copyright © 2010, Juniper Networks, Inc.12
Network and Security Manager 2010.3 Release Notes

•517864—During an SRX Series device update, VPN Manager-configured VPN settings
are being removed from the secondary node of the cluster.
•518196—If you have an NSM HA set up with MIP IP addresses and perform a delta
config, NSM unsets the secondary NSM server IP address from the cluster members.
•519004—You cannot select an interface for an imported SRX Series device from the
VLAN interface in NSM. NSM displays the following error: “Reference to undefined
collection-of-interface-range”.
•519395—For ScreenOS 6.3 devices, the NSM VPN Manager does not generate proxy-id
configurations for VPNs.
•521126—When a Source NAT update is pushed to an imported SRX Series device from
NSM, a reference to the NSM's local database is pushed instead of the IP address or
address object.
•525729—When OSPF parameters are configured using a template and then updated
on a device, the OSPF ID is not imported when you import the device configuration
back to NSM.
•528500—If you make more than 100 configuration changes in NSM from the actual
device configuration, the Job Manager displays only the first 100 lines.
•528681—When a polymorphic object is updated to a device, NSM sends the polymorphic
object name instead of the address object information.
•529124—As several of the NSM windows (such as Policy windows, Device edit windows,
and Download schema windows) were too tall, some of the buttons/functionalities
within these windows were inaccessible on normal displays. From 2010.3 release and
later, the windows are resized automatically to fit within the display.
•532571—If RMA/Activate is performed on a managed Junos OS device, it cannot connect
to NSM after the device is rebooted or the Device server is restarted.
•533763—NSM stops responding at 76 percent when policies are updated on
ScreenOS-based ISG-IDP devices.
•538643—With NSM, when you set the interface zone to null, the device update fails
as NSM tries to unset the g-arp parameter for that specific interface..
Release 2010.2
This section describes the addressed issues in 2010.2:
•228510—If you configure a multi-line banner for a device, verification fails on update.
•271590—Deleting the system services outbound-ssh stanza does not cause existing
connections to be dropped.
•407541—When you add Junos OS devices in cluster mode through the reachable device
workflow, device status is Import Needed if you first add the primary and then the
secondary device. To change the cluster status to Managed and In Sync, you must
import the cluster. To work around this issue, first add the secondary device and then
the primary device.
13Copyright © 2010, Juniper Networks, Inc.
Addressed Issues

•420276—VPN monitor does not display an entry for the vsys cluster member if the
name of the member is changed.
•429396—When a user performs a delta configuration after updating the device
configuration on an SRX Series device using a template, the same configuration data
that was pushed earlier to the device during the update is displayed.
•431656—When a standalone IDP device is added through a unreachable workflow,
the device update operation fails.
•445014—A Java exception error on the GUI occurs after modeling vsys to include a dot
as part of its name.
•462408—NSM displays “Unable to acquire lock,Locked by admin,Open read-only”
when you edit a device. This issue has been observed when editing an ISG2000 cluster
member and also on a J6350 device. This issue is not always reproducible. The
workaround is to restart the GUI Server.
•466608—NSM unsets the proxy ID of the VPN when it is configured in the template
at the first delta after restarting the GUI Server.
•468807—The comments are not pushed to the device, during a Junos OS device update.
•481318—After an upgrade to ScreenOS 6.2 devices, NSM tries to send the command
unset zone vlan block, which results in an update failure.
•483395—After running the import admin directive, NSM changes other configurations
along with admin accounts.
•483452—NSM 2009.1r1 randomly fails to recognize certain IDP detector engine versions.
•483469—Major screen redraw issues occur when running Microsoft Vista 32-bit and
NSM.
•485458—NSM displays a missing mgt route error.
•486371—The GuiServer Manager crashes as the system runs out of memory.
•495027—Power failure on the active GUI server causes a 7- to 10- minute delay before
the Device Server connects to the active GUI.
•497349—J Series devices cannot be validated through NSM.
•498554—The HA Server does not stop during system shutdown.
•498790—NSM unsets vrouter trust-vr on update if a comment is also configured.
•499064—The NSM GUI Server crashes with a Mutex Lock Event.
•499688—You cannot use the NSM GUI to remove an IDP platform from a custom IDP
attack signature.
•499748—When a packet capture (pcap) is requested and it contains VLAN traffic,
NSM replies with a JAVA Null pointer exception.
•500367—Policy update in NSM fails intermittently, displaying a Java NullPointer
Exception.
•500769—NSM does not support PPP and PPP-service protocols on J Series devices
with a 10.0r1.8 image.
Copyright © 2010, Juniper Networks, Inc.14
Network and Security Manager 2010.3 Release Notes

•500838—The timeout value defined in a custom service object is not updated to an
SRX Series device.
•501095—No error message is displayed even when the comment length exceeds 31
characters.
•501875—An SRX Series device will be shown as down if the primary GUI server fails
over to the secondary and a device connection is not established in extended HA.
•502166—The NSM GUI crashes while viewing audit log details.
•502223—When importing an NS-5GT in Home-Work port mode with DHCP DNS Options
set, NSM attempts to unset these options at the next update.
•502390—If you use NSM 2009.1 and want to upload either the SA 6.5r2 or IC C3.1r2
software into NSM, you must run a Juniper Networks Update to enable subsequent
device software upgrades through NSM.
•504195—NSM does not expand the GUI window for router-instance routes.
•504414—NSM does not allow creation of an rpc-program-number in a custom service
object if UDP or TCP services are selected.
•504457—NSM unsets the value of lifetime kilobytes from custom phase 2 proposals
after import from a device to NSM.
•509454—NSM overrides previous rule parameters when a duplicate policy ID is present
in a rule.
•511486—An SRX Series device is displayed as a ScreenOS device in the NSM device
manager after a schema upgrade to 124.
•512713—After running an import admin directive, NSM changes other configurations
along with admin accounts.
•515794—New signature language constructs within-bytes,within-packets, and
context-check created within a customer signature do not appear within the individual
attack object signature set on the device.
•515797—NSM cannot create a valid custom compound signature attack with new
signature language constructs.
•516416—An APE rulebase configured with a Custom Application fails to update for an
update device operation.
•516478—NSM incorrectly displays tunnel interfaces in a VPN.
•516804—An IPv6 configuration imported into NSM immediately shows delta.
•518800—NSM overrides previous rule parameters when a duplicate policy ID is present
in a rule.
•523762—Prior to the NSM 2010.2 release, NSM did not manage SRX Series policy
names. When the device is imported and updated, NSM overwrites these policy names
with the corresponding NSM policy IDs. With NSM 2010.2 release and later, these policy
names are managed and displayed in the newly introduced Policy Name column.
15Copyright © 2010, Juniper Networks, Inc.
Addressed Issues

Release 2010.1
This section describes the issues in 2010.1:
•236415—NSM erroneously autopopulates interface settings in templates.
•250830—NSM does not allow you to add SSG500 and SSG500M devices to the same
cluster.
•256770—A template operation directive may incorrectly remove passwords.
•269588—gl29042 IDP clusters in third party HA configurations display a failed status
at all times while IDP clusters in standalone HA installations display correct status.
•275084—NSM does not display address objects from the global domain under filtered
logs within a subdomain.
•277921—NSM does not allow you to add both SSG550 and SSG550M devices to the
same cluster.
•283064—DSCP values are not exported when a policy is exported to HTML format.
•289807—When configured, NSM fails to unset the BGP Neighbor route map.
•290186—NSM does not allow grouping of multicast address objects.
•294623—In NSM, you can accidentally create a firewall policy with a Policy ID (PID)
that is already associated with another policy. If this happens, NSM displays a yellow
warning message but allows the action to continue. Then NSM renumbers the policy
and pushes it to the device. However, NSM does not change the PID in the policy list.
This can lead to inconsistencies such as a mismatch between policies and PIDs.
•301001—NSM generates a validation error on subinterfaces based on aggregate
interfaces when bandwidth is greater than 100 Mbps.
•308927—NSM does not import the negate operator for a DI Custom attack.
•392276—NSM does not remove BGP commands when unsetting a tunnel interface.
•392731—The Search feature is missing some special characters.
•394395—The NSM GUI does not display traffic logs.
•397197—During an attack update in NSM, the GuiSvr manager restarts and performs
a core dump.
•398479—The devSvrLogWalker process crashes frequently.
•402285—NSM fails to create an MIP on a device resulting in a device update failure
when the MIP is included in a policy rule. However, the MIP can be created locally on
the device and used.
•405236,ScreenOS PR 408237—NSM does not provide an option for enabling an NTP
server on a firewall running ScreenOS 6.X.
•405802—NSM does not allow the manual mode setting for interfaces.
•406401—NSM Security Explorer does not display top attacks or top attackers when
an attack log is created.
Copyright © 2010, Juniper Networks, Inc.16
Network and Security Manager 2010.3 Release Notes

•411983—NSM attempts to set OSPF retransmit intervals even when the interface is
not part of an OSPF area.
•412776—If you create a custom view using an existing view, the custom view is not
saved in the LogViewer.
•414615—The NSM GUI is very slow.
•415598—Importing a firewall into NSM generates a validation error.
•421675—NSM does not generate unset commands correctly on devices running
ScreenOS.
•436368—NSM displays 'unset interface ethernet0/3 g-arp' in the delta config summary.
•436779—Editing settings at the member level in NSM deletes settings in multiple
clusters.
•438346—VRRP support for devices running ScreenOS 6.0.
•438686—Upgrades from ScreenOS release 5.4 to 6.1 in NSM causes template overrides
at the cluster level.
•438804—Deleting a virtual router from NSM also deletes the virtual router configuration
on multiple clusters.
•441419—NSM 2007.3r5 as well as NSM 2008 (with ScreenOS 6.1 schema) does not
include the CLI: set flow vpn-tcp-mss and set flow tcp-mss.
•442379—Tunnel interfaces belonging to shared virtual routers and zones are not
available in the Vsys.
•444462—Updates to devices running JUNOS fail if there are spaces in the name of the
address object.
•451634—NSM incorrectly displays differences immediately after creating a new policy
version with the policy versioning tool.
•453177—When you create a full mesh route-based VPN from the VPN Manager with
a numbered tunnel interface and NHTB with next hop IP-enabled, and then you delete
a device in the VPN setup and add the same device again, NSM generates a validation
error on the tunnel interface. The previous NHTB entries are also lost.
•454594—When a GRE over IPSec transport mode is selected for a VPN bound to a
tunnel interface, NSM generates an error.
•459772—When you right-click on a device in Device Manager, the software install list
is blank.
•460404—NSM 2008.2r2 does not support the ScreenOS 6.1 MGT zone for modeled
SSG5 devices.
•463817—On a modeled device running JUNOS software, you need to promote a
template twice in order to update it. However, after you promote the template,
previously edited device settings are erased from the device template.
•466215—When you install NSM with a custom data directory, NSM changes the
ownership and permissions of all files and folders present under the parent directory
instead of modifying the custom data directory alone.
17Copyright © 2010, Juniper Networks, Inc.
Addressed Issues

•466534—When rules are dragged and dropped into Rulegroups, they appear randomly
within the policy instead of within the Rulegroup.
•466683—NSM generates wrong commands when a zone named 'dmz' is created on
an NS5GT device.
•467638—Setting up a TCP connection to port 7808 and then disconnecting causes
many errors in the guidaemon log file.
•468861—NSM does not allow editing of a vsys device.
•469070—NSM does not allow the deletion of a device from Device Manager if it was
part of a VPN with NHTB enabled.
•469707—NSM displays an error when a VPN is configured to use an outgoing interface
at a cluster level.
•470179—Changing the IP address of a subinterface with OSPF causes an update failure.
•470698—NSM does not provide an option for setting 'ssh known host' in SRX Series
devices.
•470709—After importing a configuration from the DHCP server, NSM changes the
DHCP configuration and tries to update the DHCP server.
•470784—NSM does not import the device configuration from file correctly. Some fields
are either not imported or improperly displayed after import.
•471128—NSM does not display a warning when a comment for an address object
exceeds the supported number of characters.
•471868—On an NS5400 device, NSM displays a warning that the max User_Zone 1023
is larger than the number of user zones supported by the device.
•471965—NSM displays a warning when an address object contains more than 31
characters whereas ScreenOS 5.x permits it.
•473282—NSM 2007.2r2 does not provide the option avail_vip_same-as-untrust for an
SSG550 device running ScreenOS 6.0.
•473595—An upgrade from NSM 2008.2 to 2009.1 causes API integration errors.
•473614—NSM does not provide the option of configuring SSH known hosts on J Series
routers running JUNOS 9.4 and later.
•475784—NSM incorrectly displays denied logs of JUNOS 9.6 as permitted/ accepted.
•475824—On an SRX Series device running NSM 2009.1r1,the values of Bytes Total and
Packets Total are miscalculated.
•475862—NSM does not provide a means to execute the ScreenOS 6.1 command ‘set
flow vpn-tcp-mss’.
•475961—The NSM UI hangs indefinitely if the RMA/Activate procedure is not successful.
•476808—The SNMP location field should be a member level setting and not a cluster
level setting.
Copyright © 2010, Juniper Networks, Inc.18
Network and Security Manager 2010.3 Release Notes

•477349—If you select the None radio button in the NSM GUI, the context is un-initialized
and data is lost. A workaround is to save your data before you click the None button
and then restore the data after you select other options.
•477575—NSM does not generate encryption commands to SRX Series gateways when
AES is chosen as algorithm.
•478227—After RMA, an SRX 650 device cannot be activated in the unreachable mode.
•478487—If you remove a VPN created through the NSM VPN Manager, NSM fails to
remove the tunnel interface from the zone while updating the device configuration,
causing a commit failure.
•480054—NSM does not allow you to set Certificate Authority revocation to None.
•480114—When a user is created on the SRX Series device template, applied to the
device, and the device is updated; NSM always displays differences in the delta config
for the encrypted password configured in the template.
•480558—The NSM UI client freezes when you create and save multiple rule groups.
•480566—When the DHCP domain is set in a template, the CLI is not updated to an
SSG5 device running ScreenOS 6.2.
•480583—NSM does not provide an option to set policy based routing on redundant
interfaces.
•482295—NSM unsets DI pack on a device running ScreenOS if Base pack is selected.
•484916—NSM settings for the minimum and maximum number of packet logs that
can be stored in IDP devices need to be modified.
•485633—NSM does not allow custom ICMP services without code values.
•485646—During the initial update after importing a new device, NSM deletes console
port configurations from the device.
•485648—Device updates from NSM fail erroneously stating an application timeout.
•485656—After importing a new device, NSM tries to change its priority of redundancy
group value from 1 to 0.
•485773—NSM incorrectly generates validation errors when importing group
configurations from an SRX series device.
•485897—NSM displays a validation error on predefined JUNOS GTP services.
•488384—NSM does not delete custom zones defined in separate VSYS devices in
separate subdomains.
•491156—The NSM error message for duplication of objects is not sufficiently informative.
•494878—During a fresh installation of NSM 2009.1r1a, predefined service objects are
not converted to xdb.init.
19Copyright © 2010, Juniper Networks, Inc.
Addressed Issues

Known Issues
This section describes known issues with the current release of NSM. Whenever possible,
a workaround is suggested. These release notes contain issues related to NSM only. For
a complete list of addressed issues for each device, see the release notes associated
with the device.
NSM
•266865—When you use NSM to edit the startup information of a device and change
the Use Device Server Through MIP setting to Use Default Device Server IP Address
and Port or make the opposite change, NSM does not push the change to the device.
•277604—Interface configuration screens show more settings than are supported by
the actual interface.
•277718—When you use NSM to set Antivirus (AV) parameters for a policy on a Juniper
Secure Services Gateway (SSG) 300 Series device running ScreenOS 6.0r4, the new
setting is not pushed to the device. However, NSM can be used successfully to send
AV parameters settings to SSG 140 Series devices running ScreenOS 6.0r4.
•277997—Device updates fail when a policy that references address objects for ScreenOS
devices is assigned to a J Series device because the address object naming conventions
for J Series devices are more restrictive than the naming conventions for ScreenOS
devices. For J Series devices, the address object name must be a string that begins
with a letter and consists of letters, numbers, dashes, and underscores. For ScreenOS
devices, the address object name can include a combination of numbers, characters,
and symbols. To ensure that a J Series device can use the Address Objects referenced
by the security policy that is assigned to the J Series device, all address objects in that
policy must follow the address object naming conventions for J Series devices. If the
policy that is assigned to a J Series device contains preexisting address objects for
ScreenOS devices, these address objects must be renamed to follow the same address
object naming conventions for J Series devices.
•284698—NSM users that do not have the View Security Policies role can still see the
policy node within devices that have their Policy Management Mode set to In-Device.
•286643—When you create a virtual system device with a ‘.’ in the name, the firmware
upgrade fails. The root device will reflect the change, but the virtual system will not.
•287814—NSM users with IDP administrator credentials logged into a subdomain can
edit shared address objects that are also visible in the global domain.
•288309—For J Series routers in an NSM cluster, when the cluster member device
reboots and reconnects to NSM, the hardware inventory displays out-of-sync in the
Device list table. To work around this issue, execute the Reconcile Inventory directive
to synchronize the inventory state of the device.
•288993—When you customize a predefined report, guiSvrCli.sh does not generate it
correctly and causes subsequent reports to fail.
Copyright © 2010, Juniper Networks, Inc.20
Network and Security Manager 2010.3 Release Notes