ViPNet in detail: understanding the features of a crypto gateway / Rostelecom-Solar Blog / Sudo Null IT News

ViPNet Office Firewall

A software firewall designed to control and manage traffic and traffic transformation (NAT) between segments of local networks during their interaction, as well as during the interaction of local network nodes with public network resources.

Usage scenarios:

Controlling access to Internet resources from the local network.

In addition to protecting local network computers from unauthorized access over a network connection, ViPNet Office Firewall allows you to prohibit access to the Internet for certain local network computers whose users do not require such access for business needs, or allow individual computers to work on the network only with certain services, for example, email servers. In this case, it is enough to set filters for computer IP addresses or address ranges and indicate that traffic from these addresses should be blocked or allowed.

Protection of multiple local networks and DMZ.

ViPNet Office Firewall provides work with several network interfaces, allowing you to combine subnet segments, and for each network adapter you can set its own operating mode and filters. It is also possible to organize a so-called “demilitarized zone” (DMZ), in which servers can be placed that are open to access from the Internet. In this case, outgoing traffic from the DMZ to local networks connected to other internal adapters can be completely blocked.

ViPNet product lines

ViPNet CUSTOM

The most extensive product line of the enterprise level is a designer of secure networks, offering a solution to the full range of tasks for organizing VPN and PKI. The products included in ViPNet CUSTOM are regularly certified according to the requirements of the FSB and FSTEC of Russia for means of protecting restricted access information (confidential information), including personal data. This allows the use of these products in both commercial and government companies and organizations. ViPNet CUSTOM products are designed for use in a wide variety of conditions of modern multiservice communication networks - from local networks with several dozen computers to global, geographically distributed data networks with tens of thousands of network nodes using the Internet as a transport medium. All ViPNet CUSTOM products are designed to work as part of a single set of ViPNet information security tools. Autonomous use of these products is not envisaged[2].

ViPNet BOX

The ViPNet BOX product line includes “boxed” products certified by the FSB and FSTEC of Russia according to the requirements for means of protecting restricted access information. By “boxed” we mean the possibility of autonomous operation of these products without the need to organize a secure network with a single control center. Products from the ViPNet BOX line are recommended for use in government information systems or commercial organizations where the task is to protect dedicated computers, without the need to protect the network as a whole. The only exception to this line is the ViPNet OFFICE software package, which is a simplified version of ViPNet CUSTOM in terms of deployment and management.

VipNet BOX Lite

The VipNET BOX Lite line contains all non-certified “boxed” products. These products are not inferior in functionality to their counterparts from the ViPNet BOX line, but are much more affordable for the end consumer. ViPNet BOX Lite products are designed for individual use on mobile and personal computers. They can be purchased at the Softkey online store. Some products in this line are completely free.

ViPNet information security tools, due to their comprehensive nature, can be used in many different scenarios for solving information security problems.

Installing ViPNet Office Firewall

Before installing the ViPNet Office Firewall program, you must make sure that the standard network settings are configured on your computer, and that the time zone, date and time are set correctly. Administrator rights are required for installation. Before installing ViPNet Office Firewall, make sure that no other firewalls are installed on your computer. If such programs are installed, you need to remove them and restart your computer before installing ViPNet Office Firewall. Using ViPNet Office Firewall simultaneously with other firewalls can lead to program conflicts and cause problems with network access.

To install ViPNet Office Firewall, follow these steps:

1) Run the installation file included in the package. Wait until preparations for installing ViPNet Office Firewall are completed.

2. Read the terms of the license agreement. If you agree, check the appropriate box. Then click the Continue button.

3. If you want to customize installation options, click the Customize button and specify:

• ViPNet Office Firewall components that need to be installed;

• path to the installation folder of ViPNet Office Firewall components on the computer;

• user name and organization name;

• name of the folder for the ViPNet Office Firewall program in the Start menu.

4. To start installing ViPNet Office Firewall, click the Install Now button.

5. If, after installation is complete, you receive a message asking you to restart your computer, restart.

