Juniper NETWORK AND SECURITY MANAGER - S REV 1 Instruction Manual

Network and Security Manager Release
Notes
November 18, 2010
Revision 1
Contents VersionSummary....................................................2
NeworChangedInformation...........................................2
BeforeYouInstallNSM................................................2
SolarisLocales...................................................2
Upgrade Considerations ..............................................3
UpgradingNSM..................................................3
DeprecatedOperatingSystem......................................3
Limitations .........................................................3
Important SSL VPN and Infranet Controller Instructions . . . . . . . . . . . . . . . . . . . . . 4
NSMServer.....................................................4
Setting Up NSM to Work with Infranet Controller and Infranet Enforcer . . . . . 5
Usage Guidelines for Applying NSM Templates to SA and IC Clusters . . . . . . . 7
Recommended...............................................7
NotRecommended...........................................7
BestPractices.......................................................8
MaintainingtheNSMGUIServer....................................8
Creating a Self-Signed TLS Certificate Between the NSM Client and the
NSM Server .................................................8
AddressedIssues ...................................................10
KnownIssues.......................................................17
NSM ..........................................................17
EXSeriesSwitches..............................................28
DevicesRunningScreenOSandIDP................................28
Secure Access SSL VPN SA Series and United Access Control Infranet
Controllers .................................................29
SRXSeriesServicesGateways.....................................30
NSM Documentation and Release Notes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Documentation Feedback............................................31
RequestingTechnicalSupport.........................................32
RevisionHistory ....................................................33
1Copyright © 2010, Juniper Networks, Inc.

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 the 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 or Changed Information
The following list provides the new or changed information for this release:
•NSM supports the management of SRX Series devices in packet and mixed mode.
•With the Junos OS Release 10.2 and later, the following devices from the SRX family
have been renamed:
SRX Series Devices—New NameSRX Series Devices—Old Name
sxr210bsrx210-lm
srx210hsrx210-hm
srx210h-poesxr210-poe
srx100bsrx100-lm
srx100hsrx100-hm
srx240bsrx240-lm
srx240hsrx240-hm
srx240h-poesrx240-poe
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.
Copyright © 2010, Juniper Networks, Inc.2
Network and Security Manager 2010.4 Release Notes

Upgrade Considerations
This section contains information about upgrading NSM and deprecated operating
systems.
Upgrading NSM
You can upgrade to NSM 2010.4 from the following versions:
•2008.2RX
•2009.1RX
•2010.1
•2010.2
•2010.3
NSM 2010.4 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 earlier.
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.
3Copyright © 2010, Juniper Networks, Inc.
Upgrade Considerations

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.
•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
Copyright © 2010, Juniper Networks, Inc.4
Network and Security Manager 2010.4 Release Notes

-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.
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 1d.
d. Click OK.
5Copyright © 2010, Juniper Networks, Inc.
Important SSL VPN and Infranet Controller Instructions

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.
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.
Copyright © 2010, Juniper Networks, Inc.6
Network and Security Manager 2010.4 Release Notes

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.
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
7Copyright © 2010, Juniper Networks, Inc.
Important SSL VPN and Infranet Controller Instructions

/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>
<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).
Copyright © 2010, Juniper Networks, Inc.8
Network and Security Manager 2010.4 Release Notes

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
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'
9Copyright © 2010, Juniper Networks, Inc.
Best Practices

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
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.
•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.
•403809—Policies cannot be edited as NSM displays a locked by another user message
even though another user is not logged in to NSM.
Copyright © 2010, Juniper Networks, Inc.10
Network and Security Manager 2010.4 Release Notes

•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.
•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.
•448239—Predefined IDP policies cannot be pushed to an SRX Series device. The
workaround is to create the custom policy from the predefined policy, and then delete
the disabled rule in the custom policy before making a policy update.
•454585—E-mail alerts from NSM do not include any attack details for IDP logs.
•459994—In NSM 2007.3r5, DevServer Manager crashes when a PCAP retrieval operation
is performed on logs.
•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.
•465850—Uploading of the IDP 5.0 image fails in NSM after an upgrade from the
2008.2r1 to the 2008.2r2 release.
•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.
•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.
•478268—An update to an SRX Series device fails if the Confirmed commit option is
enabled in the GUI.
•481066—SRX Series IDP severity level log information is displayed incorrectly in the
NSM Log Viewer.
•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).
11Copyright © 2010, Juniper Networks, Inc.
Addressed Issues

