icon-zia.svg
Secure Internet and SaaS Access (ZIA)

NSS Deployment Guide for VMware vSphere

Zscaler's Nanolog Streaming Service (NSS) can be deployed via VMware vSphere. This guide describes the tasks required for NSS deployment, enabling you to stream either Web or Firewall logs to a security information and event management (SIEM) system.

Prerequisites

Ensure you have a subscription to either NSS for Web or NSS for Firewall and review the following specifications and requirements:

    • 2 CPU cores: NSS uses one core for the control plane and another core for the data plane.
    • Instance memory:
      • 8 GB for up to 15K users
      • 16 GB for up to 40K users
      • 32 GB for up to 100K users. If you have more than 100K users, contact Zscaler Support.
    • Data disk size: 500 GB

    For recommended VM instance specifications, see Step 2.

    Close
    • Hypervisor: VMware ESX/ESXi v5.0 and later
    • Host CPU: 64-bit Xeon or equivalent
    • Host CPU Speed: Greater than or equal to 2.40GHz
    • VMware vSphere Client or vCenter
    Close
    • Network Adapter: E1000
    • Network Specs:
      • VM Network: 2 Virtual NICs. Optionally, you might need two additional virtual NICs as described in Configuring Advanced NSS Settings.
      • Bandwidth for log download: 11 Mbps for 10K users is an example average value.
      • IP Addresses: The following table lists the IP addresses and the interfaces on which they're configured. Internal IP addresses are allowed. The management IP address and service IP address can be on different subnets, as long as the DNS server can be reached on both subnets.
    Virtual InterfaceIP AddressDescription
    em0 (First network adapter)Management IP AddressThis is used for control connections to the Zscaler cloud and to make an SSH connection to the NSS VM for configuration and management.
    You can customize the deployment and define a separate IP address for the SSH connection to the NSS VM. To learn more, see Configuring Advanced NSS Settings.
    em1 (Second network adapter)Service IP AddressThis is used for data connections to the Zscaler cloud and to the SIEM.
    em2 (Third network adapter)(Optional) Second Management IP AddressIn cases where the default management interface cannot be used for SSH due to VLAN restrictions, Zscaler recommends that you add an additional interface just for management, so the first interface is used only for control connections to the cloud. To learn more, see Configuring Advanced NSS Settings.
    em3 (Fourth network adapter)(Optional) Second Service IP AddressIn cases where the default service interface cannot be used to connect to the Zscaler cloud and to the SIEM, you can add an additional service interface, so one service interface can be used to connect to the Zscaler cloud, and a separate interface can be used to connect to the SIEM.
    Close

  • It is mandatory to deploy the NSS instance behind a VM network security group. The NSS instance requires only outbound connections to the Zscaler cloud. It doesn't require any inbound connections to your network from the Zscaler cloud. To view the firewall requirements for your specific account, refer to the Zscaler Cloud Configuration Requirements for your Zscaler cloud: https://config.zscaler.com/<Zscaler Cloud Name>/nss.

    You can find the name of your Zscaler cloud in the URL you use to log in to the Zscaler service. For example, if you log in to admin.zscaler.net, then go to https://config.zscaler.com/zscaler.net/nss. To learn more, see What Is My Cloud Name for ZIA?

    The IP ranges are necessary to ensure that the service isn't affected by future Zscaler cloud expansion.

    Communication from the NSS to the Zscaler cloud must be excluded from SSL inspection to ensure that the NSS can authenticate to the Nanolog cluster using mutual TLS.

    Zscaler does not recommend or support forwarding outbound traffic from the NSS to or through the ZIA Public Service Edge as this can result in networking, latency, and administration issues.

    Close

Deploying NSS

To deploy NSS:

    1. Go to Administration > Nanolog Streaming Service.

    2. From the NSS Servers tab, click Add NSS Server.

      The Add NSS Server window appears.

    3. In the Add NSS Server window:

      • Name: Enter a name for the NSS.

      • Type: NSS for Web is selected by default. If you are configuring an NSS for firewall logs, select NSS for Firewall.

        If you have a subscription to Cloud & Branch Connector, the NSS for Firewall (NSS type) is displayed as NSS for Firewall, Cloud & Branch Connector.

      • Status: The NSS is Enabled by default.

    4. Click Save.

    5. Click Download in the SSL Certificate column of the NSS that you are configuring, and then save the certificate. You later upload the certificate to the vSphere Client.

    Close

  • Before you configure and start the NSS on the vSphere Client, ensure that you have downloaded the SSL certificate and NSS OVA file from the ZIA Admin Portal.

    To configure the NSS virtual appliance on the VM, log in to the vSphere Client and:

      1. In the left-side navigation, go to Virtual Machines.

      2. Click Create / Register VM.

        The New virtual machine wizard appears.

      3. In the New virtual machine wizard:

        1. Select Deploy a virtual machine from an OVF or OVA file and click Next.

        2. Enter a name for the VM and upload the OVA file that you downloaded from the ZIA Admin Portal. Click Next.

        3. Select storage for the VM and click Next.

        4. Select a VM Network and click Next.

        5. Review your settings before clicking Finish to close the wizard and deploy the VM.

      Close

      1. Power on the newly deployed NSS VM.

      2. Click the Console tab and log in to the ZscalerOS command prompt with the following credentials:

        • Username: zsroot
        • Password: zsroot

      The default login credentials are different from those that were used in NSS VM versions earlier than 4.2.1. By default, root login is not permitted. Administrators must use the utility sudo to run a command with higher privileges.

      Zscaler strongly recommends that you change this default password by running the command passwd. For more details about running this command,

      1. To change the password, enter passwd and your username. For example, if you are using the default username, the command is:
      passwd zsroot
      1. When prompted, specify the following:
        • Your current password. For example, if you are using the default password, enter zsroot.
        • Your new password

      Screenshot of FreeBSD command prompt login to change your password

      Close

      1. Enter the command sudo nss configure and complete the following:
        • Enter the DNS server IP address (e.g., 72.52.97.10).
        • Enter the management interface IP with CIDR netmask. Use the management IP address for SSH or FTP (e.g., 192.168.3.1/16).
        • Enter the default gateway for the management IP address (e.g., 192.168.1.1).
        • Enter the service IP address with CIDR netmask (e.g., 192.168.3.2/16). NSS uses the service IP address to communicate with the Zscaler cloud and with the SIEM.
        • Enter the default gateway for the service IP address (e.g., 192.168.1.1).

      The management IP address and service IP address can be on different subnets, as long as the DNS server can be reached on both subnets.

      1. Check the applied network configuration by running the following command:
      sudo nss dump-config
      Close

    • The NSS uses the SSL certificate to authenticate itself to the Zscaler service. Ensure that the SSL certificate is installed on only one active NSS VM at a time. Having multiple NSS VMs that use only one certificate causes cloud connection flapping, which disrupts the streaming of logs to the NSS.

      1. Navigate to the SSL certificate that you saved from the ZIA Admin Portal.
      2. Use FTP, SCP, or SFTP to upload it to the management IP address of the NSS.
      3. On the vSphere Client, click the Console tab and log in with the following credentials:
        • Username: zsroot
        • Password: zsroot
      4. Use to the Console tab or use SSH to connect to the management IP address.
      5. Run the following command, specifying the path to your uploaded certificate bundle. The path shown in red is an example.
       sudo nss install-cert /usr/home/zsroot/NssCertificate.zip
      1. Check the configuration by running the following command:
      sudo nss dump-config
      Close

    • Before starting the NSS:

      1. On the vSphere Client, click the Console tab or use SSH to connect to the management IP address.
      2. Run the following command to download and install the NSS binaries:
      sudo nss update-now

      After the first NSS software deployment, the software is automatically updated with new versions.

      Close
      1. On the vSphere Client, click the Console tab or use SSH to connect to the management IP address.
      2. Run the following command:
      sudo nss start

      Ensure that the command shows that the NSS virtual appliance started successfully. It can take a few minutes for the NSS to start streaming logs to the SIEM.

      After starting the NSS for the first time, you can run the following command to check that the latest NSS software version is installed:

      sudo nss checkversion

      To enable the NSS to start automatically after a restart, run the following command:

      sudo nss enable-autostart

      You can also explore other options by running the following command:

      sudo nss help
      Close

    • To verify the configuration, run the following command:

      sudo nss troubleshoot netstat|grep tcp

      When the output of the command is displayed, verify the following TCP connections are established:

      1. Connection to the Zscaler cloud on port 443: This is the control connection that is used to authenticate the NSS to the Zscaler Central Authority (CA) and to download the configuration (e.g., 10.66.69.215.443). It's also the data connection to the Nanolog so it can stream the logs (e.g., 10.66.126.443).

      2. Connection to the SIEM: This is the long-lived TCP connection to the SIEM on the specified log data port (e.g., 10.66.69.43.44332). If there are multiple feeds configured, multiple connections must be listed.

      The absence of any one of the preceding connections, even after waiting a few minutes, usually indicates that there is a firewall configuration issue and the logs cannot be streamed. To troubleshoot issues, see Troubleshooting Deployed NSS Servers.

      Close

    Optionally, you can also install the VMware tools for the NSS OVA.

    To install VMware tools:

    1. Log in (SSH) to the NSS and run the following command:
    sudo bash

    You are prompted to enter a password.

    1. In /etc/pkg/FreeBSD.conf, change the url to the following:
    "http://pkg.zspreview.net/FreeBSD:11:amd64/latest/"

    /etc/pkg/FreeBSD.conf should contain only the following lines:

    FreeBSD: {
          url: "http://pkg.zspreview.net/FreeBSD:11:amd64/latest/",
          enabled: yes
        }
    1. Run the following command:
    pkg install open-vm-tools
    1. Edit the /etc/rc.conf and add the following entries to it:
    vmware_guestd_enable="YES" 