Starting the program

The ViPNet Office Firewall program can be launched by the user independently or automatically when loading the Windows operating system (by default, the program starts automatically).

If the program is not registered, a window will open asking you to register ViPNet Office Firewall. You can proceed to register the program or run the unregistered version.

3. The user authorization window will open. Enter the user password and click OK.

When you launch ViPNet Office Firewall for the first time, the default password will be automatically entered in the user authorization window. After logging into the program, you can change your password.

After logging into the program, the ViPNet Monitor and ViPNet Application Control components will be launched and the main ViPNet Office Firewall (ViPNet Monitor) window will open.

On the left is the navigation bar. On the right is the section view panel. At the bottom there is a status bar containing the following information: host IP addresses and the current program configuration.

The navigation panel contains a list of sections intended for configuring various parameters of ViPNet Office Firewall:

• network filters—contains subsections with IP traffic filters:

• transit filters - designed to configure transit traffic filters;

• local filters - designed to configure local traffic filters;

• address translation—designed to set rules for translating nodes' IP addresses.

• object groups—contains lists of objects that can be used to create network filters: groups of IP addresses, groups of protocols, and so on;

• network interfaces – contains network interfaces installed on the computer;

• statistics and journals;

• configurations – designed to manage configurations of the ViPNet Office Firewall program;

• administrator – is displayed only after logging into the program in administrator mode and is used to configure additional program settings.

The section view panel is designed to display the section selected in the navigation panel.

ViPNet Personal Firewall 4 software (FSB certificate)

Category: Firewalls Version: Software package Operating system type: Windows (desktop & server)

government agencies and organizations, certified by the FSB of Russia as a means of protection against unauthorized access

ViPNet Personal Firewall is a reliable means of protecting your computer and personal data from network attacks and theft of personal information when connected to the Internet and local network. Personal Firewall is certified by the FSB of Russia as a means of protection against unauthorized access and can be used in government agencies and organizations, providing both a high level of computer and data security, as well as flexibility of management and ease of use.

Security:

“Boomerang” security mode to allow access to the network only at the user’s initiative.
Protection against spyware and Trojans.
Intrusion detection and attack blocking system (IDS).
Identifying sources of network attacks.

Control flexibility:

Allow or prohibit the creation of network connections for individual programs.
Preset security modes that guarantee a high level of protection immediately after installing the program.
Flexible management of filtering rules makes it easy to allow or deny connections on specified protocols and ports.

Ease of use:

Supports various methods of connecting to the network - home networks, Stream (MTU-Intel JSC), regular modem connection, wireless communication technologies (GPRS, Wi-Fi).
An online software update system that informs you about the release of new versions and provides downloads of updates necessary to install new versions and containing both new functions and bug fixes.
Web filtering that blocks pop-ups, various advertising banners, interactive elements (Java and ActiveX applications, Flash animation, JavaScript and VB Script) and user personalization elements (Referrer and Cookie).
Informative log of IP packets for studying and troubleshooting network failures.

Main advantages of the program:

Readiness for work immediately after installation without additional settings is ensured by the presence of built-in rules and filters for DHCP, the Microsoft network, and proactive connection mode.
The ability to separately filter network traffic and control network activity of programs helps reduce the load on the computer and simplify the setup process.
Enhanced protection for logging into the operating system and quickly blocking computer and IP traffic.
The mandatory authorization mode when starting the operating system will not allow you to log in without entering the program password.
An IP packet log that records detailed information about a computer's network activity.
Integration with Security Center (a component of Microsoft Windows XP SP2) allows you to obtain objective information about the state of your computer's protection.
Ability to quickly block network traffic and desktop traffic.
Operation of network filters according to a predetermined schedule, allowing you to flexibly manage and limit the cost of paying for communication channels.
Support for the FTP protocol to ensure that FTP clients can operate in active mode, as well as filtering FTP protocol commands to protect against the use of incorrect client and server IP addresses.
SIP protocol support for automatically opening ports that are necessary for the operation of SIP clients that provide VoIP telephony.
The program uses ViPNet technologies that have passed state certification (as part of other company products).

