Deploying Kaspersky SD-WAN

You can deploy Kaspersky SD-WAN using the knaas-installer_<version information> installation archive that is part of the distribution kit.

Before following this procedure, you must prepare a solution deployment scenario. If you have any problems with preparing a deployment scenario, we recommend contacting Kaspersky Technical Support.

A solution deployment scenario consists of the following steps:

1. Preparing the administrator device

   Prepare the administrator device for solution deployment. You can use a local or remote virtual machine, or a personal computer as the administrator device. When deploying a Kaspersky SD-WAN testbed in accordance with the all-in-one deployment scenario, you must use a virtual machine as the administrator device.

2. Ensuring network connectivity between the administrator device and solution components

   Ensure network connectivity between the administrator device and the virtual machines or physical servers on which you want to deploy Kaspersky SD-WAN components. If you plan to deploy multiple nodes of solution components, make sure that the links between virtual machines or physical servers satisfy the hardware and software requirements.

3. Manually generating passwords

   If necessary, manually generate passwords to ensure the security of Kaspersky SD-WAN components and their SSL certificates.

4. Preparing the configuration file

   Prepare the configuration file in accordance with the chosen deployment scenario. You can use example configuration files for typical deployment scenarios in the /inventory/external/pnf and /inventory/external/vnf directories of the installation archive.

5. Replacing the graphics of the orchestrator web interface

   If necessary, replace the graphics of the orchestrator web interface. For example, you can replace the image that is displayed in the background when an error occurs while logging into the orchestrator web interface.

6. Deploying Kaspersky SD-WAN

   Do the following on the administrator device:

   1. Accept the End User License Agreement by running the following command:

      export KNAAS_EULA_AGREED="true"

   2. Go to the directory with the extracted installation archive.
   3. If you want to deploy Kaspersky SD-WAN in attended mode, do one of the following:
      • If you have generated passwords manually, run the command:

        ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -K --ask-vault-pass knaas/knaas-install.yml

        When running the command, enter the root account password and the generated master password.

      • If you have not generated passwords manually, run the command:

        ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -K knaas/knaas-install.yml

   4. If you want to deploy Kaspersky SD-WAN in unattended mode, do one of the following:

      We only recommend using this mode in a trusted environment because it makes intercepting your passwords easy for a malicious actor.

      • If you have generated passwords manually, run the command:

        ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -e "ansible_become_password=yourSudoPassword" --vault-password-file ./passwords/vault_password.txt knaas/knaas-install.yml

      • If you have not generated passwords manually, run the command:

        ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -e "ansible_become_password=yourSudoPassword" knaas/knaas-install.yml

The Kaspersky SD-WAN components are deployed on the virtual machines or physical servers that you specified in the configuration file. A successful deployment message is displayed in the console of the administrator device.

If a network connectivity issue occurs with one of the virtual machines or physical servers during the deployment of solution components, an error message is displayed in the administrator device console, and the solution is not deployed. In that case, you need to restore network connectivity, clean up the virtual machines or physical servers, and then run the deployment command again.

Redundancy of solution components

Expand all | Collapse all

About redundancy schemes for solution components

Kaspersky SD-WAN supports two deployment scenarios for solution components:

• In the N+1 deployment scenario, you deploy two nodes of the solution component. If one node fails, the second node provides the functionality of the solution component.
• In the 2N+1 deployment scenario, you deploy multiple nodes of the solution component. One node is the primary node and the rest are secondary nodes. If the primary node fails, a randomly chosen secondary node takes its place. This redundancy scheme allows solution components to remain operational even when multiple failures occur in a row.

The table below lists the solution components and the deployment scenarios that are applicable to them.

You can specify the number of nodes you want to deploy for each solution component in the configuration file.

When you configure the deployment settings for the MongoDB database or the controller node in accordance with the 2N+1 deployment scenario, the last node you specify becomes the arbiter node. The arbiter node is linked to other nodes and is used to choose the primary node. A node that has lost contact with the arbiter node enters standby mode. One of the nodes that have retained contact with the arbiter node stays or becomes the primary node. An arbiter node cannot become a primary node and does not store data.

