Difficult IPSec with Linux

Developing IT infrastructure sooner or later comes the task of integrating with any services of a large organization. This may be, for example, a bank or carrier. As a rule, in large organizations, well-established information security policies are in place, which in particular require the implementation of a service with an infrastructure external to them through encrypted channels - IPSec. At the same time, in small start - up organizations there is no experience in organizing such schemes, and from the equipment there is only VDS with Linux on board. Moreover, to my surprise, there are practically no materials in RuNet with a description of Linux troubleshooting tools. Let's try to eliminate this gap and describe the practical part of the settings.

The general scheme of the service is presented below. As a rule, in large organizations everything is already standardized, put on stream, all possible encryption and other networking things are done on separate equipment (tsiski-junipery and others like them), and, more importantly, by individual people (perhaps every blue square on the diagram below serve different people). You have one virtual machine with which the service will be launched and IPSec organized.


')
Please note that IPSec itself is organized between the same IP addresses (in my example 10.0.255.1 <-> 10.0.1.1 ), and the service itself between the others ( 192.168.255.1<-> 192.168.1.1 ). Such schemes are also called IPSec Network-Network .

A simple example is that you work in a young, but very ambitious SuperService company, and you need to organize interaction with MegaTelecom's closed API. Your infrastructure is one VDS server, the partner infrastructure is a bunch of network and server equipment. The task is divided into two stages:

1. Arrange transportation (as will interconnection).
2. Configure the service (run applications directly on the servers).

So, the SuperService manager decided to organize a connection to some large organization to solve a business problem. He turned to MegaTelecom , for which he was sent technical conditions for connection. One of these conditions is IPSec organization. This condition came in the form of an excel tablet, an example of which I presented below. In the picture I highlighted the technically significant parameters in yellow. The format may be different, but the essence remains the same.



Initially, it comes not completed on your part, it must be completed and sent to the partner for approval. After agreeing, you can sit down and try to customize your Linux machine.

IPSec concept

Next, I will give a bit of theory for people who are not at all familiar with technology. Everything I describe further refers to pure Ethernet and IPv4. I will not go into encryption algorithms, key exchange, instead focus on the network part.

IPSec is a set of techniques and protocols for establishing a secure connection.

Unlike other tunneling technologies (GRE, PPP, L2TP, even MPLS-TE) IPSec does not create explicit tunnel interfaces through which traffic can be routed. Instead, IPSec provides the concept of so-called Security Assotiations (SA) . SA is a tunnel from one network device to another. But do not forget that SA is not a network interface in the normal sense of the word, classical routing does not work here. Instead of the routing table, the concept of Security Policy (SP) works here. We explicitly prescribe something like an access list (ACL) for passing traffic through a specific SA. All these things are defined in the so-called ISAKMP framework.

ISAKMP is a description of IPSec procedures, referred to in the literature as its framework. It describes the terms SA, SP, SAD (Security Assotiations Database), SPD (Security Policy Database), the need to install auxiliary tunnels ... ISAKMP is designed so as not to depend on tunneling technologies, authentication algorithms and encryption. It simply introduces the necessary definitions.

IKE (v1 / 2) is an authentication protocol itself. It already implements key exchange algorithms and their application.

Thanks to the Cisco concept, ISAKMP and IKE are now considered synonymous.

Before encrypting traffic, the parties must agree on the parameters (and keys) of this encryption. For this, an auxiliary tunnel (also called the ISAKMP tunnel) rises between both sides, which operates all the time. This bidirectional tunnel is a connection over UDP (by default on port 500). To organize this auxiliary tunnel, the parties must verify each other's authenticity (the password must match). This is done by the IKEv1 / 2 protocol (Internet Key Exchange) . And already through an ISAKMP- organized tunnel, the parties agree to encrypt user traffic directly.

The organization of IPSec itself is divided into two phases:

1. Creating an auxiliary ISAKMP tunnel
2. Creating a user data tunnel

As I wrote, in the concept of IPSec (and already correct to say, in the concept of ISAKMP ) tunnels are called SA .

The first phase (organization of ISAKMP SA) can be carried out in two modes:

1. main - the parties alternately exchange the negotiation parameters. It is considered more secure, used for permanent channels (our case).
2. aggressive - the initiator in one message sends all the necessary negotiation parameters, used when connecting a remote user for a temporary session (in order to be faster).

It should be understood that the main SA-tunnels are unidirectional . For two-way data transmission over an IPSec channel, there must be two tunnels: source (src) → receiver (dst) and vice versa.

In all encryption methods, additional headers are added to the original IP packet, encapsulation occurs. There are two ways of this encapsulation - AH (Authentication Header) and ESP (Encapsulation Security Payload) . AH only authenticates the packet (digitally signed by the sender), ESP and authenticates (signs), and encrypts. To date, AH is almost never used, all are packaged in ESP.

You can encrypt and authenticate the source IP packet without taking into account the IP header (transport mode) or with it (tunnel mode). Transport is used when you plan to organize your tunnels using other technologies (not IPSec / ESP). For example, GRE, l2tp, ppp. For the purpose of connecting some service to the internal infrastructure of a large organization, it is practically not used. I used such a scenario to combine several offices into one VPN through IPSec. We are more interested in the tunnel mode. As you can see from the picture, one additional IP header is added here.

By the way, there is a real example of using AH-encapsulation. Suppose we have two networks connected to different routers. Hosts must transmit information with an MTU of 1500 bytes without fragmentation, but we have an intermediate section that supports only 1380 bytes. The whole trail is trusted. We can take advantage of the fact that IPSec does not create tunnel interfaces, in the classical sense through which traffic is not routed. We will create an AH type SA tunnel (we don’t need to encrypt it), then the traffic will go to it. Only external IP packets will be fragmented in traffic (by external IP headers), internal ones will be reassembled without changes.

Note that the ESP header gets up to TCP / UDP transport . Remember, in the header of the IP packet there is a Protocol field? Based on this field, the network equipment (and the final hosts) correctly process IP packets. So for ESP your number is 50. The full list of protocols for this field can be viewed on the wiki , it can be very useful.

The absence of a transport-level header (TCP / UDP / ICMP is already encrypted!) Imposes a restriction on technologies like NAT. Remember, NAT with port translation (overload, PAT, MASQARADE, it has many names) works on the basis of transport protocol ports. And in the IPSec encrypted tunnel there are none! To overcome this problem, there is a technology such as IPSec NAT-Traversal (NAT-T) . During the first phase, the parties agree on the possibility of using NAT-T. If both parties support NAT-T (and even on the same UDP ports), then a UDP header is added to the final tunnels for traffic, with which the packets will already pass through routers with network address translation.

By itself, the tunnel does not rise, you need to send traffic there. As I wrote above, routing rules do not work here, you need to write Security Policy (SP) .

Policies consist of the source address, destination address, direction (in, out, fwd) and user tunnel parameters (ESP is described here as either AH, tunnel variant or transport). This is more like organizing rules for NATa. NAT also has insufficient routing table entries. And there, too, the rules indicate where, where and how , and not where and through what . And it is also possible to overwhelm the entire connection on a remote server with an incorrect hand movement.

All IPSec manipulations add overhead headers. At a minimum, they will eat another 40 bytes from the source packet. Thus, for example, with a standard MTU for PPPoE of 1380 bytes of connections, the real MTU will be <1340.

Linux IPSec

Let's practice on the example of DEB-distributions. I will consider only the case with authorization based on the pre-shared-key (PSK) , we will configure the scheme from the beginning of the article.

IPSec itself is supported by the kernel, but this support is very limited. In reality, core modules are only concerned with encryption and with the keys already received (transferred to the kernel) - packet processing. And to transfer there the parameters and rules with which you need to handle traffic, you need separate software. There are several solutions for such software:

1. KAME, migrated from BSD
2. xSWAN (strongswan, freeswan, libreswan, etc)
3. shorewall

It seemed to me the simplest (most predictable) version of KAME, and we will continue to turn it on.

 # deb-       root@localhost: ~# apt-get install racoon ipsec-tools 

Traditionally KAME consisted of two components.