System requirements:

Pentium III 500 MHz processor and higher;
at least 512 MB of RAM;
100 MB of free hard disk space;
operating system Microsoft Windows 2000/XP (all line) / Vista (all line) 32-bit;
Internet Explorer version 6.0 and higher.

Technical support

The product includes free annual technical support, including: Program updates when new versions are released. Consultations on using the program via email ( [email protected] ). After free support ends, it can be extended for a fee.

Screenshots

Blocked IP Packets

IP Packet Log

Setting up banner blocking

Certificate of conformity of the Federal Security Service of Russia No. SF/115-1783 dated December 20, 2011 Validity period: December 20, 2014

The ViPNet Personal Firewall product meets the FSB requirements for firewall devices of security class 4.

Configuring the ViPNet Office Firewall

In the ViPNet Office Firewall program, all traffic that passes through a network node is filtered.

Traffic can be local or broadcast. Local traffic refers to incoming or outgoing traffic of a specific node (that is, when a network node is the sender or recipient of IP packets). Broadcast traffic refers to the transmission by a node of IP packets whose destination IP address or MAC address is a broadcast address (that is, the transmission of packets to all nodes of a certain network segment).

In addition, transit traffic can pass through the firewall. The firewall is neither the sender nor the recipient of transit IP packets that travel through it to other hosts.

The greatest danger can come from traffic from the Internet, where the source of the attack is very difficult to detect if the attacker is skillful. In order to properly configure network filters, you need to understand the basic principles of traffic filtering.

All incoming and outgoing IP packets undergo a comprehensive check in accordance with network filters. If the IP packet has an address allowed by the anti-spoofing rule, the packet is allowed through. Otherwise, it is blocked. Checking in accordance with network filters If an IP packet matches the parameters of one of the available network filters, then it is passed or blocked in accordance with this filter. If a packet does not match any of the specified filters, it is blocked.

This filtering principle provides a high level of security, allowing connections only to the necessary hosts using the specified protocols and ports. An IP packet sequentially passes through a number of filters in accordance with their priority until it is passed or blocked by one of them. Once a packet is allowed through or blocked, all subsequent filters are no longer in effect. If the packet has not been processed by any filter, then it is blocked.

General information about network filters

All network filters (see “Surge line filter” on page 131) are divided into the following categories:

• Preset filters and user-defined filters - available for editing by the user;

• Default filters are not editable.

Preset and default filters are created automatically by ViPNet Office Firewall during installation. Preset filters and user-defined filters in ViPNet Office Firewall have higher priority than default filters. They can always be changed or deleted. The default filters are represented by one network filter that blocks IP traffic, which does not match any of the network filters in the first category.

The list of network filters is presented in the viewing panel in the ViPNet Office Firewall program window in the Network Filters section.

Surge filters have the following features:

• Filters include the following parameters:

— Action applied to IP packets. Filters can allow or block IP packets that match specified parameters;

— Source and destination of IP packets that are subject to the filter;

— IP packet filtering protocols;

— Action schedule.

Groups of objects can be used to set filter parameters.

• To change the filter action, double-click the filter properties and, under Basic Settings, select the desired value. To enable or disable a filter, select or clear the check box next to the filter name.

• IP packets are checked according to the location of the filters in the list, in order from top to bottom. Once a packet is blocked or passed by the first matching filter, subsequent filters have no effect on that packet.

• In the ViPNet Office Firewall program, filters of various categories in the filter lists are displayed in the corresponding groups and are arranged in order of their priority according to the diagram above. The default filter order cannot be changed. You can change the order of preset filters and filters specified in ViPNet Office Firewall.

• User-defined filters affect both new and existing connections. Thus, if a filter blocking connection traffic is added after the connection has been established, the connection will be terminated.

Checking the ban

By default, ViPnet is configured to deny everything except what is allowed. The ping command is carried out using the icmp protocol.

1) Open Start on wkstnn, click run and write cmd.

2) The command line opens. Enter the command ping 192.168.0.1 there.

3) Thus, ping showed that the node is unavailable.

4) Scan the ports using the Nmap program.

5) The result of the scan is the conclusion that nmap cannot determine the ports.

Creating network filters (for passing ICMP packets)

The ViPNet Office Firewall program provides the ability to create network filters.

To create a network filter, follow these steps:

1) In the ViPNet Office Firewall program window, in the navigation panel, select the section of the type of filters you want to create.

2) On the view panel, click the New button. The network filter properties window will open, in which you can set the parameters of the new filter.

3) In the Basic Settings section, do the following:

• Enter the filter name in the appropriate field (name – filter2);

• Specify the action of the new filter by setting the switch to Pass.

4) In the Sources section, specify the sender of the IP packets to which the

extend the filter action. To do this, add:

• IP address (192.168.0.2) or DNS name of the sender or range of addresses, if there are several;

• Groups of sender IP addresses, if any have been created;

• System object group My Site. In this case, the filter will apply to outgoing open connections from your node.

• System object group Other nodes. In this case the filter will be

act on incoming open connections from your node.

If you do not specify the sender, the filter will apply to IP packets sent by any nodes, including your node.

5) In the Destinations section, specify the recipient of IP packets that will be affected by the filter. To do this, add the My Site system object group. In this case, the filter will apply to incoming open connections from your node;

If you do not specify a recipient, the filter will apply to IP packets sent to any host.

6) In the Protocols section, specify the protocol for ICMP filtering. In this case, the filter will process only ICMP packets transmitted using the specified protocol. Click apply.

ICMP packet inspection

1) Open the command line on wkstnn and enter the command ping 192.168.0.1.

2) We will see the unimpeded passage of ICMP packets.

Creating network filters (for port scanning)

To create a network filter, follow these steps:

1) In the ViPNet Office Firewall program window, in the navigation panel, select the section of the type of filters you want to create.

2) On the view panel, click the New button. The network filter properties window will open, in which you can set the parameters of the new filter.

3) In the Basic Settings section, do the following:

• Enter the filter name in the appropriate field (name – filter3);

• Specify the action of the new filter by setting the switch to Pass.

4) In the Sources section, specify the sender of the IP packets to which the

extend the filter action. To do this, add:

• IP address (192.168.0.2) or DNS name of the sender or range of addresses, if there are several;

• Groups of sender IP addresses, if any have been created;

• System object group My Site. In this case, the filter will apply to outgoing open connections from your node.

• System object group Other nodes. In this case the filter will be

act on incoming open connections from your node.

If you do not specify the sender, the filter will apply to IP packets sent by any nodes, including your node.

If you do not specify a recipient, the filter will apply to IP packets sent to any host.

6) In the Protocols section, specify the protocol for TCP filtering. In this case, the filter will process only TCP packets transmitted using the specified protocol. Click apply.

ViPNet in detail: understanding the features of the crypto gateway

The life of a network engineer was happy and carefree until a certified crypto gateway appeared in it.
Agree, understanding solutions designed to encrypt data transmission channels in accordance with GOST is not an easy task. It’s good if these are well-known and understandable products. Let’s remember the same “S-Terra” (we already wrote about their “S-Terra Gateway”). But what to do with more exotic solutions based on our own encryption protocols, for example, “Continent” (from “Security Code”) or ViPNet Coordinator HW (from “Infotex”)? In this article I will try to make it easier for you to immerse yourself in the world of ViPNet (we’ll also talk about “Continent” someday) and tell you what problems I encountered and how I solved them. Let me make a reservation right away that we will talk about version 4.2.1, currently certified by the FSB and FSTEC. In the current versions 4.3.x, a lot of interesting things have appeared, for example, DGD (Dead Gateway Detection) and a modified clustering mechanism that provides almost seamless switching, but for now this is the future. I will not dive deeply into the depths of configuration commands and files, focusing on key commands and variables, and a detailed description of these “keys” can be found in the documentation. First, let's figure out how it all works. So, the ViPNet coordinator performs several functions. Firstly, it is a crypto gateway (CG), which allows you to implement both Site-to-site and RA VPN. Secondly, it is a server-router for envelopes containing encrypted service data (directories and keys) or client application data (file sharing, business mail). By the way, it is in directories that files are stored containing information about ViPNet network objects, including their names, identifiers, addresses, and connections. The coordinator is also a source of proprietary information for his clients.