•482995—DevSvr logs are not getting purged after the specified time interval if you set
this interval using NSM GUI (Server Manager > Servers > Device Server > Disk and Log
Management > Number of days to retain logs).
•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.
•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.
•483469—Major screen redraw issues occur when running Microsoft Vista 32-bit and
NSM.
•485458—After adding a device to NSM, if you remove the default route and enable
the dynamic protocol for that device, NSM displays an error indicating that the
management route is missing.
•486371—The GuiServer Manager crashes as the system runs out of memory.
•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.
•489643—As a result of incorrect parsing of log data in NSM, the Log Viewer displays
inaccurate information in different fields for AV, UF, traffic, and IDP logs.
•491015—An inconsistent export of DevSvr log data to csv format occurs when using
the devSvrCli.sh log2action utility.
•494359—For SRX Series devices configured with VPN, the Delta Config summary
shows configuration differences even after a device update.
•495027—Power failure on the active GUI server causes a 7- to 10- minute delay before
the Device Server connects to the active GUI.
•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.
•497114—Updates to an SRX3600 device fail because NSM repeatedly displays a
hardware OutofSync message. The workaround is to manually right-click on the device
and reconcile inventory.
•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.
•499642—While performing Get Delta Config Summary and Update directives, NSM
reports an error “Failed to acquire lock on device” even when no other user is logged
in.
Copyright © 2010, Juniper Networks, Inc.12
Network and Security Manager 2010.4 Release Notes

•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.
•500838—The timeout value defined in a custom service object is not updated to an
SRX Series device.
•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.
•502893—When VPN Manager is set to automatically generate static routes, it ignores
the default route preference set in the corresponding virtual router.
•503179—Logs are not getting parsed because of file header corruption, resulting in a
devSvrManager crash with core.
•503231—A subinterface cannot be created on a serial interface on the SSG-20 platform
as the interface is not displayed in the NSM GUI.
•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.
•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.
•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.
•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.”
13Copyright © 2010, Juniper Networks, Inc.
Addressed Issues

•512288—After a device import, duplicate objects are created due to the mismatch in
color between the configuration on the device and on NSM.
•512713—After running an import admin directive, NSM changes other configurations
along with admin accounts.
•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.
•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.
•515796—NSM UI displays the virtual chassis option for all OS versions of SRX low-end
(100/210/240/650) devices, but does not support SRX devices running versions earlier
than Junos OS Release 10.1.
•515797—NSM cannot create a valid custom compound signature attack with new
signature language constructs.
•515845—NSM UI does not display the correct hardware inventory output for devices
in an SRX Series virtual cluster.
•516416—An APE rulebase configured with a Custom Application fails to update for an
update device operation.
•516433—NSM displays an out-of-sync message when the primary device in an SRX
Series virtual cluster goes down and the secondary device takes the primary role. The
workaround is to reconcile inventory.
•516478—NSM incorrectly displays tunnel interfaces in a VPN.
•516804—An IPv6 configuration imported into NSM immediately shows delta.
•517009—A Global MIP object cannot be created on the subinterface of a cluster as
the subinterface (redundant1) is not listed in Object Manager.
•517864—During an SRX Series device update, VPN Manager-configured VPN settings
are being removed from the secondary node of the cluster.
•518800—NSM overrides previous rule parameters when a duplicate policy ID is present
in a rule.
•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.”
Copyright © 2010, Juniper Networks, Inc.14
Network and Security Manager 2010.4 Release Notes

•519395—For ScreenOS 6.3 devices, the NSM VPN Manager does not generate proxy-id
configurations for VPNs.
•519888—NSM cannot create a single tunnel interface VPN using VPN manager. NSM
builds NHTB entries using the egress interface of the end device, instead of the tunnel
interface.
•521126—When a Source NAT update is pushed to an imported SRX Series device from
NSM, a reference to the local NSM database is pushed instead of the IP address or
address object.
•521182—As NSM does not validate the number of entries in an address group, an SRX
Series device update fails if the entries exceed 256.
•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.
•523931—Even though NSM pushes the RADIUS server information to an SRX Series
device on every device update, the Delta Config summary shows that this information
still needs to be pushed.
•525134—NSM does not save some of the changes to the user preferences for users
who are authenticated through the RADIUS server.
•525264—After an upgrade from 2010.1, the detector version information is not imported
into the cluster record when you import an ISG-IDP series root device cluster with its
associated vsys members in NSM.
•525588—In spite of filtering the report based on specific event categories, the
NSM-generated report also has information about other event categories.
•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. With the 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.
•533009—After an upgrade to the NSM 2010.2 release, an SRX device policy update
fails if this policy had comments with spaces in the previous release (that is, in the
release from which you had upgraded).
•533763—NSM stops responding at 76 percent when policies are updated on
ScreenOS-based ISG-IDP devices.
15Copyright © 2010, Juniper Networks, Inc.
Addressed Issues

•534638—For ISG-IDP Series clusters running 6.1.x versions, when a root device is
updated with a new detector, the detector version is updated only for the root device
and not for the vsys members of this device. This mismatch in detector version between
the vys members and the root device results in a device update failure.
•534943—An SRX device update fails when you push a policy that contains a customer
service object with the SQL*Net Version 2 application protocol.
•535137—During a device update, NSM does not push the maximum bandwidth setting
for a firewall policy that has traffic shaping configured. NSM creates an exception.
•537273—When you import an SOS cluster device to NSM in root mode, the aggregate
subinterfaces are displayed as physical interfaces.
•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.
•538908—NSM Policy Manager does not display comments for a rule that has a single
service enabled.
•541154—After an upgrade from 2010.2 to 2010.3, policy names are getting overwritten
with the corresponding policy IDs during a J Series or SRX Series device update.
•541576—NSM does not support adding more than one physical interface to an aggregate
interface in the ns-5000-8G2-G4 card for an ns5000 series device.
•541992—The custom phase 2 VPN proposal configuration from Junos OS devices is
incorrectly imported into NSM. In addition, NSM does not permit a user to edit this
configuration.
•542616—If an SRX Series device upgrade fails from NSM, then you cannot upgrade it
again from NSM due to space limitation. You must manually clear all temporary files
created on the device by NSM before upgrading again.
•542814—The custom phase 1 VPN proposal configuration from Junos OS devices is
incorrectly imported into NSM. In addition, NSM does not permit the user to edit this
configuration.
•543140—NSMXpress Web UI allows users created from the Web UI to log on using an
incorrect password.
•545126—For an SRX Series device, the traffic logs in the NSM Log Viewer do not contain
any information for the Rule ID and Policy ID fields.
•545225—If the Junos OS-based devices (such as SRX Series devices) are configured
with policy- or route-based VPNs, even after a device update, the Delta Config summary
shows there are configuration differences for the preshared key.
•547929—With the NSM 2010.2r1-13.1n59 release, adding or editing devices takes
relatively more time than in previous releases.
•549986—The NSM installation script fails if there are multiple tmp partitions on the
Solaris server (such as, “/tmp” and “/var/tmp”).
•550796—If you add a cluster server to NSM after an upgrade from 2008.3 to 2010.2
LGB13z1n33 (with schema 143 and running on RH5 with service pack 5), then the
cluster’s secondary server settings are grayed out in NSM.
Copyright © 2010, Juniper Networks, Inc.16
Network and Security Manager 2010.4 Release Notes

•552226—Under the Policies > Source NAT tab in NSM, the zone information is not
displayed, and the source and destination addresses are not selectable. In addition,
you cannot select a target for this policy.
•553746—NSM does not manage address objects with dns-name for SRX Series devices
running on Junos OS Release 10.2R2 and 10.0R2 images.
•557767—As SRX OS platforms have been renamed from 10.2 and later, if you model
any SRX Series low-end devices with the 10.2 or later OS using the old platform-name,
NSM GUI displays the old platform-name instead of the new platform-name.
•559528—Within an SOS template, if you assign the same host IP address for IPv4 and
IPv4/IPv6 options under the SNMP Reporting settings, NSM displays a validation error.
•560765—NSM Log Viewer stops responding and does not display the logs when there
is a huge amount of logs to be processed by the log-walker.
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.
17Copyright © 2010, Juniper Networks, Inc.
Known Issues

•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. As a workaround, 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.
•292369—When you create a policy-based VPN and then update the device and import
it back into NSM, the VPN rules previously created with VPN Manager and updated to
the device are now imported in the new policy created under Policy Manager > Security
Policies, and the new policy is assigned to the device. However, if the VPN is
subsequently deleted by the user, the VPN and all rules associated with it are removed
from the VPN Manager, but not the Policy Manager policy. Before you can successfully
update the devices, you must manually delete these VPN rules in the policy under
Policy Manager.
•292522—On a Secure Access SSL VPN SA Series device, when a user creates a resource
profile, updates the device, and tries to add another bookmark, the new bookmark
page does not show the Host and Server port values.
•295156—On a Secure Access SSL VPN SA Series device, the order of the policies within
a SAM policy is not maintained when the SAM policy is edited with the NSM GUI.
•295314—After the initial import of a device, the database version feature shows the
user who performed the import as ‘unknown.’
•299504—When you promote a device with a medium-sized configuration to a template
from the root configuration level, you must wait at least 1 minute for the change to
take effect before opening the template.
•299014—During an upgrade installation, license information is required to complete
the installation.
•302289—The virtual management Ethernet interface must be set as the management
interface on the Virtual Chassis for it to be managed through NSM.
•302500—If you perform a firmware upgrade from Junos OS Release 9.0 to 9.1 through
the device UI (or CLI) and not through NSM, you must reimport the device in NSM and
adjust the operating system (OS) version of the device. To adjust the OS version in
NSM, open Device Manager and right-click the device. Select either View/Reconcile
Inventory or Adjust-OS Version. Ensure that the OS version running on the device
matches the one recorded in the NSM database.
•In NSM 2008.2, the NSM UI connects with the GUI server through port 7808, which is
FIPS compliant. When installation is complete, you see the following message: “Please
note that TCP port 7808 is being used for server-UI communication.” Earlier versions
of NSM connected through port 7801, which was not FIPS compliant.
Copyright © 2010, Juniper Networks, Inc.18
Network and Security Manager 2010.4 Release Notes

