Support Support Downloads Knowledge Base Case Manager My Juniper Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[EOL/EOE] Device using wrong VR to connect to NSM server and failing to connect to NSM server

0

0

Article ID: KB11481 KB Last Updated: 18 Oct 2020Version: 5.0
Summary:
Note: A product listed in this article has either reached hardware End of Life (EOL) OR software End of Engineering (EOE).  Refer to End of Life Products & Milestones for the EOL, EOE, and End of Support (EOS) dates.
It is very important that the firewall device uses the correct interface to connect to NSM.  Failure to do so can cause connection issues.
Symptoms:
Symptoms & Errors:
  • Firewall Device unable to connect to NSM server
  • Firewall Device choosing wrong outgoing interface to connect to NSM server
  • Firewall Device choosing wrong VR to connect to NSM server
Solution:

When a firewall device is added to NSM, the device initiates a connection to NSM device server on port 7800.  While adding the device, NSM configures the device level configuration for reaching out to NSM.  It is very important that device uses the correct interface to connect to NSM.  In cases where device is not able to connect to NSM perform the  following checks:

Device using wrong Source Interface to reach out to NSM device server:

  1. Login to the Device and execute the command get nsm. Output from the device will look similar to the following:
    ISG1000-> get nsm
    <Status> Enabled (Connecting, Down 9d;06:22:13 since 05/10/2002 08:10:52)
    <Key exchange ID> B5DB1CE2437A8422E2201188405C0106C30DD07000
    <Primary server> host: 172.19.50.175, port: 7800 src-interface eth0/0
    <Public Key for server 172.19.50.175>: 00209787B949503D6BAB2E7C2FC16AF75308E34AD684B9A086DD8258FDC4B04E1523000123
    <BulkCLI> reboot: Yes, timeout: 120 seconds
    <Domain ID/Device ID>:  1/386 (root)
    <Report settings>:
            Protocol Distribution Table:         Yes
            Ethernet Statistics Table:           Yes
            Attack Statistics Table:             Yes
            Flow Statistics Table:               Yes
            Policy Traffic Statistics Table:     Yes
            Traffic Alarm Reports:               Yes
            Attack Alarm Reports:                Yes
            Other Alarm Reports:                 Yes
            Deep Inspection Alarm Reports:       Yes
            Configuration Log Reports:           Yes
            Information Log Reports:             Yes
            Self Log Reports:                    Yes
            Traffic Log Reports:                 Yes
    <Connection History>
            Connected       05/10/2002 08:10:52 (was down for 00:02:51)
            Disconnected    05/10/2002 08:08:01 (was up for 18:24:09)
            Connected       05/09/2002 13:43:52 (first time)
    <Logs accounting info>:
            Number of logs dropped: 6
  2. The output above indicates the device is using eth0/0 as source interface to reach out to the NSM. Make sure this is the right interface to reach NSM device server. If this is not the correct interface it can be corrected by running the following commands on the device CLI.
    set nsmgmt server primary 172.19.50.1 src-interface mgt
    save
    unset nsm en
    set nsm en
  3. Once the changes are made, run get nsm from the command line to make sure the device is able to connect to NSM server.
 

Device not able to connect to NSM server due to wrong VR in reaching out to NSM server:

By default device uses route lookup to reach out to the NSM server. If there are multiple routes to the NSM server then device chooses the route from the default VR.

An issue can occur in cases where the mgt interface is in the trust-vr and the default vr is untrust vr or some other user defined vr.  In order to verify which route the device is taking to reach out to NSM server, run the command get route ip <NSM_IP_ADDRESS>

nsisg1000(M)-> get route ip 172.19.50.233
Dest for 172.19.50.233
--------------------------------------------------------------------------------------
trust-vr       : => 172.19.51.194/23 (id=2) via 0.0.0.0 (vr: trust-vr)
                    Interface mgt , metric 0
potential routes in other vrouters:
untrust-vr     : => 0.0.0.0/0 (id=1) via 192.168.15.2 (vr: trust-vr)
                    Interface ethernet1/1 , metric 1
The above output indicates that the device has 2 routes in 2 different VRs for reaching out to NSM server. When the actual connection to the NSM server is made it chooses the default VR defined on the device to connect NSM.  To find the default VR on the device run the command "get vrouter".
nsisg1000(M)-> get vrouter
* indicates default vrouter for the current vsys
A - AutoExport, R - RIP, N- NHRP, O - OSPF, B - BGP, P - PIM

   ID Name           Vsys       Owner     Routes    MRoutes     Flags
*   1 untrust-vr     Root       shared    1/max       0/max      
    2 trust-vr       Root       shared    5/max       0/max      
total 2 vrouters shown and 0 of them defined by user

The above command output indicates that the device has default vr of untrust-vr and is going to choose eth1/1 to reach out to NSM. This may cause problems in connecting to NSM server as the device should normally go out of mgt interface to connect to NSM.

To correct this situation there are 2 option.

Option#1:
Change the default VR to trust-vr by running the below 2 commands:

nsisg1000(M)-> set vrouter trust-vr
nsisg1000(trust-vr)(M)-> set default-vrouter
nsisg1000(trust-vr)(M)-> exit
nsisg1000(M)-> save
nsisg1000(M)-> unset nsm en
nsisg1000(M)-> set nsm en

Option#2:
If changing the default VR is not an option then a route should be added in the default VR specific to NSM server to route traffic to trust-vr.

nsisg1000(M)-> set route <NSM_IP/32> vrouter "trust-vr" preference 20 metric 1
nsisg1000(M)-> unset nsm en
nsisg1000(M)-> set nsm en
nsisg1000(M)-> save

 
 

For additional assistance, consult: KB9836 - Not able to connect or select the device from NSM.

Modification History:
2020-10-18: Tagged article for EOL/EOE.
 
Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search