In addition, it can tunnel traffic from network computers where ViPNet software is not installed. By the way, specialists working with this solution often call open hosts not “tunneled nodes,” but simply “tunnels.” This can be confusing for engineers who are used to other VPN solutions, where a tunnel refers to a PtP connection between CBs.

ViPNet uses IPlir as an encryption protocol, also developed by Infotex. To encapsulate traffic, the transport protocols IP/241 (if the traffic does not leave the broadcast domain), UDP/55777 and TCP/80 (if UDP is not available) are used.

The concept of building secure connections involves so-called “connections”, which are of two types. The first (at the node level) are needed to build a secure connection between nodes, the second (at the user level) are necessary for the operation of client applications. But there is an exception: ViPNet network administrator nodes require both types of communication.

What could go wrong in this scheme? As practice shows, there are really many peculiarities of the work, and not all problems can be solved intuitively, without the “help of the audience,” but some must simply be taken for granted.

Coordinator unavailable

“We have no coordinator/client/tunnel available. What to do?" is the most common question that newbies come up with when setting up ViPNet. The only correct action in such a situation is to enable the registration of all traffic on coordinators and look at the IP packet log, which is the most important tool for troubleshooting all kinds of network problems. This method saves in 80% of cases. Working with the IP packet log also helps you better understand the operating mechanisms of ViPNet network nodes.

Envelope not delivered

But the IP packet log, alas, is useless when it comes to envelopes.
They are delivered using a transport module (mftp), which has its own log and queue. Envelopes are transferred by default to the client’s “own” coordinator (that is, the one on which the node is registered), and then via inter-server channels that are configured between coordinators (that is, not directly via a secure channel). This means that if you want to send a letter by business mail, the client will pack it in an envelope and send it first to his coordinator. Further along the path there may be several more coordinators, and only after that the envelope will reach the recipient node. Two conclusions follow from this. Firstly, communication between clients does not have to be checked (by clicking on F5 and the corresponding icon in the menu) to deliver envelopes. Secondly, if the connection between them is nevertheless checked, this does not guarantee delivery, since the problem may be in one of the interserver channels.

You can diagnose the passage of envelopes through interserver channels or between the client and the coordinator in non-obvious cases using the log and queue of envelopes, as well as logs on the coordinator. Also, the transport module of the ViPNet client can be configured for direct delivery of envelopes, delivery via a shared folder or SMTP/POP3 (but this is a completely exotic option). We will not dive into these settings.

Consequences of flashing

