Situation
I received a demo version of C-Terra VPN products version 4.3 for three months. I want to find out if my engineering life will become easier after switching to the new version.
Today is not difficult, one bag of instant coffee 3 in 1 should be enough. I'll tell you how to get demos. I'll try to build the GRE-over-IPsec and IPsec-over-GRE schemes.
How to get a demo
It follows from the figure that in order to get a demo you need to:
- Write a letter to [email protected] from a corporate address;
- In the letter, indicate the TIN of your organization;
- List the products and their quantity.
Demos are valid for three months. The vendor does not limit their functionality.
Expanding the image
The Security Gateway demo is a virtual machine image. I am using VMWare Workstation. A complete list of supported hypervisors and virtualization environments is available on the vendor's website.
Before you begin, please note that there are no network interfaces in the default virtual machine image:
The logic is clear, the user should add as many interfaces as he needs. I'll add four at once:
Now I start the virtual machine. Immediately after launch, the gateway requires a username and password.
There are several consoles in S-Terra Gateway with different accounts. I will count their number in a separate article. For now:
Login as: administrator
Password: s-terra
I am initializing the gateway. Initialization is a sequence of actions: entering a license, setting up a biological random number generator (keyboard simulator - my record is 27 seconds) and creating a network interface map.
Map of network interfaces. It became easier
Version 4.2 greeted the active user 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 can set up anything quickly and without documentation.
Something was going wrong before trying to set up an IP address on the interface. It's all about the network interface map. It was necessary to do:
/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
service networking restart
As a result, a network interface map is created that contains the mapping of physical interface names (0000:02:03.0) and 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
The logical designations of interfaces are called aliases. Aliases are stored in the /etc/ifaliases.cf file.
In version 4.3, when the virtual machine is first started, an interface map is created automatically. If you change the number of network interfaces in the virtual machine, then please recreate the interface map:
/bin/netifcfg enum > /home/map
/bin/netifcfg map /home/map
systemctl restart networking
Scheme 1: GRE-over-IPsec
I deploy two virtual gateways, I switch as shown in the figure:
Step 1. Set up 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.254VG2(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.253Checking 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 msStep 2: Set up GRE
I take an example of setting up GRE from official scripts. I create a gre1 file in the /etc/network/interfaces.d directory with the contents.
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 gre1For 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 gre1I raise the interface in the system:
root@VG1:~# ifup gre1
root@VG2:~# ifup gre1Checking:
root@VG1:~# ip address show
8: gre1@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> 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 1C-Terra Gateway has a built-in packet sniffer - tcpdump. I will write a traffic dump to a pcap file:
root@VG2:~# tcpdump -i eth0 -w /home/dump.pcapI start 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 msGRE tunnel is up and running:
Step 3. Encrypt with GOST GRE
I set the type of identification - by address. Authentication with a predefined key (according to the Terms of Use, digital certificates must be used):
VG1(config)#
crypto isakmp identity address
crypto isakmp key KEY address 172.16.1.254I set the IPsec Phase I parameters:
VG1(config)#
crypto isakmp policy 1
encr gost
hash gost3411-256-tc26
auth pre-share
group vko2I set the IPsec Phase II parameters:
VG1(config)#
crypto ipsec transform-set TSET esp-gost28147-4m-imit
mode tunnelI create an access list for encryption. Targeted traffic - GRE:
VG1(config)#
ip access-list extended LIST
permit gre host 172.16.1.253 host 172.16.1.254I create a crypto map and bind 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 CMAPFor VG2, the configuration is mirrored, the differences are:
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.254Checking:
root@VG2:~# tcpdump -i eth0 -w /home/dump2.pcaproot@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 480There are no packets in the GRE traffic dump:
Conclusion: the GRE-over-IPsec scheme works correctly.
Figure 1.5: IPsec-over-GRE
I do not plan to use IPsec-over-GRE on the network. I collect because I want to.
To deploy the GRE-over-IPsec scheme the other way around:
- Fix encryption access list - targeted traffic from LAN1 to LAN2 and vice versa;
- Configure routing through GRE;
- Hang a cryptomap on the GRE interface.
By default, there is no GRE interface in the Cisco-like gateway console. It exists only in the operating system.
I add the GRE interface to the Cisco-like console. To do this, I edit the /etc/ifaliases.cf file:
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 interface designation in the operating system, Tunnel0 is the interface designation in the Cisco-like console.
I recalculate the hash of the file:
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 1400Correcting 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.255I configure 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.2I remove the cryptomap from Fa0 / 0 and bind it to the GRE interface:
VG1(config)#
interface Tunnel0
crypto map CMAPFor VG2 it is similar.
Checking:
root@VG2:~# tcpdump -i eth0 -w /home/dump3.pcaproot@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 msISAKMP/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 352In the ESP traffic dump, the packets encapsulated in GRE:
Conclusion: IPsec-over-GRE works correctly.
Results
One cup of coffee was enough. I sketched instructions for obtaining a demo version. Configured GRE-over-IPsec and deployed vice versa.
The map of network interfaces in version 4.3 is automatic! I'm testing further.
Anonymous engineer
t.me/anonymous_engineer
Source: habr.com