•303308— Excessive retry operations can cause a DMI device to malfunction if NSM
closes the connection to the device while the device is trying to connect to NSM. When
you add a DMI device through the NSM UI, you first add an unreachable device and
then use the generated key to configure the device so that the device can initiate the
connection to the NSM server. The connection will fail, however, if NSM closes the
connection because:
•The device is in the modeled RMA state.
•The device shares a duplicate sequence number with another managed device.
•The platform or device type (cluster member, virtual chassis, and so on) you specified
while adding the device does not match the device itself.
You can check for these conditions by examining the Configuration Status in the Device
List. If the Configuration Status is RMA,Detected duplicate serial number,Platform
mismatch, or Device type mismatch, delete the device immediately from NSM to
prevent excessive connection retries from causing a device malfunction, such as
exceeding the maxproc limit, or reaching 100 percent CPU utilization. To add the device
again, make sure the platform type and device type specified in the device add workflow
match those of the device itself.
•304406—During an NSM installation in an HA environment, when performing a refresh
with the NSM installer or NSMXpress UI, the HA peers may not initialize communication
properly. This problem commonly occurs when you migrate from a single NSM server
to an HA configuration. The error does not occur when you perform a clean install or
an upgrade using the NSM installer.
•305451—On a subinterface, the NSM template does not display a data origin icon under
the Service Options.
•312509—When you configure the Network Address Translation (NAT) rule set on an
SRX Series device running Junos OS Release 9.2, it is not imported correctly into NSM.
•313889—When you connect 3000 or more devices to NSM, the GUI client freezes for
a few minutes because of the large number of notifications from the GUI server.
•If you add a Junos OS device to the NSM database through the reachable device
workflow, you must enable netconf for SSH (specific to system services) by running
the following command in the device CLI: set system services netconf ssh.
•388578—NSM 2008.1r1 does not support SSL-VPN security devices.
•394543—When you update the configurations of more than 30 devices together, the
update device operation can take up to 10 minutes.
•396285—Rebooting NSM servers fails in a Solaris 10 environment. You can use either
of these workarounds to start or stop an NSM server:
•Use /etc/init.d/guiSvr and /etc/init.d/devSvr as the root user.
•Use /usr/netscreen/GuiSvr/bin/guiSvr.sh and /usr/netscreen/DevSvr/bin/devSvr.sh
as an NSM user. You cannot use this script as the root user.
•400850—Physical interfaces do not appear in the PBR policy non-member list if you
bind them to the same security zone as the redundant interface.
19Copyright © 2010, Juniper Networks, Inc.
Known Issues

•404479—NSM does not list physical interfaces imported to vsys or cluster vsys devices
if they are configured in the shared zone. If the interface is not configured in the shared
zone, NSM displays it in the interface list.
•If you add a Junos OS device to NSM through the unreachable workflow, execute the
following commands on the device CLI to enable logging on it:
set system syslog file default-log-messages any
set system syslog file default-log-messages structured-data
•404943—When the predefined service ‘any-ip’ is selected in a policy-based VPN and
the device is updated, NSM generates an invalid CLI.
•406791—After migration from NSM 2008.1R1 to 2008.2, editing a VPN results in a
reference error under the manually created NHTB entry in NSM 2008.1R1.
•409350—NSM does not support automatic ADM transformation for DMI devices. VPN
monitor does not display an entry for the vsys cluster member if the name of the
member is changed.
•410009—When a large number of devices is discovered, topology discovery displays
unconnected devices, connected devices, and links as overlapping each other. The
workaround is to manually drag unconnected device icons to free areas in the topology
map, or view connected and unconnected devices separately.
•422422—With every action, the NSM server increases its usage of memory which does
not get freed later.
•426324—The NSM guiSvrManager does not scale up to manage 6000 devices. You
must limit the number of managed devices to a total of 3500 firewalls and DMI devices
with 10K configurations and 5 GUI clients.
•434863—VPN manager automatically fills tunnel proxy information for a route-based
VPN. However, for external devices, you may want to check the proxy information and
change it manually, if required.
•436587—In NSM 2008.1, the value of the NHRP field in the vrouter schema is True,
thereby enabling NHRP on all vrouters by default. In NSM 2008.2R2, the NHRP default
value is False. Migrating from either NSM 2008.1R2 or NSM 2008.2R1 to NSM 2008.2R2
ensures that wrongly enabled vrouters are reset.
•437109—If you disable backup during a high availability installation of NSM, then manual
backups using the script replicateDb present in the /usr/netscreen/HaSvr/utils/
directory are not allowed as well.
•437457—When you update an ICAP profile in a vsys device, the update fails.
•438631—When an IDP device is upgraded from 4.1R3 to 5.0, the IDP configuration files
are not imported to NSM. This is because the packet capture settings in IDP 5.0 devices
are configurable from NSM, and are limited to 1000 to 65535, unlike in IDP 4.1R3 devices.
•439567—Since IDP and ISG devices support multiple services, NSM also allows multiple
services to be added in an IDP policy. However since SRX Series devices do not support
multiple services in IDP policies, a device update fails after a service field is changed
in the IDP policy.
Copyright © 2010, Juniper Networks, Inc.20
Network and Security Manager 2010.4 Release Notes