NSS Deployment Guide for Azure

NSS Deployment Guide for Azure

This guide describes the tasks required to deploy a Nanolog Streaming Service (NSS) to stream either web logs or firewall logs to a SIEM. Each step in the guide links you to the appropriate article for that configuration task on Azure. 

To learn more about NSS, see About NSS.

  1. Ensure that you have all the requirements for Azure in place.
  2. On the Zscaler Admin Portal, register the NSS and download the SSL certificate.
  3. On the Zscaler Admin Portal, get the recommended Azure VM instance specifications.
  4. Provision and configure an Azure VM.
  5. Configure and start NSS on the Azure VM.
  6. Add NSS Feeds for each NSS.

You'll need the following to deploy NSS over Azure:

  • A subscription to either NSS for Web or NSS for Firewall.
  • Azure VM specifications (see How do I download the NSS Virtual Appliance? to get your required specifications):
    • CPU
      • 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 15,000 users, 16 GB for up to 40,000 users, 32 GB for up to 100,000 users
    • Storage account: General Purpose
    • Data disk size: 500 GB
  • Network Specs
    • Two Network Interfaces with IPs that can route to Zscaler's service over the internet

The two public IPs aren't required when using a NAT. A NAT network configuration will work correctly as long as it has sufficient network bandwidth.

  • Bandwidth for log download: 11 Mbps for 10,000 users

    Firewall Requirements

    It's mandatory to deploy the NSS instance behind an Azure 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, go to the following:


    The <zscaler-cloud-name> can be found in the URL you use to log in to the Zscaler admin portal. For example, if you log in to admin.zscaler.net, then go to https://ips.zscaler.net/addresses/nss.html.

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

    IP Addresses: The following table lists the IP addresses and the interfaces on which they're configured.

    Virtual Interface IP Address Description
    nic0 (First network adapter) Management IP Address This is used for control connections to the Zscaler cloud and to make an SSH connection to the NSS VM for configuration and management. Note that you can customize the deployment and define a separate IP address for the SSH connection to the NSS VM.
    nic1 (Second network adapter) Service IP Address This is used for data connections to the Zscaler cloud and to the SIEM.

    Second management or service network interfaces are currently not supported in the NSS over Azure VM deployment.

    You can find more details about the outbound connection requirements on https://ips.<zscaler-cloud-name>/addresses/nss.html.


    1. Ensure you have Azure PowerShell Modules.
    2. Run PowerShell with administrator privileges.
    3. Run the following script to allow to run unsigned scripts: 
      Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass
    4. Download the deployment package:
    5. SAS Token for Zscaler's NSS VHD files
      • Contact Zscaler Support to receive the token.

    Configure and Launch Azure VM

    The NSS VM provisioning is done automatically using 2 PowerShell scripts.

    Follow the next steps to configure and run the scripts:

    The blob_copy.ps1 copies two VHD files from Zscaler’s Azure storage account to a general purpose account specified in copyconfig.txt. One VHD file is approximately 30GB and is used for the OS disk; the other is approximately 500GB and is used for the data disk. After copying the VHD files, the script will create an Azure Managed Image based on the OS Disk.

    To complete this step, do the following:

    1. Make sure to pre-create or select an Azure Storage account, blob container, and location to which you want to copy the disks to.
    2. Populate the values in copyconfig.txt. The following table describes each value.
    3. Run the script 
      powershell.exe .\blob_copy.ps1 '.\copyconfig.txt'
    4. In the pop-up window, enter your Azure credentials to start the script. Wait for a few minutes for the VHD files to copy. See image.
    5. After the script completes successfully, you'll see the two VHDs in the destination Blob Containter: See image.

    The deployment script spins up a new VM using the OS and Data disks copied in the previous step. The script completes the following:

    1. Optionally, creates 2 public IP addresses.
    2. Associates the VM to an existing/new VNET and subnet.
    3. Creates and associates a new network security group to the VM.
    4. Clones the OS and Data Disk VHDs copied in the previous script to a new container. The script clones the VHDs so that the original ones will not be attached to the VM and can be used to spin up additional NSS VMs in the future. You can delete the original VHDs, if necessary.
    5. Attaches the OS and Data disks to the NSS VM.
    6. Spins up the NSS VM.

    To complete this step, do the following:

    1. Populate the values in conf_file.txt. The following table describes each value.
    2. Run the script 
      deployment_script.ps1 config_file.txt
    3. In the pop-up window, enter your Azure credentials to start the script. See image.
    4. After the script completes successfully, validate that you see the following resources in your Resource Group: See image.
      • A clone of the two VHDs in the dest container
      • Two public IPs
      • Two NICs
      • A VNET/Subnet
      • A Network Security Group
      • NSS VM
    5. Manually configure the network security groups settings. See image.
      • By default, the script creates the outbound connection rules to any IP address.
      • You can find more details about the outbound connection requirements on: https://ips.<zscaler-cloud-name>/addresses/nss.html. The <zscaler-cloud-name> can be found in the URL you use to log in to the Zscaler Admin Portal. For example, if you log in to admin.zscaler.net, then go to https://ips.zscaler.net/addresses/nss.html.
      • To connect to your instance via SSH, you're required to open port 22 for inbound connections. In production, you should authorize only a specific IP address or range of addresses to access your instance and not use If you use a NAT gateway, you can disassociate and delete the two public IP addresses.
    Value Description Example
    osdisk Use the appropriate link for your region:
    • USA: https://zsprod.blob.core.windows.net/nss/znss_osdisk.vhd
    • Europe: https://zsprodeu.blob.core.windows.net/nss/znss_osdisk.vhd
    • Australia: https://zsprodau.blob.core.windows.net/nss/znss_osdisk.vhd
    datadisk Use the appropriate link for your region:
    • USA: https://zsprod.blob.core.windows.net/nss/znss_datadisk.vhd
    • Europe: https://zsprodeu.blob.core.windows.net/nss/znss_datadisk.vhd
    • Australia: https://zsprodau.blob.core.windows.net/nss/znss_datadisk.vhd
    sastok Contact Zscaler Support or your account team to receive the SAS token  
    store Destination Azure General Purpose account mycompanyzscalerstore
    name Prefix for destination VHD file names zscalernss
    dest Destination Blob Container Name in the destination storage account zscalercontainer
    rgname Creates or selects a Resource Group with this name zscaler_rg
    location The Azure location for the destination container westus

    For the value location, the following are all the possible location names:

    To get the latest location list, run the following PowerShell command:

    Get-AzureRmLocation | Format-Table
    Location Display Name
    australiacentral Australia Central
    australiacentral2 Australia Central 2
    australiaeast Australia East
    australiasoutheast Australia Southeast
    brazilsouth Brazil South
    canadacentral Canada Central
    canadaeast Canada East
    centralindia Central India
    centralus Central US
    eastasia East Asia
    eastus East US
    eastus2 East US 2
    francecentral France Central
    francesouth France South
    japaneast Japan East
    japanwest Japan West
    koreacentral Korea Central
    koreasouth Korea South
    northcentralus North Central US
    northeurope North Europe
    southcentralus South Central US
    southeastasia Southeast Asia
    southindia South India
    westus2 West Central US 2
    uksouth UK South
    ukwest UK West
    westcentralus West Central US
    westeurope West Europe
    westindia West India
    westus West US
    westus2 West US 2

    Value Description Example
    name Name of the instance zscalernss
    Used also for the NIC prefix. Identical to the one used in the blob_copy.ps script.
    location Location to deploy the instance westus
    rgname Name of destination resource group zscaler_rg
    createrg N if the resouce group is allocated already. Y if it needs to be provisioned. N
    storename Name of the destination storage account mycompanyzscalerstorage
    createstorage If storage account is already provisioned, set this to N. Set everything else to Y. N
    vnetname Name of the virtual network to which this instance is associated. Creates a VNET if the one with specified name doesn't exist. zscalernss_vnet
    vnetprefix IP address range in CIDR for the virtual network
    subnetname Name of the subnet in virtual network to which this instance is associated. Creates a new subnet if one with this name doesn't exist. zscalernss_subnet
    subnetprefix CIDR prefix for the subnet
    niccount Number of NICs to attach to the instance 2, unless advanced deployment
    • Copy: Copies the data disk VHD from srcDataURI
    • Attach: attaches the existing data disk VHD
    • Create: Creates a new empty data disk, with a size defined in datadisksize
    • Ignore: ignores
    datadisksize If create option is selected, set the size of disk to be created. Size is in GB. 500
    srcDataURL If attach option is selected, set to the data disk VHD URL   
    srcOsURI URI of the OS disk copied in the previous step. Go to Image Overview > Source Blob URI to find the URI
    dstStorageURI URI of the storage account to which the OS and Data disks are copied to. The URI should not include the ending forward slash. Go to Storage Account > Primary Blob Service Endpoint to find the URI
    dstContainer The name of the container to which the OS and data disks are copied to zscalernsscontainerprod

    The NSS service configuration steps will be executed through an SSH terminal connection to your instance. SSH to NSS only works with basic authentication. Use zsroot/zsroot when prompted for credentials. We recommend that you change the default password.

    Before starting, do the following:

    • Note the private IP of the service network interface (nic_1) you created in your Azure account.
      1. Go the NSS VM Configuration page.
      2. On the side menu, go to Networking, and select nic_1.
      3. Copy the Private IP address. See image.

    Configuring the NSS Virtual Appliance on Azure

    To configure the NSS virtual appliance on Azure, follow the steps below.

    1. Copy the SSL Certificate. 
    2. Remote log in to the Azure VM instance.
    3. Install the SSL Certificate.
    4. Configure the NSS Network Settings.
    5. Download the NSS software.
    6. Start NSS.
    7. Verify the configuration.
    1. Copy the downloaded file from the admin portal to the Azure VM, using FTP, SCP or SFTP.
    2. Look up the public hostname or IP address of your instance in the Azure VM. 
    1. Use an SSH command such as follows to get shell access to the Azure VM:
      ssh zsroot@Public-Host-Name
    2. Use the following username/password: zsroot/zsroot.

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

    1. Copy the NssCertificate.zip file to the /home/zsroot root directory.
    2. Run the command sudo nss install-cert NssCertificate.zip.
    3. Check the configuration by running the command sudo nss dump-config.
    1. Enter the command netstat – rn and note down the Default gateway IP address. For example: 
      Destination Gateway





    1. Configure the NSS network (service interface only). You will be prompted for several IP configurations.
    2. Enter the command sudo nss configure and use the following inputs:
    • nameserver: (Options <c:change, d:delete, n:no change>): N
    • Do you wish to add a new nameserver? N
    • smnet_dev (Service interface IP address with netmask) []: Private IP address of the second network interface (service interface - eth1) created in the Azure VM.
    • smnet_dflt_gw (Service interface default gateway IP address) []: The default gateway IP address which you can find by running netstat -rn (e.g.

    On NSS on Azure, the first network interface (management network) is configured by default when you spin up the Azure VM. 

    You will need to download the NSS software, before starting the NSS service.

    1. Run the command sudo nss update-now to download and install the NSS binaries.
    2. After the first NSS software deployment, new versions of the software will be automatically upgraded.
    3. Run the command sudo nss checkversion to verify that the latest version was installed successfully. 

    Unless you are planning to use this instance for passive backup, run the command sudo nss start and do the following: 

    1. Ensure that the command shows that the NSS virtual appliance started successfully.
    2. It may take a few minutes for the NSS to start streaming logs to the SIEM.
    3. To enable the NSS to start automatically after a restart, run the command sudo nss enable-autostart.
    4. You can also explore other options by running sudo nss help.
    1. To verify the configuration, run the following command: sudo nss troubleshoot netstat|grep tcp.
    2. When the output of the command is displayed, verify that the following TCP connections are established in the following order:
      • Connection to the Zscaler cloud on port 9422: This is the control connection that is used to authenticate NSS to the Zscaler Central Authority and to download the configuration.
      • Connection to the SIEM: This is the long-lived TCP connection to the SIEM on the specified log data port. If there are multiple feeds configured, multiple connections must be listed.
      • Connection to the Zscaler cloud on port 9431: This is the data connection to the Nanolog so it can stream the logs.
    3. The absence of any one of the connections above, 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 NSS.

    An NSS feed specifies the data from the logs that the NSS will send to the SIEM. You can filter the data, so you send only the data you need to the SIEM. You can add one or more fields for the logs and one field for alerts. You can add up to eight NSS feeds for each NSS. Each feed can have a different list of fields, a different format, and different filters. Click a link below to learn how to configure each feed.

    You can also learn about:

    For full site redundancy, each organization can subscribe to up to two NSS servers for each type of traffic and deploy each pair in an active-active configuration. Each NSS supports up to eight parallel feeds. Each feed can have a different list of fields, a different format, and different filters.

    When you register a new NSS in the Zscaler service, you are required to download an SSL certificate, which you then upload to the new NSS that you configure. The newly configured NSS then uses the certificate to authenticate itself to the Zscaler service. You can configure one NSS as two virtual machines identified by the same certificate, as long as they do not try to connect to the Nanolog at the same time. One VM can be the active NSS and the other VM can be a cold standby. Zscaler strongly recommends against running both VMs as active because this will result in frequent connection resets and a failure to stream the logs.

    For completely redundant site configurations, if your organization has two SIEMs, Zscaler recommends using two NSS subscriptions, so both NSS VMs can stream logs to the SIEMs at the same time. Each NSS will run independently, with different configurations, and stream logs to two separate SIEMs. This is not recommended if you use a single SIEM, because each NSS will send copies of the same logs to the SIEM, which might not be able to remove the duplicates.