vmware_guest_vmmemctl_enable="YES" 
vmware_guest_vmxnet_enable="YES"
    1. Reboot from the vSphere menu for the NSS instance.
    2. Check the status of the VMware tools under the General Information section.
    3. Run the following command to check the status:
    /usr/local/etc/rc.d/vmware-guestd status
    Close

  • An NSS feed specifies the data from the logs that the NSS sends to the SIEM. You can filter the data so that you send only the data you need to the SIEM. You can add up to 16 NSS feeds for each NSS server. (Web and Firewall logs are each limited to 8 feeds per NSS server to ensure optimal performance.) Each feed can have different filters and fields, and a different output format (e.g., CSV). To learn more about how to configure each feed, see Adding NSS Feeds.

    Close

Post-Deployment Tasks

After you have verified your deployment, you can perform additional tasks:

  • An NSS server represents the NSS virtual machine (VM) in the ZIA Admin Portal. When you create an NSS server in the portal, an SSL certificate is generated. You download the SSL certificate from the portal and upload it to the NSS VM that you configure and deploy. The newly configured NSS VM uses the SSL certificate to authenticate itself to the Zscaler service.

    Each NSS server supports up to 16 NSS feeds. (Web and Firewall logs are each limited to 8 feeds per NSS to ensure optimal performance.) Each NSS feed can have different filters and fields and a different output format (e.g., CSV).

    For site reliability, you can deploy multiple NSS VMs, either in an active-active or active-passive configuration.

    Active-Active Configuration

    Zscaler recommends leveraging two NSS servers per NSS type (i.e., NSS for Web and NSS for Firewall) and deploying each pair in an active-active configuration. In this configuration, you create two NSS servers of the same NSS type in the ZIA Admin Portal with separate SSL certificates.

    Running multiple active NSS VMs with the same SSL certificate causes cloud connection flapping, which disrupts the streaming of logs to the NSS.

    Optionally, for optimal reliability, you can configure the NSS VMs to stream logs to two separate SIEMs. In this configuration, each NSS VM runs independently, streaming logs to its respective SIEM at the same time.

    Zscaler does not recommend configuring two NSS VMs of the same NSS type to stream logs to a single SIEM. In this case, each NSS VM sends copies of the same logs to the SIEM, which might not be able to deduplicate them.

    Active-Passive Configuration

    Alternatively, you can deploy multiple NSS VMs in an active-passive configuration. In this configuration, you create one NSS server (for Web or Firewall) in the ZIA Admin Portal and use the generated SSL certificate to deploy one active NSS VM; the second VM serves as a cold standby. Both NSS VMs use the same SSL certificate in this configuration, but they should not connect to the Zscaler Nanolog at the same time as this results in connection flapping.

    If the active NSS VM fails, you must perform failover activities, ideally within one hour of the failure to prevent data loss. In this time frame, you can leverage the following NSS reliability mechanisms:

    • NSS to SIEM: The NSS buffers the logs in the VM memory to increase its resiliency to transient network issues between the SIEM and the NSS. If the connection drops, the NSS replays logs from the buffer, according to the Duplicate Logs setting.
    • Nanolog to SIEM: If the connectivity between the Zscaler cloud and the NSS is interrupted, the NSS misses logs that arrived at the Nanolog cluster during the interruption, and they are not delivered to the SIEM. When the connection is restored, the NSS one-hour recovery allows the Nanolog to replay logs up to one hour back.

    To learn more about NSS for Web, NSS for Firewall, and NSS Log Recovery subscriptions, contact Zscaler Support.

    Close

  • This article describes additional features that facilitate deploying the NSS in cases where you have specific requirements or restrictions. It includes the following topics:

    The first three sections listed pertain to the NSS deployment over VMware vSphere only.

    • Sometimes, the default management interface can't be used for SSH due to VLAN restrictions. In those cases, Zscaler recommends that you add an additional interface just for management, so the first interface is used only for control connections to the cloud.

      There are two ways to add a second management interface:

      • Zscaler recommends that you log in to your client and configure the additional interface from the console tab. See Configuring the Additional Interfaces from the Console.

      • To manually add a management interface:

        1. Shut down the NSS and stop the VM.
        2. Using your client, assign an additional interface to the VM. Map it to an appropriate network or VLAN.
        3. Reboot the NSS.
        4. Run the following command and ensure that the em2 interface is active:
        ifconfig
        1. Update the system configuration file /etc/rc.conf to configure the interface automatically after each system restart. To do this, run the following command:
        sudo vi /etc/rc.conf
        1. Add the em2 interface to the list of network interfaces. Modify the line that starts with network_interfaces and change it to:
        network_interfaces="em0 em1 em2 lo0"
        1. Add a new line at the end of the file:
        ifconfig_em2="<subnet-ip-address>"

        Ensure that you replace <subnet-ip-address> with the IP address of the subnet. For example:

        ifconfig_em2="192.168.1.100/24”
        1. The default gateway is automatically added via the em0 interface. To add a static route to a different subnet or VLAN for the newly added em2 interface, add the following lines at the end of the file:
        static_routes="em2"