Failure scenarios of solution component nodes

The figure below shows a diagram of Kaspersky SD-WAN deployed on three virtual machines in a data center. The diagram uses the following symbols:

• 'www' is the frontend part of the solution
• 'orc' is the orchestrator
• 'mongo' is the MongoDB database
• 'redis-m' is a Redis replica server
• 'redis-s' is a Redis Sentinel system
• 'vnfm-proxy' is a virtual network functions manager proxy
• 'vnfm' is a Virtual Network Function Manager
• 'ctl' is the controller and its database
• 'zabbix-www' is the frontend part of the Zabbix monitoring system
• 'zabbix-proxy' is the Zabbix proxy server
• 'zabbix-srv' is the Zabbix server
• 'zabbix-db' is the database of the Zabbix monitoring system
• 'syslog' is the Syslog server

Users and CPE devices gain access to the web interface of the orchestrator and the web interface of the Zabbix monitoring system using a virtual IP address. The virtual IP address is assigned to virtual machine 1.

Solution deployed on three virtual machines

In this deployment scenario, the following failure modes are possible:

• Failure of virtual machine 1 or its link.

  If virtual machine 1 or its link fails, the solution remains operational. The following changes occur in the state of the nodes of solution components:

  • The virtual IP address is assigned to virtual machine 2.
  • The www-1 node of the frontend part of solution is unavailable; www-2 is available. The orchestrator web interface is displayed in the browser.
  • The orc-1 orchestrator node is unavailable; orc-2 is available. The backend part of the solution is functional, users can log into the orchestrator web interface and manage it.
  • The mongo-1 node of the MongoDB database is unavailable; mongo-2 and mongo-3 are available; mongo-2 becomes the primary node because mongo-3 is the arbiter node and cannot become the primary node. The orchestrator continues using the MongoDB database.
  • State of the Redis database:
    • The redis1-m node of the Redis replica server is unavailable; redis2-m and redis3-m are available.
    • The redis1-s node of the Redis Sentinel system is unavailable; redis2-s and redis3-s are available; redis2-s becomes the primary node and randomly assigns either the redis2-m or the redis3-m node of the Redis replica server as the primary node.

    The orchestrator continues using the Redis database.

  • States of the Virtual Network Function Manager:
    • The vnfm-proxy-1 node of the virtual network function manager proxy is unavailable; vnfm-proxy-2 is available.
    • The vnfm-1 Virtual Network Function Manager node is unavailable; vnfm-2 is available.

    SSH consoles of the solution components are operational.

  • The ctl-1 node of the controller is unavailable; ctl-2 and ctl-3 are available; ctl-2 becomes the primary node because ctl-3 is the arbiter node and cannot become the primary node. Physical connectivity between CPE devices is maintained.
  • State of the Zabbix monitoring system:
    • The zabbix-www-1 node of the frontend part of solution is unavailable; zabbix-www-2 is available.
    • The zabbix-proxy-1 node of the Zabbix proxy server is unavailable; zabbix-proxy-2 is available.
    • The zabbix-srv-1 node of the Zabbix server is unavailable; zabbix-srv-2 is available.
    • The zabbix-db-1 node of the Zabbix monitoring system database is unavailable; zabbix-db-2 is available.

    The Zabbix monitoring system is operational.

• Failure of virtual machine 2 or 3, or its link.

  If virtual machine 2 or 3 or its link fails, nodes of solution components that are deployed on virtual machine 1 stay primary, and the solution remains operational.

