Contents
About Kaspersky SD-WAN
Kaspersky SD-WAN is used to build Software-Defined Wide Area Networks (Software Defined WAN; SD-WAN). In SD-WAN networks, routes with the lowest latency and the greatest bandwidth are determined automatically. Traffic is routed using the SDN (Software Defined Networking) technology.
The SDN technology separates the
from the and allows managing the network infrastructure using an and the API. Separating the control plane from the data plane makes it possible to virtualize network functions (Network Function Virtualization; NFV), wherein network functions such as firewalls, routers, and load balancers are deployed on standard equipment. Network function virtualization in the solution is compliant with the NFV MANO specification (NFV Management and Network Orchestration) standards of the European Telecommunications Standards Institute (ETSI).Building an SD-WAN network does not depend on transport technologies. You can also send traffic over multiple links based on application requirements regarding bandwidth and quality of service. The following underlay network types are supported:
- MPLS transport networks
- Broadband links for connecting to the Internet
- Leased communication lines
- Wireless connections including 3G, 4G, and LTE
- Satellite links
The solution is intended for service providers and organizations with a large branch network; it replaces standard routers in distributed networks
(hereinafter referred to as CPE devices, CPEs).Kaspersky SD-WAN lets you do the following:
- Intelligent traffic management
- Automatic CPE device configuration
- Central management of solution components using the web interface
- Network monitoring
- Automatically responding to changes in QoS policies to meet requirements of applications
The figure below shows a diagram of an SD-WAN network built using the Kaspersky SD-WAN solution.
SD-WAN network diagram
Distribution kit
To learn more about purchasing the solution, please visit the Kaspersky website (https://www.kaspersky.com) or contact partner companies.
The distribution kit includes the following components:
- knaas-installer_<version information> in the TAR.GZ format (hereinafter also referred to as the installation archive) for solution deployment.
- Docker containers for deploying Kaspersky SD-WAN components:
- knaas-ctl
- knaas-orc
- knaas-www
- knass-vnfm
- knaas-vnfm-proxy
- mockpnf
You must download the following containers from the common Docker repository:
- mariaDB
- mongo
- redis
- syslog-ng
- zabbix-proxy-mysql
- zabbix-server-mysql
- zabbix-web-nginx-mysql
- CPE device firmware.
- A file with the text of the End User License Agreement, which stipulates the terms and conditions that you must accept to use the solution.
- Kaspersky SD-WAN Online Help files that let you read documentation without an Internet connection.
The content of the distribution kit may differ depending on the region in which the solution is distributed.
Page topHardware and software requirements
Kaspersky SD-WAN has the following hardware and software requirements:
Hardware requirements depend on the number of CPE devices being managed (see the table below). If you need to connect more than 250 CPE devices, you need to deploy additional controllers. If you need to calculate hardware requirements for a specific deployment scheme more precisely, we recommend contacting Kaspersky Technical Support.
Solution component |
Virtual CPU |
RAM, GB |
Disk, GB |
IOPS |
---|---|---|---|---|
50 CPE devices |
||||
Redis replica server |
2 |
1 |
100 |
1000 |
Redis Sentinel system |
2 |
1 |
||
MongoDB database |
2 |
2 |
||
Orchestrator |
4 |
4 |
||
Virtual Network Function Manager (VNFM) |
2 |
1 |
||
Proxy Virtual Network Function Manager (VNFM proxy) |
2 |
1 |
||
Frontend part of the solution |
2 |
1 |
||
Database of the Zabbix monitoring system |
2 |
1 |
500 |
1000 |
Zabbix server |
2 |
1 |
||
Frontend part of the Zabbix monitoring system |
2 |
1 |
||
Zabbix proxy server |
2 |
1 |
||
Syslog server |
1 |
1 |
No value |
No value |
Data storage system |
8 |
8 |
20 |
1000 |
Controller |
8 |
8 |
64 |
1000 |
Total |
41 |
32 |
684 |
4000 |
100 CPE devices |
||||
Redis replica server |
2 |
1 |
100 |
1000 |
Redis Sentinel system |
2 |
1 |
||
MongoDB database |
4 |
4 |
||
Orchestrator |
4 |
4 |
||
Virtual Network Function Manager (VNFM) |
2 |
1 |
||
Proxy Virtual Network Function Manager (VNFM proxy) |
2 |
1 |
||
Frontend part of the solution |
2 |
2 |
||
Database of the Zabbix monitoring system |
4 |
1 |
1000 |
1000 |
Zabbix server |
2 |
1 |
||
Frontend part of the Zabbix monitoring system |
2 |
1 |
||
Zabbix proxy server |
2 |
1 |
||
Syslog server |
2 |
1 |
No value |
No value |
Data storage system |
8 |
8 |
20 |
1000 |
Controller |
8 |
8 |
64 |
1000 |
Total |
46 |
35 |
1184 |
4000 |
250 CPE devices |
||||
Redis replica server |
2 |
2 |
100 |
1000 |
Redis Sentinel system |
2 |
2 |
||
MongoDB database |
4 |
4 |
||
Orchestrator |
6 |
4 |
||
Virtual Network Function Manager (VNFM) |
2 |
2 |
||
Proxy Virtual Network Function Manager (VNFM proxy) |
2 |
2 |
||
Frontend part of the solution |
2 |
2 |
||
Database of the Zabbix monitoring system |
4 |
2 |
2500 |
1000 |
Zabbix server |
4 |
2 |
||
Frontend part of the Zabbix monitoring system |
2 |
2 |
||
Zabbix proxy server |
2 |
2 |
||
Syslog server |
2 |
2 |
No value |
No value |
Data storage system |
8 |
10 |
20 |
1000 |
Controller |
8 |
16 |
64 |
1000 |
Total |
50 |
54 |
2864 |
4000 |
500 CPE devices |
||||
Redis replica server |
2 |
2 |
100 |
1000 |
Redis Sentinel system |
2 |
2 |
||
MongoDB database |
6 |
4 |
||
Orchestrator |
6 |
6 |
||
Virtual Network Function Manager (VNFM) |
2 |
2 |
||
Proxy Virtual Network Function Manager (VNFM proxy) |
2 |
2 |
||
Frontend part of the solution |
2 |
2 |
||
Database of the Zabbix monitoring system |
4 |
2 |
5000 |
1000 |
Zabbix server |
4 |
2 |
||
Frontend part of the Zabbix monitoring system |
4 |
2 |
||
Zabbix proxy server |
4 |
2 |
||
Syslog server |
2 |
2 |
No value |
No value |
Data storage system |
8 |
10 |
20 |
1000 |
Controller |
8 |
32 |
128 |
1000 |
Total |
56 |
72 |
5248 |
4000 |
1000 CPE devices |
||||
Redis replica server |
4 |
2 |
100 |
1000 |
Redis Sentinel system |
2 |
2 |
||
MongoDB database |
6 |
6 |
||
Orchestrator |
6 |
8 |
||
Virtual Network Function Manager (VNFM) |
2 |
2 |
||
Proxy Virtual Network Function Manager (VNFM proxy) |
2 |
2 |
||
Frontend part of the solution |
2 |
2 |
||
Database of the Zabbix monitoring system |
6 |
2 |
1000 |
1000 |
Zabbix server |
6 |
2 |
||
Frontend part of the Zabbix monitoring system |
4 |
2 |
||
Zabbix proxy server |
4 |
2 |
||
Syslog server |
6 |
2 |
No value |
No value |
Data storage system |
10 |
12 |
20 |
1000 |
Controller |
8 |
64 |
256 |
1000 |
Total |
68 |
110 |
1376 |
4000 |
2000 CPE devices |
||||
Redis replica server |
4 |
4 |
200 |
2000 |
Redis Sentinel system |
2 |
4 |
||
MongoDB database |
6 |
8 |
||
Orchestrator |
6 |
10 |
||
Virtual Network Function Manager (VNFM) |
2 |
4 |
||
Proxy Virtual Network Function Manager (VNFM proxy) |
2 |
4 |
||
Frontend part of the solution |
4 |
4 |
||
Database of the Zabbix monitoring system |
6 |
4 |
2000 |
2000 |
Zabbix server |
6 |
4 |
||
Frontend part of the Zabbix monitoring system |
6 |
4 |
||
Zabbix proxy server |
6 |
4 |
||
Syslog server |
6 |
4 |
No value |
No value |
Data storage system |
12 |
16 |
20 |
1000 |
Controller |
8 |
128 |
512 |
1000 |
Total |
76 |
202 |
2732 |
6000 |
5000 CPE devices |
||||
Redis replica server |
4 |
6 |
500 |
5000 |
Redis Sentinel system |
2 |
6 |
||
MongoDB database |
6 |
10 |
||
Orchestrator |
6 |
12 |
||
Virtual Network Function Manager (VNFM) |
4 |
6 |
||
Proxy Virtual Network Function Manager (VNFM proxy) |
2 |
6 |
||
Frontend part of the solution |
4 |
8 |
||
Database of the Zabbix monitoring system |
8 |
6 |
5000 |
5000 |
Zabbix server |
8 |
6 |
||
Frontend part of the Zabbix monitoring system |
6 |
6 |
||
Zabbix proxy server |
6 |
6 |
||
Syslog server |
8 |
6 |
No value |
No value |
Data storage system |
16 |
32 |
50 |
1000 |
Controller |
8 |
320 |
1280 |
1000 |
Total |
88 |
390 |
6330 |
7000 |
10,000 CPE devices |
||||
Redis replica server |
4 |
8 |
1000 |
10,000 |
Redis Sentinel system |
2 |
8 |
||
MongoDB database |
8 |
12 |
||
Orchestrator |
8 |
16 |
||
Virtual Network Function Manager (VNFM) |
4 |
8 |
||
Proxy Virtual Network Function Manager (VNFM proxy) |
2 |
8 |
||
Frontend part of the solution |
4 |
8 |
||
Database of the Zabbix monitoring system |
8 |
32 |
10,000 |
10,000 |
Zabbix server |
8 |
16 |
||
Frontend part of the Zabbix monitoring system |
8 |
8 |
||
Zabbix proxy server |
8 |
8 |
||
Syslog server |
8 |
8 |
No value |
No value |
Data storage system |
32 |
64 |
100 |
1000 |
Controller |
8 |
640 |
2560 |
1000 |
Total |
112 |
844 |
13,660 |
22,000 |
The following table lists the hardware requirements that apply when a Kaspersky SD-WAN testbed is deployed in accordance with the all-in-one deployment scenario with 50 connected CPE devices.
Solution component |
CPU |
RAM, GB |
Disk, GB |
IOPS |
---|---|---|---|---|
Redis replica server |
0.5 |
1 |
4 |
500 |
Redis Sentinel system |
0.5 |
1 |
4 |
500 |
MongoDB database |
1 |
2 |
16 |
1000 |
Orchestrator |
2 |
4 |
4 |
500 |
Virtual Network Function Manager (VNFM) |
1 |
1 |
4 |
1000 |
Proxy Virtual Network Function Manager (VNFM proxy) |
1 |
1 |
4 |
500 |
Frontend part of the solution |
1 |
1 |
4 |
500 |
Database of the Zabbix monitoring system |
1 |
1 |
128 |
1000 |
Zabbix server |
1 |
1 |
4 |
500 |
Frontend part of the Zabbix monitoring system |
1 |
1 |
4 |
1000 |
Zabbix proxy server |
0.5 |
1 |
4 |
500 |
Syslog server |
0.5 |
1 |
32 |
1000 |
Controller |
4 |
8 |
32 |
1000 |
Operating system |
1 |
8 |
12 |
500 |
Total |
|
32 |
256 |
10,000 |
Third-party solution requirements
The following third-party solutions are necessary to deploy the solution:
- The Zabbix monitoring system versions 5.0.26 or 6.0.0. For details, please refer to the official documentation of the Zabbix solution.
- The Docker cloud platform version 1.5 or later for deploying Docker containers of solution components. For details, please refer to the official documentation of the Docker cloud platform.
- The OpenStreetMap service for viewing the transport service topology overlaid on a map. If the infrastructure of your organization does not provide for an Internet connection, you can use offline maps. Offline maps take up additional disk space:
- The offline map (central-fed-district-latest.osm.pbf) takes up approximately 100 GB.
- Geocoding data takes up approximately 10 GB.
For detailed information, please refer to the official documentation of the OpenStreetMap service.
Operating system requirements
The following 64-bit operating systems are supported:
- Ubuntu 22.04 LTS
- Astra Linux 1.7 (security level: "Orel").
- RED OS 7.3 "MUROM".
Requirements for deployment environments of solution components
The following deployment environments are supported for solution components:
- Physical servers (bare-metal servers):
- CPU Intel Xeon E5-2600 v2 or later or an equivalent CPU.
- IOPS 3000 or later.
- VMWare virtualization environment:
- Version 7.0 or later.
- The openvm-tools agent must be installed.
- IOPS 3000 or later.
- KVM virtualization environment:
Only the original KVM virtualization environment without additional orchestration tools is supported.
- Kernel version 5.15 or later.
- qemu-guest-agent must be installed.
- The CPU must be in host mode.
- IOPS 3000 or later.
Requirements for links between nodes of solution components
When deploying Kaspersky SD-WAN, you can deploy multiple nodes of solution components. The following requirements apply to links between nodes of solution components:
- Requirements for links between controller nodes:
- Bandwidth: 1 Gbps
- RTT (Round Trip Time): 200 ms or less
- Packet loss: 0%
- Requirements for links between MongoDB database nodes:
- Bandwidth: 1 Gbps
- RTT: 50 ms or less
- Packet loss: 0%
- Requirements for links between Redis database nodes:
- Bandwidth: 1 Mbps
- RTT: 50 ms or less
- Packet loss: 0%
Browser requirements
The following browsers are supported for managing the orchestrator web interface:
- Google Chrome 100 or later
- Firefox 100 or later
- Microsoft Edge 100 or later
- Opera 90 or later
- Safari 15 or later
Requirements for the data storage system
We recommend using your own data storage system for fault tolerance. The following requirements apply to the data storage system:
- Support for simultaneous read and write from multiple hosts.
- The size of the data storage system depends on the size of the files being stored, but at least 40 GB of available protected space that supports further expansion.
- The bandwidth of the link between the storage system and the orchestrator must be at least 1 Gbps; 10-Gigabit Ethernet or 8-Gigabit FC (Fiber Channel) is recommended.
- At least 250 IOPS, at least 400 is recommended.
- The following types of data storage systems are supported:
- NFS
- iSCSI
- FC
- CephFS
- The data storage system must be mounted.
- Must stay available if the host restarts.
Administrator device requirements
The administrator device for deploying the solution must satisfy the following requirements:
- Operating system:
- Ubuntu 20.04 LTS or 22.04 LTS
- RED OS 8.
The operating system must support internet access or contain a mounted disk image.
- 4 virtual CPU cores.
- 8 GB of RAM.
- 32 GB of free disk space.
- The name and password of root accounts must be the same on the administrator device and on the virtual machines or physical servers on which you want to deploy the solution components.
CPE device requirements
The following CPE device models are supported:
- KESR-M1-R-5G-2L-W
- KESR-M2-K-5G-1L-W
- KESR-M2-K-5G-1S
- KESR-M3-K-4G-4S
- KESR-M4-K-2X-1CPU
- KESR-M4-K-8G-4X-1CPU
- KESR-M5-K-8G-4X-2CPU
- KESR-M5-K-8X-2CPU
CPE devices of the KESR model are based on x86 (Intel 80x86) and MIPS (Microprocessor without Interlocked Pipeline Stages) processor architectures.
KESR M3–M5 CPE devices have Intel network adapters that are compatible with Intel SFP transceivers. For details about supported SFP transceivers, you can use the Intel Product Compatibility Tool
(in the territory of the Russian Federation, the link is accessible only via VPN). When using the Intel Product Compatibility Tool, you need to select one of the following product categories:- 500 Series to view SFP transceivers that are compatible with KESR M3 CPE devices.
- 700 Series to view SFP transceivers that are compatible with KESR M4–M5 CPE devices.
Kaspersky experts carried out tests to confirm the functionality of CPE devices when providing the L3 VPN service (see the table below). DPI (Deep Packet Inspection) was not used on the tested devices, and traffic encryption was disabled.
Model |
Packet size (bytes) |
Bandwidth (Mbps) |
---|---|---|
KESR-M1 |
IMIX (417) |
30 |
Large (1300) |
115 |
|
KESR-M2 |
IMIX (417) |
165 |
Large (1300) |
241 |
|
KESR-M3 |
IMIX (417) |
805 |
Large (1300) |
1150 |
|
KESR-M4 |
IMIX (417) |
1430 |
Large (1300) |
2870 |
For detailed information about the characteristics of CPE devices, please refer to the official page of the solution.
You can deploy uCPE devices on servers with x86 (Intel 80x86) or ARM64 processor architectures.
vCPE device requirements
The distribution kit includes the following firmware for deploying vCPE devices:
- vKESR-M1
- vKESR-M2
- vKESR-M3
- vKESR-M4
The following virtualization environments are supported for vCPE devices:
- VMware 7.0 or later
- KVM with kernel version 5.15 or later
Only the original KVM virtualization environment without additional orchestration tools is supported.
The following table lists the virtual resource requirements for deploying vCPE devices.
Firmware |
CPU |
RAM, GB |
Disk, GB |
---|---|---|---|
vKESR-M1 |
2 |
0.5 |
1 |
vKESR-M2 |
4 |
8 |
1 |
vKESR-M3 |
12 |
16 |
1 |
vKESR-M4 |
24 |
32 |
1 |
When upgrading Kaspersky SD-WAN from version 2.2 to 2.3, you need to make sure that your previously deployed vCPE devices satisfy the requirements of the new version, after which you can update your vCPE devices using the vKESR-M1-5 firmware.
Page topEnsuring security
Security in Kaspersky SD-WAN is ensured in the data plane, control plane, and orchestration plane. The security level of the solution as a whole is determined by the security level of each of these planes, as well as the security of their interaction. The following processes take place in each plane:
- User authentication and authorization
- Use of secure management protocols
- Encryption of control traffic
- Secure connection of CPE devices
Secure management protocols
We recommend using HTTPS when communicating with the SD-WAN network through the orchestrator web interface or API. You can upload your own certificates to the web interface or use automatically generated self-signed certificates. The solution uses several protocols to transmit control traffic to components (see the table below).
Interacting components |
Protocol |
Additional security measures |
Orchestrator and controller |
gRPC |
TLS is used for authentication and traffic encryption between the client and server. |
Orchestrator and CPE device |
HTTPS |
Certificate verification and a token are used for authentication and traffic encryption between the orchestrator and the CPE device. |
Controller and CPE device |
OpenFlow 1.3.4 |
TLS is used for authentication and traffic encryption between the controller and the CPE device. |
Secure connection of CPE devices
The solution uses the following mechanisms for secure connection of CPE devices:
- Discovery of CPE devices by DPIDs (datapath identifiers).
- Deferred registration. You can select the state of the CPE device after successful registration: Enabled or Disabled. A disabled CPE device must be enabled after making sure it is installed at the location.
- Two-factor authentication.
Using virtual network functions
You can provide an additional layer of security with virtual network functions deployed in the data center and/or on
. For example, traffic can be relayed from a CPE device to a virtual network function that acts as a firewall or proxy server. Virtual network functions can perform the following SD-WAN protection functions:- Next-Generation Firewall (NGFW)
- Protection from DDoS (Distributed Denial of Service) attacks
- Intrusion Detection System (IDS) and Intrusion Prevention System (IPS)
- Anti-Virus
- Anti-Spam
- Content Filtering and URL filtering system
- DLP (Data Loss Prevention) system for preventing confidential information leaks
- Secure Web Proxy
What's new
Kaspersky SD-WAN has the following new and improved functionality:
- GOST traffic encryption is supported on CPE devices of the KESR model.
- Improved link monitoring on CPE devices.
- Improved user authentication window.
- CPE device deletion method selection is now supported.
- The URL with basic CPE device settings now includes information about NTP servers.
- Added support for the vKESR-M1 model of CPE devices for KVM / ESXI hypervisors.
- Added support for the vKESR-M2 model of CPE devices for KVM / ESXI hypervisors.
- Added support for the vKESR-M3 model of CPE devices for KVM / ESXI hypervisors.
- Added support for the vKESR-M4 model of CPE devices for KVM / ESXI hypervisors.
- Added support for the OpenFlow dump utility for requesting dump-flows and dump-groups generated by virtual switches of CPE devices.
- Added support for link monitoring on CPE devices using the Connectivity Fault Management (CFM) functionality.
- Added support for resuming CPE device registration in case of an error.
- Added support for viewing the topology of CPE devices on the self-service portal.
- Added support for using a backup orchestrator when the primary orchestrator fails. You can specify the backup orchestrator when configuring the connection of the CPE device to the orchestrator and controller.
- Improved security of Docker containers of solution components.
- Added support for creating OpenFlow ports mapped to network interfaces on virtual switches. This allows establishing L2 connectivity between CPE devices.
- Added support for editing common firewall zones and firewall templates.
- Added support for editing kernel settings related to virtual routing and forwarding tables for a CPE device. This is necessary for correct operation of network services in user-created virtual routing and forwarding tables.
Known limitations
Kaspersky SD-WAN has the following limitations:
- Firewall rules do not work in user-created virtual routing and forwarding tables.
- When static routes are modified, the FRR daemon is restarted.
- NetFlow flows are not distributed across network interfaces.