route_em2="-net <destination-subnet> <gateway-ip-address>"

        Replace <destination-subnet> with the IP address of the destination subnet, and replace <gateway-ip-address> with the appropriate gateway IP address. For example:

        static_routes="em2"
route_em2="-net 198.51.100.0/24 192.168.1.3"
        1. Reboot the VM.
        2. To verify the changes, ping the newly added subnet gateway and run the following command to print the route information:
        sudo netstat -rn
        Close
      Close

    • The NSS typically uses the service interface to download logs from the Nanolog in the Zscaler cloud and send them to the security information and event management (SIEM) system.

      Some organizations might need to use one interface to connect to the Zscaler cloud and another interface to connect to the SIEM. For example, an organization might have a SIEM in a management LAN that is not routed to the internet, and it might also have a service LAN that is routed to the internet but not to the management LAN, as shown in the following diagram.

      Diagram of one interface connecting to the Zscaler cloud and another interface connecting to the SIEM.

      If your organization has a similar requirement, you can configure a second service interface. You can then use one interface to connect to the Zscaler cloud to download the logs and a different interface to send the logs to the SIEM located in the management LAN.

      There are two ways to add a second service interface:

      • Zscaler recommends that you log in to your client and configure the additional interface from the console tab. See Configuring the Additional Interfaces from the Console.

      • To manually add a second service interface:

        1. Shut down the NSS and stop the VM.
        2. Using your client, assign an additional interface to the VM. Map it to an appropriate network or VLAN.
        3. Reboot the NSS.
        4. Run the following command and ensure that the em2 interface is active:
        ifconfig
        1. Copy the sc.conf file.
        cp /sc/conf/sc.conf /sc/conf/sc.conf.old
        1. Use the vi Editor to edit the sc.conf file. Run the following command:
        vi /sc/conf/sc.conf
        1. Add the following lines to the file, replacing the sample values in red per your configuration:
        smnet_dev=em2=zs1:192.168.223.41/24