• Simultaneous failure of virtual machines 1 and 3 or 2 and 3, or their links.

  If virtual machines 1 and 3 or virtual machines 2 and 3, or their links fail simultaneously, the solution stops working. The following changes occur in the state of the nodes of solution components:

  • The orchestrator web interface is not displayed in the browser. Users cannot log into the orchestrator web interface and manage it.
  • The Zabbix monitoring system stops working.
  • Network connectivity between CPE devices and the network devices connected to them is maintained; traffic continues to be transmitted.
  • Network connectivity within the P2P services and TAP services is maintained.
  • Network connectivity within P2M services and M2M services is maintained for established sessions. For new sessions, network connectivity is maintained if, when creating the P2P service or M2M service, in the MAC learn mode drop-down list, you selected Learn and flood.
  • CPE devices use a reordering compensation mechanism to reduce the number of duplicate packets on network devices connected to these CPE devices.
  • The load on the CPE devices and the SD-WAN network increases proportionately to the number of CPE devices and links.

  If links are restored, the solution is also restored and resumes normal operation.

  If virtual machines 1 and 3 or virtual machines 2 and 3 fail simultaneously, the configuration of solution components is lost. To restore the configuration of solution components, you can contact Kaspersky Professional Services.

• Simultaneous failure of virtual machines 1 and 2

  If virtual machines 1 and 2 fail simultaneously, the configuration of the solution components is irreversibly lost because virtual machine 3 has arbiter that do not store data. To avoid this situation, we recommend deploying databases and controllers on separate virtual machines or physical servers and making regular backups.

About the installation archive

The knaas-installer_<version information> installation archive has the TAR format and is used for solution deployment. You can download the installation archive from the root directory of the distribution kit. The installation archive has the following structure:

We do not recommend editing system files because this may cause errors when deploying the solution.

• ansible.cfg file is a system file with Ansible settings.
• CHANGELOG.md is the file change log in YAML format.
• /docs contains the installation archive documentation.
• /images contains images of the solution components.
• /inventory:
  • /external:
    • /pnf contains example configuration files for typical solution deployment scenarios with the controller as a physical network function.
    • /vnf contains example configuration files for typical solution deployment scenarios with the controller as a virtual network function.
• /generic contains common system files.
• /knaas contains system files with playbooks for deploying the solution.
• /oem contains default graphics of the orchestrator web interface.
• /pnfs contains physical network functions for deployment of one, three, or five controller nodes.
• README.md contains instructions for deploying the solution using the installation archive.
• requirements.txt is a system file with Python requirements.

About the attended, unattended, and partially attended action modes

When you perform actions on the administrator device when deploying Kaspersky SD-WAN, you may need to enter the root password as well as the master password. How the passwords are entered depends on the mode in which you are performing the action. The following action modes are supported:

• In the attended mode, an employee must take part in the action. To perform an action, you must manually enter the root password and the master password. This is the safest mode that avoids saving any passwords on the administrator device.
• In the unattended mode, the action is performed without involving an employee. To perform an action, the root password and the master password are entered automatically. In this mode, you can run automated tests.

  We only recommend using this mode in a trusted environment because it makes intercepting your passwords easy for a malicious actor.

• In the partially attended mode, the action is performed with partial involvement of an employee. When performing an action, you must enter the root password, but the master password is entered automatically.

Preparing the administrator device

You can use a local or remote virtual machine, or a personal computer as the administrator device. When deploying a Kaspersky SD-WAN testbed in accordance with the all-in-one deployment scenario, you must use a virtual machine as the administrator device.

If you experience any problems while preparing the administrator device, we recommend contacting Kaspersky Technical Support.

To prepare the administrator device:

1. Make sure the administrator device satisfies the hardware and software requirements.
2. Make sure that the same root account is used on the administrator device and the virtual machines or physical servers on which you want to deploy Kaspersky SD-WAN components. After deploying the solution, you can use a different root account on the virtual machines or physical servers.
3. Download the knaas-installer_<version information> installation archive from the root directory of the distribution kit and extract the installation archive on the administrator device.
4. Go to the directory with the extracted installation archive and prepare the administrator device:
   1. Make sure the pip package management tool is installed by running the command:

      python3 -m pip -V

   2. If the pip package management tool is not present, do one of the following:
      • If the administrator device is running Ubuntu:

        apt-get install python3-pip

      • If the administrator device is running RED OS 8:

        yum install python3-pip

   3. Install the Ansible tool and its dependencies:

      python 3 -m pip install -U --user -r requirements.txt

   4. Update the PATH variable:
      1. echo 'export PATH=$PATH:$HOME/.local/bin' >> ~/.bashrc
      2. source ~/.bashrc
   5. Verify that the Ansible tool is ready for use:

      ansible --version

   6. Install the operating system packages for Kaspersky SD-WAN deployment on the administrator device:

      ansible-playbook -K knaas/utilities/toolserver_prepare/bootstrap.yml

      Enter the root password when running the command.

   You only need to complete this step when initially deploying the solution.

