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