smnet_route=10.0.0.0/8/192.168.223.1

        In this example, em2=zs1 is the second service interface and 192.168.223.41/24 is the service IP address with the subnet mask. If your SIEM is in the same subnet, then the second line is not required. If your SIEM is in a different subnet, add smnet_route and define values in the second line. For example, to reach 10.0.0.0/8, use gateway 192.168.223.1.

        1. Save the changes in the file and then restart the NSS by running the following command:
        sudo nss restart
        1. Verify if the NSS is using the second service interface by running the following command:
        sudo nss dump-config
        Close
      Close

    • To configure a second management interface and service interface, first ensure that you run the following command to set your network settings:

      sudo nss configure

      Then, run the following command to specify the IP addresses for the additional interfaces and their corresponding routes:

      sudo nss configure split-interface

      Screenshot of FreeBSD command prompt showing the command sudo nss configure split-interface

      During a split-interface configuration, the NSS asks for an smnet_route. If your SIEM is in a different network compared to the NSS smnet interface (em3=zs1) subnet, you can enter specific routes for feeds.

      See the following example:

      [root@NSS /sc/update]# nss configure split-interface
            ifconfig_em2 (Internal Management interface IP address with netmask) [1.1.1.1/23]:
            route_net:-net 1.1.1.2/12 2.1.1.1 (Options <c:change, d:delete, n:no change>) [n]
            Do you wish to add a new route_net? <n:no y:yes> [n]:
            smnet_dev=em3 (Internal Service interface IP address with netmask) [10.10.35.20/24]:
            Do you wish to add a new smnet_route? <n:no y:yes> [n]: y
            Atleast one entry required for smnet_route
            smnet_route (Static route for Siem N/w ,e.g (network/subnet/gateway): 172.12.1.0/21/10.10.35.1) []: 1.3.2.1/2/2.2.1.2
            Do you wish to add a new smnet_route? <n:no y:yes> [n]: 2.1.2.3/2/43.3.3.2
      Close

    • If you have a local NTP Server, you can configure the NSS to synchronize time with that server:

      1. Run the following as root:
      crontab -e
      1. Add the following command:
      PATH=/sbin:/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/usr/games:/sc/update:/home/zsroot/bin:/sc/update
      1. Add the following command:
      */10 * * * * ntpdate <ntp-server-name>

      Replace <ntp-server-name> with your local NTP server's FQDN or IP address.

      1. Save and exit.

      The time synchronization command runs every 10 minutes. You can find logs for the NTP process in /var/log/cron.

      Close

    • Some customers might have a no default route environment. This prevents the NSS from establishing connections to the Zscaler cloud. For this scenario, you can configure the NSS in explicit proxy mode, so that it tunnels all Zscaler cloud-bound connections through a proxy. These include network connections and TCP connections from the NSS to the:

      • Nanolog (SMSM)
      • Zscaler Central Authority (CA) (SMCA)
      • Update server (SMCDSS) for software updates
      • Kafka server for audit log streaming

      Connections from the NSS to the SIEM are not tunneled.

      The NSS in explicit proxy mode can tunnel Zscaler cloud-bound connections. Based on your configuration, you can tunnel these connections without the need for internet-facing DNS resolution.

      If you configure the dnsoverproxy flag to 1, then the NSS in explicit proxy mode makes a CONNECT request to the following domains and the explicit proxy performs the name resolution:

      • msmca.<cloudname> for the connection to the Zscaler CA
      • zdistribute.<cloudname> for the connection to the update server
      • kproxy.hdeu1.zdataservices.net for the connection to the Kafka server

      If you configure the dnsoverproxy flag to 0, then the NSS needs DNS resolution for the connections to the current master CA IP address, update server, and Kafka server.

      NTP connections are not tunneled. The NSS needs DNS resolution for the NTP server. To learn more, see Configuring a Local NTP Server.

      To configure the NSS in explicit proxy mode:

      1. Run the nss configure command to configure the two network interfaces.
      2. Run the nss configure proxy command. For example:
      [root@NSS /usr/home/zsroot]# nss configure proxy
        proxyserver (Proxy Host ) [10.81.153.26]:
        proxyport (Proxy Port ) [443]:
        dnsoverproxy (DNS over proxy: 0/1 ) []: 1
        Successfully configured proxy

      To undo this configuration, you can use remove:

      nss configure proxy remove

      1. Run the sudo nss restart command to restart the NSS service.

        When the NSS starts, it tries to connect to the Zscaler CA or Nanolog using the proxy it configured.

      2. Run the nss troubleshoot netstat command to verify the proxy (e.g., 10.81.153.26) connections for the Zscaler CA and Nanolog.

      Close

      1. Log in to your NSS VM.
      2. Edit the file /etc/rc.conf using the vi Editor.
      [zsroot@New_Hostname ~/$ vi /etc/rc.conf
      1. Add the hostname entry to the file.
      hostname=<name>
      1. Run the reboot command.
      root@New_Hostname:/usr/home/zsroot # reboot
      1. After the NSS restarts, your new hostname appears.

    • You can restrict SSH access based on IP/Subject using the following configuration in sshd_config:

      AllowUsers zsroot@10.66.70.*

      In this example, SSH is allowed only from the source IP range 10.66.70.0/24. Then, run the following command to make the configuration change effective:

      service sshd restart
      Close

      1. Create a .ssh directory in the home directory: /home/zsroot/ under the user root.
      2. Upload your user public key file to the file authorized_keys under the directory /home/zsroot/.ssh.
      3. Adjust the file /etc/ssh/sshd_config with the following updates. Make a backup of this file before changing it.
      ChallengeResponseAuthentication no
PasswordAuthentication no

      These entries are set to yes by default. You can set them to no or comment them out.

      1. Use the following command to restart the sshd service:
      service sshd restart

      Replace option restart with stop and start as required.

      1. Test the new configuration on the client side using SSH (e.g., PuTTY).
      Close

    Close

  • You can use the following commands within the virtual machine (VM) console for your platform in order to configure and troubleshoot the NSS server. By default, root login is not permitted, so admins must use the sudo utility to run a command with higher privileges.

    • To start the service:
    sudo nss start
    • To stop the service:
    sudo nss stop
    • To restart the service:
    sudo nss restart
    • To smoothly shut down the operating system:
    sudo nss halt
    • To change the network configuration (i.e., IP addresses, gateway information) for the service:
    sudo nss configure

    To learn more, see the NSS deployment guide for your platform.

    • To configure additional interfaces:
    sudo nss configure split-interface

    To learn more, see Configuring the Additional Interfaces from the Console.

    • To configure an explicit proxy:
    sudo nss configure proxy

    To learn more, see Configuring NSS in Explicit Proxy Mode.

    • If you configured additional interfaces using the sudo nss configure split-interface command and want to remove the configuration:
    sudo nss configure split-interface --wipe
    • To remove the network settings that were configured using the sudo nss configure command:
    sudo nss configure --wipe
    • To display the configuration file that was changed using the sudo nss configure command:
    sudo nss dump-config
    • To install NSS certificates from a specified certificate bundle file:
    sudo nss install-cert <certificate bundle file>
    • To check if a new NSS version is available:
    sudo nss checkversion
    • To manually update the NSS to the latest version:
    sudo nss update-now
    • To force the NSS to update, regardless of whether a new version is available:
    sudo nss force-update-now
    • To check the firewall configuration:
    sudo nss test-firewall

    This command does active firewall configuration probing by attempting to resolve the DNS names and establishing outbound connections to the Zscaler cloud. This command doesn't reset the management IP interface, so you can run it on an SSH connection.

    • To view troubleshooting help command information:
    sudo nss troubleshoot help
    • To show the active connections on the service IP address:
    sudo nss troubleshoot netstat

    The output is similar to that of the netstat utility.

    • To show the connections and their status:
    sudo nss troubleshoot connection

    This command probes the connection status over a period of time and indicates whether the connections are stable or flapping.

    • To show the status of the NSS feeds:
    sudo nss troubleshoot feeds

    This command probes the status of the feeds and determines if the logs are queued due to the slow consumption of logs by the security information and event management (SIEM) system.

    • To generate diagnostic information to send to Zscaler Support:
    sudo nss collect-diagnostics

    This command collects the configuration, vital statistics regarding the health of the NSS, and error statistics, and then downloads the data to a local file. This file can be emailed to Zscaler Support for troubleshooting purposes.

    • To reset the network configuration:
    sudo nss reset-network
    • To change the SNMP admin user configuration:
    sudo nss snmp-admin-configure
    • To change the SNMP trap configuration:
    sudo nss snmp-trap-configure
    • To automatically start the NSS after reboot:
    sudo nss enable-autostart
    • To disable the automatic start of the NSS after reboot:
    sudo nss disable-autostart
    • To set up and enable MCAS:
    sudo nss configure-mcas2

    You must restart the NSS using the sudo nss restart command for the changes to take effect. To learn more, see Integrating with Microsoft Cloud App Security.

    • To disable MCAS:
    sudo nss disable-mcas

    You must restart the NSS using the sudo nss restart command for the changes to take effect. You can re-enable MCAS by re-issuing the sudo nss configure-mcas2 command.

    Enabling Remote Access

    An admin can request remote assistance and allow Zscaler Support to log in to their NSS server without having to open a firewall connection for inbound traffic. This feature is disabled by default and must be enabled explicitly for the duration that remote support assistance is required.

    • To enable Zscaler Support to access your NSS server:
    sudo nss support-access-start

    This creates a long-lived SSH tunnel to the Zscaler cloud and sets up remote port forwarding. Zscaler Support can then use this tunnel to log in to your NSS server.

    • To disable Zscaler Support access to your NSS server:
    sudo nss support-access-stop

    This brings down the long-lived SSH tunnel to the Zscaler cloud and all the remote connections.

    • To check the status of the Zscaler Support access to your NSS server:
    sudo nss support-access-status

    This checks the status of the long-lived SSH tunnel to the Zscaler cloud, which Zscaler Support uses to log in to your NSS server.

    • To enable a remote debugging session:
    sudo nss enable-remote-debugging
    • To disable a remote debugging session:
    sudo nss disable-remote-debugging

    Error Codes

    The following are error codes that you might encounter when executing an sudo nss update-now command:

    Error CodeDescription
    Error Code 96Invalid client certificate
    Error Code 97Timeout occurred while contacting upgrade server
    Error Code 99A problem occurred while downloading and installing the latest version. The sudo force-update-now command needs to be explicitly issued.

    Use Case

    You can use the following commands to check the DNS resolution issues on the service interface and routes to the surface interface.

    • To check the reachability of a server IP address using ICMP:
    /sc/bin/smmgr -ys smnet='ping <IP address or Domain Name>'
    • To print the server interface IP config details:
    /sc/bin/smmgr -ys smnet=ifconfig
    • To check the DNS resolution of a hostname:
    /sc/bin/smmgr -ys smnet='route'/sc/bin/smmgr -ys host="<Domain Name>" -ys connect=dns
    • To check the communication or port reachability of a server:
    /sc/bin/smmgr -ys host="<FQDN of SIEM server>" -ys port=<Listening port> -ys connect=tcp

    What happens if the NSS goes down?

    In the event of a connection loss between the NSS server and the cloud Nanolog, the cloud retransmits the logs to the NSS up to a maximum of one hour. If the NSS is down for more than an hour, the logs falling out of the one-hour window aren't retrieved by the NSS.

     

    Close
Related Articles
Deploying NSS Virtual AppliancesNSS Deployment Guide for Amazon Web ServicesNSS Deployment Guide for Google Cloud PlatformNSS Deployment Guide for Microsoft AzureNSS Deployment Guide for VMware vSphereNSS Collector Deployment Guide for VMware vSphereConfiguring Advanced NSS SettingsTroubleshooting Deployed NSS Servers