5. Make sure the administrator device is ready for use:
   1. Restart the administrator device.
   2. Go to the extracted installation archive and start the automatic check of the administrator device:

      ansible-playbook knaas/utilities/pre-flight.yml

6. If you want to deploy Kaspersky SD-WAN on multiple virtual machines or physical servers:
   1. Make sure SSH keys have been generated on the administrator device. If the SSH keys do not exist, generate them.
   2. Place the SSH keys on virtual machines or physical servers:

      ssh-copy-id user@<IP address of the virtual machine or physical server>

   If you are deploying a Kaspersky SD-WAN testbed in accordance with the all-in-one deployment scenario, skip this step.

The administrator device is prepared for Kaspersky SD-WAN deployment.

Managing passwords

Passwords help ensure the security of deployed Kaspersky SD-WAN components. You can manually generate the passwords. If you do not manually generate the passwords, they are generated automatically when you deploy the solution.

Passwords are contained in the following files:

• keystore.yml contains passwords of Kaspersky SD-WAN components and their SSL certificates.
• vault_password.txt contains the master password.

We recommend storing password files in a protected directory because they can be used to gain access to the deployed solution.

After deployment, the generated passwords are automatically placed in the Docker containers of Kaspersky SD-WAN components. Solution components exchange passwords when interacting with each other.

Manually generating passwords

To manually generate the passwords:

1. Create the /passwords directory on the administrator device. Specify the path to the created directory in the external section of the configuration file using the vault_password_dirname setting.
2. Create a keystore.yml file and in that file, specify the passwords using the following settings:
   • ZABBIX_DB_SECRET is the root password of the Zabbix monitoring system database.
   • MONGO_ADMIN_SECRET is the administrator password of the MongoDB database.
   • MONGO_USER_SECRET is the user password of the MongoDB database. This password is used by the orchestrator.
   • CTL_CERT_SECRET is the password of the controller SSL certificate.
   • ORC_CERT_SECRET is the password of the orchestrator SSL certificate.
   • ORC_ENC_SECRET is the password for encrypting confidential data in the MongoDB database. Minimum length: 32 characters.
   • VNFM_CERT_SECRET is the password of the VNFM SSL certificate.

   For all passwords except ORC_ENC_SECRET, we recommend specifying at least 16 characters.

3. Create the vault_password.txt file and in that file, specify the master password.
4. Encrypt the keystore.yml file:
   • If you want to encrypt the keystore.yml file in attended mode:

     ansible-vault encrypt --ask-vault-pass keystore.yml

   • If you want to encrypt the keystore.yml file in unattended mode:

     ansible-vault encrypt --vault-password-file vault_password.txt keystore.yml

The passwords are generated and encrypted.

Changing passwords

To change the passwords:

1. Decrypt the keystore.yml file:
   • If you want to decrypt the keystore.yml file in attended mode:

     ansible-vault decrypt --vault-password-file vault_password.txt keystore.yml

   • If you want to decrypt the keystore.yml file in unattended mode:

     ansible-vault encrypt --ask-vault-pass keystore.yml

2. Change the following passwords in the keystore.yml file:
   • ZABBIX_DB_SECRET is the root password of the Zabbix monitoring system database.
   • MONGO_ADMIN_SECRET is the administrator password of the MongoDB database.
   • MONGO_USER_SECRET is the user password of the MongoDB database. This password is used by the orchestrator.
   • CTL_CERT_SECRET is the password of the controller SSL certificate.
   • ORC_CERT_SECRET is the password of the orchestrator SSL certificate.
   • ORC_ENC_SECRET is the password for encrypting confidential data in the MongoDB database. Minimum length: 32 characters.
   • VNFM_CERT_SECRET is the password of the VNFM SSL certificate.

   For all passwords except ORC_ENC_SECRET, we recommend specifying at least 16 characters.

