This is the first article in a series about IPSec services on Mikrotik platform. We will discuss a basic theory of IPSec services. On that foundation, we will explore a few common scenarios for implementation.
I will demonstrate each scenario in the virtual environment and provide you with detailed explanation. In addition, I will publish the basic configuration scripts that you can use in your laboratory.
The series will cover following topics:
- What is IPSec? (this article)
- How to connect two sites over the Internet using IPSec protocol
- How to connect two sites when servers need to use NAT addresses
- How to connect two sites when one of them is behind a NAT router
- Implementing L2TP/IPSec tunnels
- How to connect three sites using IPsec (added 21.03.2017.)
- How to protect tunnels without encryption using IPSec
- Basic troubleshooting techniques
I will also present to you my virtual lab. That part will help you to understand the scenarios and to build your own testing environment. All scenarios will be presented in the same environment.
This part is more theoretical. This is the essence of the theory. You need to understand it well and to build a good foundation for further work.
Before we begin, I need to write a word of caution. In case that VPN or encryption technologies are considered forbidden and/or illegal in your country, please stop further reading and leave this page. You have been warned!
What is IPSec?
IPSec is a suite of the services intended to protect the data exchange over the unsecured IPv4 or IPv6 networks.
In IT jargon, when we speaking about IPSec, we mean IPSec VPN tunnel. In addition, the IPSec protocol is short for the IPSec protocol suite. I will use this convention through the series.
IPSec tunnel is dynamic non-routable VPN tunnel. That means that we have to establish it when we need exchange of data and we cannot assign an IP address to it. Without the IP address, this kind of tunnel cannot be used as part of the routing table.
IPSec protocol is widely used in today’s corporate networks and it’s considered the de facto standard for secure communication over public networks.
IPSec suite includes the following protocols:
- Authenticated Header (AH)
- Encapsulation Security Payload (ESP)
- Internet Key Exchange (IKE)
We can use only AH, only ESP or both AH and ESP protocols in our implementations. IKE protocol is always used.
IPSec protocols are very sensitive to time synchronization. For best experience, it is recommended that both sides use a NTP service.
IPSec tunnel can be used in two modes:
In the transport mode, IPSec tunnel is used to protect the direct communication between two hosts inside the same network. For example, we can protect the communication between user’s laptop and the database server or between the application and database server.
In the tunnel mode, we want to protect only part of the communication path between two hosts. The hosts are separated with the gateways (routers), that will route the whole network traffic over the Internet.
Both gateways will act as the termination points for the IPSec VPN tunnel. Only that part of the interconnection path between our hosts is encrypted.
One host will send the IP packet. That packet will travel as unencrypted inside the local network. On the gateway, packet will be collected and, according to the specific rules, it will be encrypted and sent over the Internet to the other gateway.
The second router will receive this encrypted packet, inspect it and, if it match the appropriate rules, decrypt it and send to the destination host. Then the destination host will send the answering packet back using same mechanism.
More details about IPSec protocols
We need to understand IPSec protocols, if we want to master it. We will not going through the whole theory of IPSec here.
Authentic Header or AH protocol is designed only to protect the authentication of the packet content. It will not encrypt the data and therefore it will not protect it from eavesdropping.
Whoever see the packet can also read the contents. However, the contents cannot be altered by third party.
AH protocol will create its own packet header. The value of the header depends on the packet content.
Position of the header depends on the connection mode. In the transport mode, the header is calculated and inserted after the original IP header.
In the tunnel mode, gateway will create completely new IP packet with the secured header and the payload of that packet will be the original IP packet.
For authentication between the parties, we can use either MD5 or SHA1 protocol. The SHA1 protocol is recommended.
AH protocol is described in details inside the RFC 4302.
Encapsulation Security Payload (ESP)
Encapsulation Security Payload or ESP protocol is designed for the data protection. This protocol will encrypt the data part of the packet (or the payload) and hide it from third parties. The packet header is not encrypted and it’s still visible over the Internet.
ESP protocol uses its own identification protocols. Therefore, we do not need to use AH. In addition, using AH in conjunction with ESP protocol will result in the increased security of the tunnel.
For the data encryption, this tunnel will use one of the well-known encryption algorithms, like:
- AES 128/192/256 bits
- Camellia 128/192/256 bits
It’s recommended that you use at least AES algorithm, as DES and 3DES are weak.
The ESP header have three part:
- ESP Header
- ESP Trailer
- ESP Authentication Data
Again, depending on the traffic mode, position of the headers will vary. In the tunnel mode, the complete original packet is used as payload. This will encrypt it and protect it during the transport.
In the transport mode, the ESP header is inserted behind original IP header and then the IP Trailer. Original content is encrypted and attached next, as payload. Behind it will be ESP Authentication Data. Original IP header is not touched or altered in this mode.
ESP protocol is described in details inside the RFC 4303.
A few advanced models of Mikrotik Routerboards have hardware acceleration for ESP protocol:
- RB 1000
- RB 1100AHx2
- All Cloud Core Router (CCR) devices
- RB 850Gx2
The CPU on those models is optimized for the faster processing of the AES-CBC and SHA1/SHA256 algorithms. All other calculations are performed in the software mode.
Internet Key Exchange protocol
Internet Key Exchange or IKE protocol is the most often used protocol for the key exchange over the Internet.
This service (or daemon) works only during the certain periods of establishing IPSec tunnels. The main goals of IKE protocol are to:
- perform the exchange of crypto keys in the secure way over the Internet
- provide mutual authentication of both parties
- calculate and manage the Security Associations (SA) values
The SA values are most important for every tunnel. If values of the SA are not compatible on both sides, tunnel cannot be established.
The establishment of IPSec tunnel has two phases:
- IKE phase I
- IKE phase II
IKE phase I
IKE phase I will occur when two devices (most often routers) identify the first packet that needs to be send through encrypted tunnel. In that moment, the IKE daemon will run and initiate the connection process.
In this phase, we need to define the peer with which we need to establish the tunnel. Both sides must have the proper definition of the matching peer on the other side of the tunnel.
If this definition is not correct, the tunnel cannot be initialized. This is one of the common mistakes during the configuration of IPSec tunnels.
We need to harmonize following parameters in this phase:
- The IP address of the matching peer
- An authentication algorithm (MD5, SHA-1,…)
- An encryption algorithm (3DES, AES,…)
- A lifetime of the tunnel (like 1 day or 5 GB of data)
- A Diffie-Helman (DH) group (at least DH group 2 – 1024 bits)
- Are we passing through the NAT (NAT-T option)
- Should we send initial contact?
- Dead Peer Discovery (DPD) settings
DPD is a mechanism that router will use to determinate if other side is still “alive”. Every side will send the R-U-There message every 30 seconds. If N messages during the period of T seconds are not answered, router will conclude that other side is not alive anymore. In addition, router will destroy tunnel and its SA identifications.
The Diffie-Helman algorithm is designed with goal that two parties can build common crypto key over the Internet. Moreover, neither side have the complete key in the beginning. Key will be generated dynamically every time when tunnel is build.
This key will be used for further encryption of other traffic. It’s recommended to use the key with length of at least 1024 bits or DH group 2. However, stronger key is advised.
IKE phase II
The second phase in the IPSec establishment will be used to encrypt the packets between endpoints (hosts). It covers:
- Rules for the data protection (proposal)
- Rules for the communication (policies)
Inside proposal, we must specify identical authentication and encryption algorithms, lifetime and Perfect Forward Security parameter. We should use at least the SHA-1 authentication protocol and AES-128-CBC bit encryption protocol.
The parameter of the lifetime will keep the tunnel alive for the specific predefined period. After the time elapsed, tunnel will be either refreshed with the new key or destroyed. The usual lifetime period is 8 hours, but you can shorten it for sensitive applications. However, too short period will require that routers spending their precious CPU time to recalculate the keys more often.
Perfect Forward Security or PFS is mechanism that uses same DH algorithm as IKE phase I to calculate keys for every tunnel established between two hosts.
Usage of the PFS is optional. We can omit it. However, it’s good practice to use the PFS. In addition, same rule about the key length should be applied here – at least the DH group 2 or 1024 bits.
The tunnel life
As we said in the beginning, IPSec tunnel is dynamic. Therefore, it is established when we need it and it is destroyed when we do not need it any more. Moreover, every IPSec tunnel had the lifetime.
Every new tunnel will use new crypto key. That crypto key will be generated dynamically. Therefore, if the key is compromised at one time, only portion of the traffic can be decrypted.
We can limit the life of the tunnel in two ways, either a period of time or an amount of data that can be exchanged. The second method will be used either when we working in sensitive environment or exchanging a large amount of data.
Every tunnel will use two counters – a soft and hard counter. The soft counter is used to determinate a moment when we need to renew the tunnel. In case that communication is disturbed and that tunnel is not active in that moment, our device will wait the predefined time until the hard counter is reached. That is the signal that tunnel should be destroyed.
There is no special requirements for IPSec services on any license level.
For full details related to Mikrotik RouterOS license level, please visit this page.
Where is IPSec located?
IPSec service can be found in the menu IP > IPSec or through command ip ipsec on the console.
IPSec packet is installed on every Mikrotik Routerboard device. For the software x86 routers, this packet is optional. There are two packets related to the VPNs in the x86 RouterOS:
- Security – this one is for IPSec service
- PPP – this one covers PPP services, including PPTP and L2TP VPN services
You need one paper
When we summarize this very long post, we can see that we need to harmonize many settings between two parties. It is wise to produce one document (it can be even plain text file) where we will record all parameters and exchange it with other party. On that way, we can shorten the time needed for implementation.
As you can see from this sample, we will enlist all parameters. The pre-shared key should not be exchanged in this document, rather over the SMS or any other communication channel. In this demo, we will use the key Test1234.
I saw too many failed implementations just because both sides were lazy to write parameters on the paper. In addition, when you harmonize the parameters, you can re-check settings again very easy if any problem occur. Moreover, you can than push other side to do so, having this paper as good argument.
That’s all about the essential theory of IPSec tunnels. This basis will help us to build our lab and then to bravely go in the world of IPSec tunnels. Stay tuned.