1. A racoon daemon to manage the ISAKMP tunnel.
2. Setkey utilities for managing SA data tunnels.

Let's start with the first. Racoon is responsible for authorization parameters for tunnels within IKE. This is a daemon, it is configured by a single configuration file ( /etc/racoon.conf ), it is run by a regular init-script ( /etc/init.d/racoon <start|stop|restart> ).



As always, details in man 5 racoon.conf

Further we will be engaged in the setkey utility. It also runs as a daemon ( /etc/init.d/setkey <start|stop|restart> ), but in fact it executes the /etc/ipsec-tools.conf script. As I said, it already sets up creates tunnels for user traffic. Namely sets SA and SP for them. This is something like a crypto-map on ASA. The easiest option for us is to add just SP. Then SA will be built automatically based on the parameters of the second phase, specified in the racoon settings.

But it is possible not to use the parameters of the second phase from racoon at all , but to set the SA through this utility. Details and syntax can be found in man 8 setkey . And I will give you an example of the simplest configuration.


Currently, the setkey utility is duplicated by the iproute2 module.
Within it, there are two record management teams, SA and SP.

1. ip xfrm state
2. ip xfrm policy

In addition to managing the same utility, you can view the status of organized SAs and SPs applied to traffic. Read more in man 8 ip-xfrm .

Take another look at the original label. There are different IP addresses for IPSec and service. The internal IP address is filtered inside the Megatelecom infrastructure. But we have only one virtual machine. It should somehow appear internal IP-address, and packets into the tunnel must leave with him. There are several options to achieve this scenario:

1. A static route without a nextop, but with an explicit indication of the outgoing interface and IP address.
2. Setting routes based on policy based routing (PBR in Linux aka ip rule ).
3. Address Translation ( NAT / MASQARADE ).

From my point of view, the first option is appropriate here.

We can add an additional (secondary) IP address to our interface, while it is better to make an alias for this interface
root@localhost: ~# ip addr add 192.168.1.1/32 dev eth1 label eth1:1
and configure the route to the Megatelecom server from this IP address.
root@localhost: ~# ip route add 192.168.255.1/32 dev eth1:1 src 192.168.1.1
But if you do this, nothing will start. The fact is that when adding a route in this form, the Linux station will try to determine the MAC address of the recipient, it will do it through ARP ... The computer will send ARP requests Who has IP 192.168.255.1 . Since 192.168.255.1 is not on the same network as 192.168.1.1 (mask / 32!), There will be no answer to ARP. But when trying to connect, it will return from the local IP address. No route to host will be returned. To defeat this, we need to set a static ARP record:
root@localhost: ~# arp -s 192.168.255.1 00:00:00:00:00:01 -i eth1:1
Such a life hack. By the way, such manipulations can lead not quite to the correct operation of the Linux IP stack. In one of the cases, the ip route commands did not lead to the desired result, we had to reload the network stack.

Health check

Do not forget, the tunnel will rise only when the traffic goes into it! You need to run ping from a specific interface (IP address) before assignment.
root@localhost: ~# ping -I 192.168.1.1 192.168.255.1
With a slight delay, there should be answers from the reverse side (if of course ICMP is not closed anywhere on the site).

We can see if the ISAKMP tunnel is up.


We can also see user data tunnels.


It can be useful in tcpdump to see the connection establishment logic. Here you can also see the phases of the establishment of the connection and the traffic already encrypted in ESP. Of course, there are techniques to decipher it, but usually this is already enough.

When remotely connecting via SSH, in order not to produce a bunch of windows, it is convenient to run tcpdump in the background:

root@localhost: ~# tcpdump -i eth1 -w ipsec.pcap esp &


Starting ping, telnet, netcat ...

root@localhost: ~# killall tcpdump
root@localhost: ~# tcpdump -vr ipsec.pcap


Also in the logs you can see the successful status of the connection. It shows the successful establishment of both phases of IPSec.


That's all. It remains to add all the necessary manipulations to autoload, and you can begin integrating applications.

PS: Request to report any errors or inaccuracies in the article by a personal message. When I correct the article, the comments will look silly.