Continental TLS VPN implementation experience in a cluster configuration

    Hello, Habr! We faced the challenge of introducing the Continent TLS VPN product of the Security Code company. In this article we share our experience in implementing this product.


    TLS is a cryptographic protocol that provides secure data transfer between nodes on the Internet. You can find it here or here .

    Key TLS Tasks:

    1. ensure confidentiality, that is, implement protection against leaks of transmitted information;
    2. provide detection of substitution, that is, implement the preservation of the integrity of the transmitted information;
    3. provide authentication of nodes, that is, give a mechanism for authenticating the message source.

    This protocol is widely used in applications working with the Internet, such as web browsers, e-mail, instant messaging and IP-telephony (VoIP).


    In our case, it was necessary to provide access to a web resource protected by GOST encryption.


    • Cluster configuration (solution requires high fault tolerance)
    • High throughput
    • Support for various browsers (IE, Mozilla, Chrome)
    • The maximum number of connections in HTTPS proxy mode is 10,000
    • Certificate of the Federal Security Service of Russia at SKZI


    Below is a diagram and description of the components.

    To solve this problem, the “Security Code” Continental TLS VPN product was selected that meets all of the above conditions.

    It is worth noting that at the time of design it was the only certified PAC that performs encryption in accordance with GOST using the TLS protocol. In the future, it is expected to receive the ViPNet TLS PAK certificate from InfoTex.

    The main elements of the system:

    • CIPF “Continent TLS VPN Client”, version 1.2.1068
    • Load Balancer, Netscaler v12
    • SKZI "Continent TLS VPN Server", version

    Item Description

    SKZI “Continent TLS VPN Client” - a TLS client is a software installed on a remote user’s computer that functions in conjunction with a TLS server. The TLS client is designed to provide remote users with secure access to corporate network web resources via communication channels of common data transmission networks.

    NetScaler is an application delivery controller that provides flexible service delivery for traditional, container and microservice applications from a data center or any cloud. A Citrix-based Netscaler balancer spans HTTPS sessions between TLS server clusters. Responses from the WEB server are also collected by the balancer.

    CPSI “Continent TLS VPN Server” - the server is designed to provide secure access for remote users to protected resources.

    Setting procedure

    1. We initialize the TLS server, configure the cluster, create certificate requests for the TLS server (root CA certificate, server certificate, certificate for remote server management, administrator certificate and CRL).
    2. Initial setup of TLS servers, import of certificates.
    3. Checking the connection to the protected resource of the remote client using the TLS VPN Client.


    The first difficulty arose when starting TLS servers. The message “No controller found” appeared. Together with the specialists of the Security Code company, a rather non-standard problem was identified. It turned out that the PAK refused to work in the data center with BenQ monitors, and worked with any others without problems.

    The initial setup is simple and consists mainly of determining the ip-address and gateway, as well as the name of the device. Plus creation, export / import of a master key.

    The customer in the project used two TLS servers. Both TLS servers must be active-active.

    A master key is created on one server; it is imported to other servers. The master key (cluster key) is designed to solve the following problems:

    • encryption of private keys of server certificates;
    • Organization of a secure connection between cluster elements.

    When exporting the master key, the TLS server accepted only a single USB flash drive from Transcend 3.0 4GB. Unfortunately, no flash drives, even those that came with the Security Code, came up.

    Certificate Import

    Next, you need to connect to the TLS server via the web-face, determine the protected resource and install certificates for the servers (root CA certificate, server certificate, certificate for remote server management, administrator certificate and CRL). All these certificates must be issued by one CA. For the first connection via the web, you need to use CryptoPro CSP, and not the “CSP Security Code. At subsequent changes of certificates, it is better to first delete the CA root certificate, and then change other certificates.

    Due to the impossibility of immediately making combat certificates, it was decided to check the operability of the cluster of TLS servers on certificates made at the test CA Cryptopro.

    On TLS servers, it is possible to disable user authentication. In this case, a secure channel will be created if there is a TLS client and installed certificates (root, server certificate and CRL), i.e. a personal certificate is not required for work.

    Connection check

    Initially, there were problems connecting via a secure channel to a protected resource using a certified version of the TLS client from the Security Code. It turned out to connect to the protected resource using the TLS client 2.0 from the Security Code, but this version is still at the certification stage. The problem was an incorrect redirect on the protected resource, which did not pass, because the TLS servers did not work out this rule correctly in the release version of the firmware. To solve the problem, it was necessary to reflash both TLS servers and raise the backups made.

    The flashing procedure is as follows:

    • save the server database (so as not to create everything over again)
    • upload image to Flash using flashGUI program
    • we enter the BIOS, first in the settings of the Sobol PAC we set the response time of the watchdog timer, sufficient to make a change in the settings in the BIOS
    • change the boot order, set the boot from Flash, save
    • at start there will be a message about changing partitions, we agree
    • during installation, select the debug version and the platform you use
    • reboot, enter the BIOS, change the installation order, agree with the change
    • configure the server locally
    • connect to the server
    • load base

    To enter debug mode on the TLS server, press the F2 key.
    For version 1.2, the file / usr / share / tls / webmgr / templates / websrv / nginx / base
    Remove the proxy_redirect line from it and recalculate the checksums.

    After the operations completed, a certified TLS client from the Security Code was launched, and the customer insisted on working in the system. But here is the trick, it did not work in the Chrome browser, the work in which was simply necessary for the customer, you can even say that everything was sharpened for him. A number of tests were conducted in conjunction with the support of the Security Code, and as a result, everything worked on a slightly newer version (1.2.1073) than the certified one (1.2.1068).

    By the way, one of the pitfalls when setting up any TLS client from the Security Code (except for version 2.0) - they do not work on virtual machines. During testing, virtual machines were often used, which further complicated the diagnostic process.


    In the end, I would like to summarize. The product is simple to set up and deploy. There is still something for developers to work on, this applies to both the server and the client. But in general, the product is working and works in a cluster configuration. The system currently works without failures and holds the load. We hope that our full cones will help you deploy the Continent TLS faster and more efficiently.

    The article was prepared by Ilya Platonov.

    Also popular now: