🥇1.5 schemes on domestic IPsec VPN. Testing demo versions

Situation

I received a demo version of S-Terra VPN products version 4.3 for three months. I want to figure out if my engineering life will be easier after transitioning to the new version.

Today it’s easy, one packet of 3-in-1 instant coffee should be enough. I'll explain how to obtain demo versions. I will try to compile GRE-over-IPsec and IPsec-over-GRE schemes.

How to obtain a demo version

According to the diagram, to obtain a demo version you need to:

Write an email to presale@s-terra.ru from a corporate address;
In the email, specify your organization's TIN;
List the products and their quantities.

Demo versions are valid for three months. The vendor does not restrict their functionality.

Deploying the image

The demo version of the security gateway is a virtual machine image. I use VMWare Workstation. A complete list of supported hypervisors and virtualization environments is available on the vendor's website.

Before starting active actions, please note that the virtual machine image does not have any network interfaces by default:

The logic is clear, the user must add as many interfaces as needed. I will add four right away:

Now I am starting the virtual machine. Immediately after launching, the gateway requires a login and password.

In S-Terra Gateway, there are several consoles with different accounts. I will count their number in a separate article. For now:
Login as: administrator Password: s-terra

I initialize the gateway. Initialization is a sequence of actions: entering the license, configuring the biological random number generator (the keyboard trainer – my record is 27 seconds) and creating a network interface map.

Network interface map. It has become easier

Version 4.2 greeted active users with messages:

Starting IPsec daemon... failed ERROR: Could not establish connection with daemon

An active user (according to an anonymous engineer) is a user who is able to set anything up quickly and without documentation.

Something was going wrong, even before attempts to configure the IP address on the interface. It all comes down to the network interface map. I needed to perform:

/bin/netifcfg enum > /home/map /bin/netifcfg map /home/map service networking restart

As a result, a network interface map is created, which contains the mapping of physical interface names (0000:02:03.0) to their logical designations in the operating system (eth0) and Cisco-like console (FastEthernet0/0):

#Unique ID iface type OS name Cisco-like name

0000:02:03.0 phye eth0 FastEthernet0/0

Logical designations of interfaces are called aliases. Aliases are stored in the file /etc/ifaliases.cf.
In version 4.3, when the virtual machine is first launched, the interface map is created automatically. If you change the number of network interfaces in the virtual machine, please recreate the interface map:

/bin/netifcfg enum > /home/map /bin/netifcfg map /home/map systemctl restart networking

Diagram 1: GRE-over-IPsec

I am deploying two virtual gateways and connecting them as shown in the figure:

Step 1. Configuring IP addresses and routes

VG1(config) #
interface fa0/0
ip address 172.16.1.253 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.1.253 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.254

VG2(config) #
interface fa0/0
ip address 172.16.1.254 255.255.255.0
no shutdown
interface fa0/1
ip address 192.168.2.254 255.255.255.0
no shutdown
ip route 0.0.0.0 0.0.0.0 172.16.1.253

Checking IP connectivity:

root@VG1:~# ping 172.16.1.254 -c 4
PING 172.16.1.254 (172.16.1.254) 56(84) bytes of data.
64 bytes from 172.16.1.254: icmp_seq=1 ttl=64 time=0.545 ms
64 bytes from 172.16.1.254: icmp_seq=2 ttl=64 time=0.657 ms
64 bytes from 172.16.1.254: icmp_seq=3 ttl=64 time=0.687 ms
64 bytes from 172.16.1.254: icmp_seq=4 ttl=64 time=0.273 ms

--- 172.16.1.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 0.273/0.540/0.687/0.164 ms

Step 2. Configuring GRE

I will take the GRE configuration example from the official scripts. I create the gre1 file in the /etc/network/interfaces.d directory with the following content.

For VG1:

auto gre1
iface gre1 inet static
address 1.1.1.1
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.254 local 172.16.1.253 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1

For VG2:

auto gre1
iface gre1 inet static
address 1.1.1.2
netmask 255.255.255.252
pre-up ip tunnel add gre1 mode gre remote 172.16.1.253 local 172.16.1.254 key 1 ttl 64 tos inherit
pre-up ethtool -K gre1 tx off > /dev/null
pre-up ip link set gre1 mtu 1400
post-down ip link del gre1

Bringing the interface up in the system:

root@VG1:~# ifup gre1
root@VG2:~# ifup gre1

Checking:

root@VG1:~# ip address show
8: gre1@NONE:  mtu 1400 qdisc noqueue state UNKNOWN group default qlen 1
    link/gre 172.16.1.253 peer 172.16.1.254
    inet 1.1.1.1/30 brd 1.1.1.3 scope global gre1
       valid_lft forever preferred_lft forever

root@VG1:~# ip tunnel show
gre0: gre/ip remote any local any ttl inherit nopmtudisc
gre1: gre/ip remote 172.16.1.254 local 172.16.1.253 ttl 64 tos inherit key 1

In the C-Terra Gateway, there is a built-in packet sniffer — tcpdump. I will record a traffic dump into a pcap file:

root@VG2:~# tcpdump -i eth0 -w /home/dump.pcap

Starting ping between GRE interfaces:

root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=0.850 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=0.918 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=0.974 ms

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 0.850/0.915/0.974/0.043 ms

The GRE tunnel is active and functioning:

Step 3. Encrypting GRE with GOST

Setting the identification type — by address. Authentication using a predefined key (according to the Rules of Use, digital certificates should be used):

VG1(config)#
crypto isakmp identity address
crypto isakmp key KEY address 172.16.1.254

Setting IPsec Phase I parameters:

VG1(config)#
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2

Setting IPsec Phase II parameters:

VG1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
mode tunnel

Creating an access list for encryption. Target traffic — GRE:

VG1(config)#
ip access-list extended LIST
permit gre host 172.16.1.253 host 172.16.1.254

Creating a crypto map and binding it to the WAN interface:

VG1(config)#
crypto map CMAP 1 ipsec-isakmp
match address LIST
set transform-set TSET
set peer 172.16.1.253
interface fa0/0
  crypto map CMAP

For VG2, the configuration is mirrored, differences:

VG2(config)#
crypto isakmp key KEY address 172.16.1.253
ip access-list extended LIST
permit gre host 172.16.1.254 host 172.16.1.253
crypto map CMAP 1 ipsec-isakmp
set peer 172.16.1.254

Checking:

root@VG2:~# tcpdump -i eth0 -w /home/dump2.pcap

root@VG1:~# ping 1.1.1.2 -c 4
PING 1.1.1.2 (1.1.1.2) 56(84) bytes of data.
64 bytes from 1.1.1.2: icmp_seq=1 ttl=64 time=1128 ms
64 bytes from 1.1.1.2: icmp_seq=2 ttl=64 time=126 ms
64 bytes from 1.1.1.2: icmp_seq=3 ttl=64 time=1.07 ms
64 bytes from 1.1.1.2: icmp_seq=4 ttl=64 time=1.12 ms

--- 1.1.1.2 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.077/314.271/1128.419/472.826 ms, pipe 2

ISAKMP/IPsec statistics:

root@VG1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 1 (172.16.1.253,500)-(172.16.1.254,500) active 1086 1014

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 1 (172.16.1.253,*)-(172.16.1.254,*) 47 ESP tunn 480 480

There are no GRE packet entries in the traffic dump:

Conclusion: the GRE-over-IPsec scheme is working correctly.

Diagram 1.5: IPsec-over-GRE

I do not plan to use IPsec-over-GRE in the network. I'm assembling it just because I want to.

To deploy the GRE-over-IPsec scheme backwards, you need to:

Correct the access list for encryption – target traffic from LAN1 to LAN2 and vice versa;
Set up routing through GRE;
Bind the crypto map to the GRE interface.

By default, there is no GRE interface in the Cisco-like gateway console. It only exists in the operating system.

Adding the GRE interface to the Cisco-like console. For this, I edit the file /etc/ifaliases.cf:

interface (name="FastEthernet0/0" pattern="eth0")
interface (name="FastEthernet0/1" pattern="eth1")
interface (name="FastEthernet0/2" pattern="eth2")
interface (name="FastEthernet0/3" pattern="eth3")
interface (name="Tunnel0" pattern="gre1")
interface (name="default" pattern="*")

where gre1 is the name of the interface in the operating system, Tunnel0 is the name of the interface in the Cisco-like console.

Recalculating the file hash:

root@VG1:~# integr_mgr calc -f /etc/ifaliases.cf

SUCCESS:  Operation was successful.

Now the Tunnel0 interface has appeared in the Cisco-like console:

VG1# show run
interface Tunnel0
ip address 1.1.1.1 255.255.255.252
mtu 1400

Correcting the access list for encryption:

VG1(config)#
ip access-list extended LIST
permit ip 192.168.1.0 0.0.0.255 192.168.3.0 0.0.0.255

Configuring routing through GRE:

VG1(config)#
no ip route 0.0.0.0 0.0.0.0 172.16.1.254
ip route 192.168.3.0 255.255.255.0 1.1.1.2

Removing the crypto card from Fa0/0 and binding it to the GRE interface:

VG1(config)#
interface Tunnel0
crypto map CMAP

For VG2, similarly.

Checking:

root@VG2:~# tcpdump -i eth0 -w /home/dump3.pcap

root@VG1:~# ping 192.168.2.254 -I 192.168.1.253 -c 4
PING 192.168.2.254 (192.168.2.254) from 192.168.1.253 : 56(84) bytes of data.
64 bytes from 192.168.2.254: icmp_seq=1 ttl=64 time=492 ms
64 bytes from 192.168.2.254: icmp_seq=2 ttl=64 time=1.08 ms
64 bytes from 192.168.2.254: icmp_seq=3 ttl=64 time=1.06 ms
64 bytes from 192.168.2.254: icmp_seq=4 ttl=64 time=1.07 ms

--- 192.168.2.254 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3006ms
rtt min/avg/max/mdev = 1.064/124.048/492.972/212.998 ms

ISAKMP/IPsec statistics:

root@VG1:~# sa_mgr show
ISAKMP sessions: 0 initiated, 0 responded

ISAKMP connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) State Sent Rcvd
1 2 (172.16.1.253,500)-(172.16.1.254,500) active 1094 1022

IPsec connections:
Num Conn-id (Local Addr,Port)-(Remote Addr,Port) Protocol Action Type Sent Rcvd
1 2 (192.168.1.0-192.168.1.255,*)-(192.168.2.0-192.168.2.255,*) * ESP tunn 352 352

In the traffic dump, ESP packets encapsulated in GRE:

Output: IPsec-over-GRE is functioning correctly.