It can be problematic to update old hardware that has been lying around for a long time, for example, as spare parts, to the current version. During the process, an “unsupported hardware” error may appear, which indicates either that you have a truly unsupported hardware platform from the outdated G1 line (these are HW100 E1/E2 and HW1000 Q1), or about problems in the BIOS settings or incorrect information embedded in DMI. Whether to edit DMI independently is up to everyone to decide for themselves, since there is a risk of turning the equipment into a useless “brick”. With BIOS it’s a little simpler: incorrect system settings consist of the HT (Hyper Threading) function being turned off or the ACHI (Advanced Host Controller Interface) mode for the HDD being turned off. In order not to guess what exactly the problem is, you can turn to the flash drive from which the firmware is produced. It creates files with diagnostic information, in particular, the verbose.txt file lists all supported platforms with the result of comparison with yours. For example, the error cpu::Vendor(#3)=='GenuineIntel' 24 times => [Failed] most likely indicates that HT is disabled. By the way, flashing is often confused with updating, but these are different processes. When updating, all settings are saved, and the parameters described above are not checked. And when flashing, you return to the factory settings.

Uninformative configs

The main HW configuration file is "iplir.conf", however it does not always reflect the current settings.
The fact is that when the IPlir driver is loaded, this config is interpreted in accordance with the inherent logic, and not all information can be loaded into the driver (for example, if there are IP address conflicts). Engineers who have worked with a software coordinator for Linux are probably aware of the existence of the “iplirdiag” command, which displays the current node settings loaded into the driver. In HW this command is also present in "admin escape" mode. The most popular outputs are: iplirdiag -s ipsettings —node-info <node identifier> ##display information about the node iplirdiag -s ipsettings —v-tun-table ##display all tunnels loaded into the driver

Let's dwell a little on the “admin escape” mode. Essentially this is the exit from the ViPNet shell to bash. Here I agree with the vendor, who recommends using this mode only for diagnostics and making any modifications only under the supervision of the vendor’s technical support. This is not your ordinary Debian, here any careless movement can disable the OS, the defense mechanisms of which will perceive your “independent activity” as a potential threat. In conjunction with the BIOS being locked by default, this dooms you to non-warranty (read “expensive”) repairs.

(Un)split tunneling

Another fact that not everyone knows: by default, the ViPNet client operates in split tunnel mode (when you can specify which traffic is sent to the tunnel and which is not). ViPNet has an “Open Internet” technology (later renamed to “Secure Internet Gateway”). Many people mistakenly attribute this functionality to the coordinator and not to the client. On a client that is registered with a coordinator with this function, two sets of preset filters are created. The first allows interaction only with the coordinator itself and its tunnels, the second - with other objects, but prohibits access to the PO coordinator and its tunnels. Moreover, according to the vendor’s concept, in the first case the coordinator must either tunnel the proxy server or be a proxy server itself. Service traffic, as well as the reception and transmission of envelopes (both service and application), work in any configuration.

Service ports and TCP tunnel

Once I came across an application that did not want to work through the coordinator in any way. This is how I learned that the coordinator has service ports through which unencrypted traffic is blocked without the possibility of any configuration. These include UDP/2046,2048,2050 (ViPNet core services), TCP/2047,5100,10092 (for ViPNet Statewatcher) and TCP/5000-5003 (MFTP). This is where the TCP tunnel functions failed. It's no secret that providers like to filter high UDP ports, so administrators, trying to improve the availability of their network connections, enable the TCP tunnel function. Resources in the DMZ zone (via the TCP tunnel port) become unavailable. This happens because the TCP tunnel port also becomes a service port, and no firewall or NAT (Network Address Translation) rules apply to it. What makes diagnosis difficult is the fact that this traffic is not recorded in the IP packet log, as if it does not exist at all.

Replacing a coordinator

Sooner or later, the question arises of replacing the coordinator with a more productive or temporary option. For example, replacing an HW1000 with an HW2000 or a software coordinator with a PAK and vice versa. The difficulty lies in the fact that each execution has its own “role” in the NCC (Network Control Center). How to change the role correctly without losing coherence? First, at the NCC we change the role to a new one, create directories, but do not send(!) them. Then we release a new DST file at the UCC and initialize the new Coordinator. Then we make a replacement and, after making sure that all interactions are working, we send the directories.

Clustering and node failure

Hot reserve is a must have for any large site, so they always purchased a cluster of older models (HW1000, HW2000, HW5000).
However, creating a cluster of more compact crypto gateways (HW50 and HW100) was impossible due to the vendor’s licensing policy. As a result, owners of small sites had to seriously overpay and buy HW1000 (well, or no fault tolerance). This year, the vendor finally made additional licenses for junior coordinator models. So with the release of versions 4.2.x, it became possible to collect them into a cluster. When setting up a cluster for the first time, you can save a lot of time by not configuring interfaces in wizard mode or using CLI commands. You can immediately enter the necessary addresses into the cluster configuration file (failover config edit), just do not forget to specify the masks. When the failover daemon is launched in cluster mode, it will automatically assign addresses to the appropriate interfaces. Many people are afraid to stop the daemon, assuming that the addresses are being changed to passive or single-mode addresses. Don’t worry: the addresses on the interfaces will remain the same as they were when the daemon was stopped.

In cluster implementation, there are two common problems: cyclic reboot of the passive node and its failure to switch to active mode. In order to understand the essence of these phenomena, let’s understand the mechanism of the cluster’s operation. So, the active node counts the packets on the interface and if there are no packets within the allotted time, it sends a ping to testip. If the ping passes, then the counter starts again, if it does not pass, then an interface failure is registered and the active node goes into reboot. The passive node sends regular ARP requests on all interfaces described in failover.ini (the cluster configuration file, which specifies the addresses that the active and passive nodes accept). If the ARP record of at least one address disappears, the passive node switches to active mode.

Let's return to cluster problems. I'll start with a simple one - not switching to active mode. If there is no active node, but its mac address is still present in the passive ARP table (inet show mac-address-table), you need to go to the switch administrators (either the ARP cache is configured this way, or there is some kind of failure ). Cyclically rebooting a passive node is a little more complicated. This happens because the passive one does not see the active ARP record, switches to active mode and (attention!) polls its neighbor via the HB link. But our neighbor is in active mode and has more uptime. At this moment, the passive node realizes that something is wrong, since a state conflict has arisen, and goes into a reboot. This continues ad infinitum. If this problem occurs, you need to check the IP address settings in failover.ini and the switching. If all the settings on the coordinator are correct, then it’s time to involve network engineers in the issue.

Address intersections

In our practice, we often encounter the intersection of tunneled addresses behind different coordinators.
It is for such cases that ViPNet products offer address virtualization. Virtualization is a kind of NAT without monitoring the connection state one to one or range to range. By default, this feature is disabled on coordinators, although you can find potential virtual addresses in iplir.conf in the “tunnel” line after “to” in the sections of neighboring coordinators. In order to enable virtualization globally for the entire list, you need to change the “tunneldefault” parameter to “virtual” in the [visibility] section. If you want to enable it for a specific neighbor, then you need to add the “tunnelvisibility=virtual” parameter to its [id] section. You should also make sure that the tunnel_local_networks parameter is set to “on”. To edit virtual addresses, the tunnel_virt_assignment parameter must be set to “manual” mode. On the opposite side you need to perform similar steps. The parameters “usetunnel” and “exclude_from_tunnels” are also responsible for setting up tunnels. The result of the work performed can be checked using the “iplirdiag” utility, which I mentioned above.

Of course, virtual addresses bring some inconvenience, so infrastructure administrators prefer to minimize their use. For example, when organizations connect to the information systems (IS) of some government agencies, these organizations are given a DST file with a fixed range of tunnels from the IS address plan. As we can see, the wishes of the person connecting are not taken into account. How to fit into this pool is up to everyone to decide for themselves. Some migrate workstations to new addressing, while others use SNAT on the way from the hosts to the coordinator. It's no secret that some administrators use SNAT to bypass licensing restrictions of lower-end platforms. We do not undertake to evaluate the ethics of such a “life hack”, but we should not forget that the performance of the platforms themselves still has a limit, and if overloaded, the quality of the communication channel will begin to degrade.

Inability to work GRE

Of course, every IT solution has its own limitations in terms of supported use cases, and ViPNet Coordinator is no exception. A rather annoying problem is the inability of GRE (and the protocols that use it) to work from multiple sources to a single destination via SNAT. Let's take, for example, a bank-client system that raises a PPTP tunnel to the bank's public address. The problem is that the GRE protocol does not use ports, so after traffic passes through NAT, the socketpair of such traffic becomes the same (we have the same destination address, the same protocol, and we just translated the source address into one address). The coordinator reacts to this by blocking traffic against the background of error 104 – Connection already exists. It looks like this:

Therefore, if you use multiple GRE connections, you must avoid applying NAT to these connections. As a last resort, perform a 1:1 broadcast (although this is a rather impractical solution when using public addresses).

Don't forget about time

We continue the topic of blocking with event number 4 – IP packet timeout. Everything here is trivial: this event occurs when there is a discrepancy in absolute (without taking into account time zones) time between ViPNet network nodes (coordinators and ViPNet clients). On HW coordinators, the maximum difference is 7200 seconds and is set in the “timediff” parameter of the IPlir configuration file. I'm not covering HW-KB coordinators in this article, but it's worth noting that in the KB2 version the default timediff is 7 seconds, and in KB4 it's 50 seconds, and the event there can be generated not 4, but 112, which may be confusing an engineer accustomed to “regular” HW.

Unencrypted traffic instead of encrypted

It can be difficult for beginners to understand the nature of event 22 - Non-encrypted IP Packet from network node - in the IP packet log. It means that the coordinator was expecting encrypted traffic from this IP address, but received unencrypted traffic. Most often it happens like this:

the user forgot to log in to the ViPNet client, or accidentally logged out, but is still trying to access the protected resources. In this case, the IPlir driver is inactive, and the traffic that was routed to the coordinator was not encrypted on the user's workstation. Based on the packet headers, the coordinator sees that everything is legal: the source address belongs to the workstation with the ViPNet client, the destination address belongs to the protected or tunneled node. This means that the traffic should come encrypted, but this is not the case, so it must be blocked. A special case of this scenario is the situation when the addresses on the network changed, and the tunneled workstation ended up at the address where the protected ViPNet client was located. But the coordinator still believes that there is a ViPNet client at this address, and therefore unencrypted traffic is blocked;
on one side of the interaction there are no connections. For example, you connected two coordinators, but sent directories and keys to only one (or they did not reach the second). In this case, the first one will wait for encrypted traffic, but the second one, since it does not know about the existence of the first one, will send only unencrypted traffic;
tunnels are registered manually locally on KS. To model such a scenario, two connected coordinators are needed. On one we register our own tunnels and the neighbor’s tunnels, on the second we “forget” to do this. With this configuration, traffic coming from the tunnels of the second coordinator to the tunnels of the first will not be encrypted, and event 22 will occur on the first coordinator.

Application Protocol Processing (ALG)

Many firewalls, including ViPNet Coordinator, may have problems passing SIP through NAT. Given that virtual addresses are internal NAT, the problem can occur even when NAT is not explicitly used, but only virtual addresses are used. The coordinator has an application protocol processing module (ALG), which should solve these problems, but it does not always work as we would like. I will not dwell on the mechanism of ALG operation (a separate article can be written on this topic), the principle is the same on all ITUs, only the application level headers change. For correct operation of the SIP protocol through the coordinator, you need to know the following:

when using NAT, ALG must be enabled;
when using virtual addressing, ALG must be enabled on both nodes participating in the interaction (coordinator-coordinator, coordinator-client), even if virtual visibility is set on only one side;
when using real visibility and the absence of NAT, it is necessary to disable ALG so that it does not interfere with the operation of SIP;
ALG lines 3.x and 4.x are incompatible (strictly speaking, in the 3.x line there was no way to control it at all). In such a scenario, the vendor cannot guarantee the correct operation of SIP.

The module is controlled by commands from the “alg module” group from privileged mode (enable).

Finally

I tried to look at the most pressing problems, identify their roots and talk about solutions.
Of course, these are not all the features of ViPNet, so I recommend not to be shy – contact support and ask for advice in the community (on the vendor’s forum, in the telegram channel, in the comments under this post). And if you don’t want to dive into all the complexities of working with ViPNet or it’s too labor-intensive, then you can always leave the management of your ViPNet network in the hands of professionals. Author: Igor Vinokhodov, engineer of the 2nd line of administration of Rostelecom-Solar