3. Encrypt the keystore.yml file:
   • If you want to encrypt the keystore.yml file in attended mode:

     ansible-vault encrypt --ask-vault-pass keystore.yml

   • If you want to encrypt the keystore.yml file in unattended mode:

     ansible-vault encrypt --vault-password-file vault_password.txt keystore.yml

The passwords are changed and encrypted.

Preparing the configuration file

Specify the Kaspersky SD-WAN deployment settings in the YAML configuration file on the administrator device. The path to the configuration file must be specified when deploying the solution. You can use example configuration files for typical deployment scenarios in the inventory/external/pnf and inventory/external/vnf directories of the installation archive.

The configuration file consists of two main sections:

• The nodes section specifies virtual machines or physical servers for deploying Kaspersky SD-WAN components. When deploying the solution to virtual machines or physical servers, iptables rules for interaction between solution components are automatically generated.
• The external section specifies Kaspersky SD-WAN deployment settings.

We do not recommend changing the default settings.

The nodes section has the following structure:

The external section has the following structure:

Example of configuration file

Replacing the graphical elements of the orchestrator web interface

To replace the graphics of the orchestrator web interface:

1. Configure the frontend part of the solution in the www section of the configuration file.
2. On the administrator's device, go to the /oem directory of the extracted installation archive. This directory contains the default graphics of the orchestrator web interface. You can replace the following files:
   • favicon.png and favicon.svg is the icon that is displayed on the orchestrator web interface tab.

     

   • login_logo.svg is the icon that is displayed in the upper part of the window when logging in to the orchestrator web interface.

     

   • logo_activation.svg is the icon that is displayed during the automatic registration of a CPE device.

     

   • logo.svg and title.svg are the icon and title that are displayed in the upper part of the navigation pane of the orchestrator web interface.

     

Replacement of a failed controller node

You can deploy a new controller node to replace a controller node that has failed beyond repair. If a controller node fails while in a cluster with other nodes, the new controller node is automatically added to that cluster and synchronized with the existing nodes.

Before running this script, make sure that the IP address of the virtual machine or physical server on which you are deploying the new controller node is the same as the IP address of the virtual machine or physical server where the failed controller node was deployed. You specified the IP addresses of the virtual machines or physical servers for deployment of controller nodes when you deployed the solution, in the ctl section of the configuration file.

The scenario for replacing a failed controller node involves the following steps:

1. Preparing the administrator device

   Prepare the administrator device for deployment of the new controller node. You can use a local or remote virtual machine, or a personal computer as the administrator device. When deploying a Kaspersky SD-WAN testbed in accordance with the all-in-one deployment scenario, you must use a virtual machine as the administrator device.

2. Ensuring network connectivity between the administrator device, solution components, and the new controller node

   Ensure network connectivity between the administrator device, solution components, and the virtual machine or physical server on which you want to deploy the new controller node. You must make sure that the links between virtual machines or physical servers satisfy the hardware and software requirements.

3. Deploying a controller node

   Do the following on the administrator device:

   1. Accept the End User License Agreement by running the following command:

      export KNAAS_EULA_AGREED="true"

   2. Go to the directory with the extracted installation archive.
   3. If you want to deploy the new controller node in attended mode, do one of the following:
      • If you have generated passwords manually while deploying the solution, run the following command:

        ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -K --ask-vault-pass knaas/knaas-install.yml

        When running the command, enter the root account password and the generated master password.

      • If you have not generated passwords manually while deploying the solution, run the following command:

        ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -K knaas/knaas-install.yml

   4. If you want to deploy the controller node in unattended mode, do one of the following:

      We only recommend using this mode in a trusted environment because it makes intercepting your passwords easy for a malicious actor.

      • If you have generated passwords manually while deploying the solution, run the following command:

        ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -e "ansible_become_password=yourSudoPassword" --vault-password-file ./passwords/vault_password.txt knaas/knaas-install.yml

      • If you have not generated passwords manually while deploying the solution, run the following command:

        ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -e "ansible_become_password=yourSudoPassword" knaas/knaas-install.yml

The new controller node is deployed to replace the failed controller node. A successful deployment message is displayed in the console of the administrator device.

If a network connectivity problem occurs with a virtual machine or physical server while deploying the controller node, an error is displayed in the console of the administrator device, and the new controller node is not deployed. In that case, you need to restore network connectivity, clean up the virtual machine or physical server, and then run the deployment command again.

Upgrading Kaspersky SD-WAN

Before updating Kaspersky SD-WAN, make sure that none of the CPE devices have the Error status. You can view the status of CPE devices in the CPE device table. We also recommend creating backup copies of solution components before updating Kaspersky SD-WAN:

• If your solution components are deployed on virtual machines, take snapshots of the virtual machines. After updating Kaspersky SD-WAN, you can delete the snapshots of the virtual machines. For details on how to take snapshots of virtual machines, please refer to the official documentation of your virtualization environments.
• If your solution components are deployed on physical servers, you need to make backups of hard drives of the physical servers.

The Kaspersky SD-WAN upgrade scenario involves the following steps:

1. Preparing the administrator device

   Prepare the administrator device for solution upgrade. You can use a local or remote virtual machine, or a personal computer as the administrator device. When deploying a Kaspersky SD-WAN testbed in accordance with the all-in-one deployment scenario, you must use a virtual machine as the administrator device.

2. Preparing the configuration file

   Set up the configuration file in accordance with the changes that have been made to the new version of Kaspersky SD-WAN. You can view the changes in the in the CHANGELOG.md file in the root directory of the installation archive.

   When upgrading Kaspersky SD-WAN, make sure that you keep the files with passwords and SSL certificates.

3. Upgrading Kaspersky SD-WAN

   Upgrade Kaspersky SD-WAN in one of the following ways:

   • If you want to upgrade the solution in attended mode:

     ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -K --ask-vault-pass knaas/knaas-install.yml

     When running the command, enter the password of the root account on the administrator device and the generated master password.

   • If you want to upgrade the solution in partially attended mode:

     ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -K --vault-password-file ./passwords/vault_password.txt knaas/knaas-install.yml

     Enter the root password o the administrator device when running the command.

   • If you want to upgrade the solution in unattended mode:

     ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -e "ansible_become_password=yourSudoPassword" --vault-password-file ./passwords/vault_password.txt knaas/knaas-install.yml

The Kaspersky SD-WAN components are upgraded on the virtual machines or physical servers that you specified in the configuration file. A successful upgrade message is displayed in the console of the administrator device.

If a network connectivity issue occurs with one of the virtual machines or physical servers during the upgrade of solution components, an error message is displayed in the administrator device console, and the solution is not upgraded. In that case, you need to restore network connectivity and then run the upgrade command again.

After upgrading the solution, you must clear your Bash command history.

Removing Kaspersky SD-WAN

The removal of Kaspersky SD-WAN cannot be rolled back.

To remove Kaspersky SD-WAN:

1. On the administrator device, go to the extracted installation archive.
2. Remove Kaspersky SD-WAN in one of the following ways:
   • If you want to remove the solution in attended mode:

     ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -K knaas/knaas-teardown.yml

   • If you want to remove the solution in unattended mode:

     ansible-playbook -i inventory/generic -e "@<path to configuration file>" -e "@inventory/external/images.yml" -e "ansible_become_password=yourSudoPassword" knaas/knaas-teardown.yml

Kaspersky SD-WAN components are removed from the virtual machines or physical servers. A successful removal message is displayed in the console of the administrator device.

If a network connectivity issue occurs with one of the virtual machines or physical servers during the removal of solution components, an error message is displayed in the administrator device console, and the solution is not removed. In that case, you need to restore network connectivity and then run the removal command again.