IPsec IKEv2 VPN between MikroTik routers (site-2-site)

This article is the result of several years of study, testing and implementation of VPN on MikroTik hardware based on pure IPsec IKEv2 between multiple networks with dynamic routing. Using this method, you can build a coherent network structure with a sufficient number of degrees of freedom and scaling. Optionally, link aggregation can be used, which allows for fast switching in the event of a link drop and relatively high availability.

A large amount of information will be presented below, broken down into blocks in the order of implementation.

General layout and technical subnets

All actions in this article are performed in ROS v6.49.2. It is assumed that the initial setup of the equipment has been made.

Technically, the general scheme is as follows: router R2 (initiator) establishes an IPsec IKEv2 tunnel with router R1 (responder) using certificates, on top of it an EoIP tunnel with a 30 mask is established for the OSPF dynamic routing protocol. Why EoIP – will be explained below. Only R1 should have a static IP address. R1 is also responsible for the certificates.

Scheme
Scheme

Before proceeding with the configuration, you need to decide on the technical subnets for the IPsec and EoIP tunnels. You can use any private addresses, but there is one trick: the last octet of the IP address of the ends of the tunnels is the same for the initiator and responder, respectively. Here’s what I mean:

Router

IPsec

EoIP

172.16.0.0/30

R1

10.0.0.one

172.16.0.one/thirty

R2

10.0.0.2

172.16.0.2/thirty

172.16.0.3/30

You can use the classic 192.168.XX.XX. This will only affect OSPF filtering. When planning is finished, you can proceed to the next item.

Certificates

MikroTik is very relaxed about the use of certificates, the lack of the necessary OIDs is not a problem for him. How this affects the final result is difficult to predict, so we will do it initially well and according to RFC5280

A bit of theory about Key Usage fields

First you need to decide on the fields Key Usage issued certificates:

Key Usage

Meaning (Original)

Value (Translation)

Digital signature

Use when the public key is used with a digital signature mechanism to support security services other than non-repudiation, certificate signing, or CRL signing. A digital signature is often used for entity authentication and data origin authentication with integrity.

Used when the public key is used with a digital signature mechanism to support security services other than non-repudiation, certificate signing, or CRL signing. A digital signature is often used to authenticate an entity and authenticate a data source with integrity.

Non-repudiation – aka Content commitment

Use when the public key is used to verify digital signatures used to provide a non-repudiation service. Non-repudiation protects against the signing entity falsely denying some action (excluding certificate or CRL signing).

Used when the public key is used to verify digital signatures used to provide a service without rejection. Non-repudiation protects against a signer falsely rejecting any action (excluding certificate or CRL signing).

Key encipherment

Use when a certificate will be used with a protocol that encrypts keys. An example is S / MIME enveloping, where a fast (symmetric) key is encrypted with the public key from the certificate. SSL protocol also performs key encipherment.

Used when the certificate will be used with a protocol that encrypts keys. An example would be S / MIME wrapping where the fast (symmetric) key is encrypted with the public key from the certificate. SSL also performs key encryption.

Data encipherment

Use when the public key is used for encrypting user data, other than cryptographic keys.

Used when the public key is used to encrypt user data other than cryptographic keys.

Key agreement

Use when the sender and receiver of the public key need to derive the key without using encryption. This key can then can be used to encrypt messages between the sender and receiver. Key agreement is typically used with Diffie-Hellman ciphers.

Used when the sender and recipient of a public key needs to obtain a key without using encryption. This key can then be used to encrypt messages between the sender and the recipient. Key agreement is commonly used with Diffie-Hellman ciphers.

Certificate signing – aka key cert. sign

Use when the subject public key is used to verify a signature on certificates. This extension can be used only in CA certificates.

Used when the subject’s public key is used to verify the signature on certificates. This extension can only be used with CA certificates.

CRL sign

Use when the subject public key is to verify a signature on revocation information, such as a CRL.

Used when the subject’s public key is intended to validate revocation information such as the CRL.

Encipher only

Use only when key agreement is also enabled. This enables the public key to be used only for enciphering data while performing key agreement.

Used only when key agreement is also enabled. This allows the public key to be used only for encrypting data in key agreement.

Decipher only

Use only when key agreement is also enabled. This enables the public key to be used only for deciphering data while performing key agreement.

Used only when key agreement is also enabled. This allows the public key to be used only to decrypt data in key agreement.

The rest of the parameters are in the so-called Extended Key Usage… Below is a description of these keys.

Additional Information

Extended Key Usage further refines the Key Usage Extensions. The extended key is critical or non-critical. If the extension is critical, the certificate should only be used for the specified purpose or purposes. If the certificate is used for another purpose, it violates the CA policy.

If the extension is not critical, it indicates the intended purpose or purposes of the key and can be used to find the correct key / certificate for an entity that has multiple keys / certificates. In this case, the extension is only an informational field and does not mean that the CA restricts the use of the key to the specified purpose. However, applications that use certificates may require a specific purpose for the certificate to be acceptable.

If a certificate contains both a Critical Key Usage field and a Critical Extended Key Usage field, both fields must be processed independently and the certificate must only be used for a purpose that is compatible with both fields. If there is no purpose in both fields, the certificate cannot be used for any purpose.

Extended Key Usage

Applicable for Key Usage

dvcs

(Data Validation and Certification Server RFC3029)

Digital signature, non-repudiation, Certificate signing, CRL sign

server gated crypto

there is no data

ocsp sign

Digital signature and / or non-repudiation.

Timestamp

Digital signature and / or non-repudiation.

IPsec user

Digital signature and / or key encipherment or key agreement

IPsec tunnel

Digital signature and / or key encipherment or key agreement

IPsec end system (host or router)

Digital signature and / or key encipherment or key agreement

Email protect

Digital signature, non-repudiation, and / or (key encipherment or key agreement)

Sign (downloadable) executable code – aka Code sign

Digital signature

TLS client

Digital signature and / or key agreement

TLS server

Digital signature, key encipherment or key agreement

Before performing all operations and in the future, you need the current time on both routers R1 and R2.

/system ntp client set server-dns-names=ru.pool.ntp.org enabled=yes

As mentioned above, in this case, one of the network devices is used as the certification authority. So, the scheme requires 3 certificates: CA (Certificate Authority), responder (server) and initiator (client).

To create a CA, just run the command on R1:

:global certca "ca"
/certificate add name=$certca key-size=4096 common-name=$certca key-usage=key-cert-sign,crl-sign days-valid=5890
/certificate sign [find where name=$certca]

The maximum date of validity of certificates is 2038-01-18… In case of deletion of the CA certificate automatically all certificates that depend on it are removed. Another important factor is revocation lists (CRLs). Without this option, even a revoked certificate can be successfully authenticated.

/certificate settings edit crl-use

And manually enter “yes”. Whether to store the recall lists in RAM or on a flash depends on your device.

To facilitate the generation of certificates, the commands use variables. Replace the values ​​with the required ones, or leave them as they are.

Issuing a certificate for an R1 responder:

:global certserver "server"
/certificate add name=$certserver key-size=4096 common-name=$certserver key-usage=digital-signature,key-encipherment,key-agreement,ipsec-tunnel days-valid=3650 subject-alt-name=IP:1.1.1.1
/certificate sign [find where name=$certserver] ca=$certca once do={}
:delay 130
/certificate export-certificate [find where name=$certserver] type=pem file-name=$certserver

Issuing a certificate for the initiator on R1:

:global certclient "client"
/certificate add name=$certclient key-size=4096 common-name=$certclient key-usage=digital-signature,key-encipherment,key-agreement,ipsec-tunnel days-valid=3650
/certificate sign [find where name=$certclient] ca=$certca once do={}
:delay 130
/certificate export-certificate [find where name=$certclient] type=pkcs12 export-passphrase=12345678 file-name=$certclient

Transfer the resulting certificates to the R2 initiator and import (do not forget to delete after):

:global certclient "client"
:global certserver "server"
/certificate import file-name=$certclient name=$certclient passphrase=12345678
/certificate import file-name=$certserver name=$certserver passphrase=""

IPsec tunnels

Before proceeding directly with the configuration, make sure that R1 and R2 have the MASQUARADE rule NAT (or SRC-NAT, depending on your installation) parameter ipsec-policy = out, none… This parameter allows you not to create unnecessary rules in NAT.

It is also necessary for the transponder R1 to open a set of ports and protocols:

/ip firewall filter
add action=accept chain=input dst-port=500,4500 in-interface-list=WAN protocol=udp place-before=0
add action=accept chain=input in-interface-list=WAN protocol=ipsec-esp place-before=0

To understand the general concept, below is a diagram of the IPsec menu inside Mikrotik.

IPsec Policy Building Process

An important note here: DO NOT DELETE OR CHANGE THE DEFAULT VALUES (blue). Many internal router services are tied to them. Manipulate them only if you are aware of what you are doing.

Another feature is support hardware encryption, the choice of authentication and encryption algorithms depends on this. Pay attention to the asterisks.

To create an IKEv2 responder on R1, run:

ip ipsec policy group add name=IKEv2
/ip ipsec proposal add name=SHA256 auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=00:30:00 pfs-group=modp4096
/ip ipsec mode-config add name=client responder=yes address=10.0.0.2 system-dns=no
/ip ipsec profile add name=SHA256 hash-algorithm=sha256 prf-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp4096 lifetime=12:00:00 dpd-interval=15
/ip ipsec peer add name=local local-address=1.1.1.1 profile=SHA256 exchange-mode=ike2 passive=yes send-initial-contact=no
/ip ipsec identity add peer=local auth-method=digital-signature certificate=$certserver remote-certificate=$certclient policy-template-group=IKEv2 notrack-chain=prerouting match-by=certificate mode-config=client generate-policy=port-strict
/ip ipsec policy add template=yes group=IKEv2 protocol=255 action=encrypt ipsec-protocols=esp proposal=SHA256
/interface bridge add name=IPsec protocol-mode=none
/ip address add address=10.0.0.1 interface=IPsec

The last two steps are only present in order to land the IPsec interface on the R1 router. On R2, perform this procedure no need

On initiator R2, run:

/ip ipsec policy group add name=IKEv2
/ip ipsec proposal add name=SHA256 auth-algorithms=sha256 enc-algorithms=aes-256-cbc lifetime=00:30:00 pfs-group=modp4096
/ip ipsec profile add name=SHA256 hash-algorithm=sha256 prf-algorithm=sha256 enc-algorithm=aes-256 dh-group=modp4096 lifetime=12:00:00 dpd-interval=15
/ip ipsec peer add name=server address=1.1.1.1 profile=SHA256 exchange-mode=ike2 passive=no send-initial-contact=yes
/ip ipsec identity add peer=server auth-method=digital-signature certificate=$certclient remote-certificate=$certserver policy-template-group=IKEv2 notrack-chain=prerouting match-by=certificate mode-config=request-only generate-policy=port-strict
/ip ipsec policy add template=yes group=IKEv2 protocol=255 action=encrypt ipsec-protocols=esp proposal=SHA256

This completes the IPsec configuration. You can use ping to check the availability of the other end of the tunnel. Change the options as needed.

Execute / ip ipsec installed-sa print… If you see flags H before the records, then the hardware encryption is working.

Generate a separate certificate for each connection point. Yes, unnecessary steps, but this will save you from a long trip in the event of a certificate revocation.

EoIP tunnels

It would be possible to do without these interfaces, but they are necessary for OSPF to work, as well as for more interesting things: if you have two or more communication channels, then EoIP can be combined into Bond with wide customization and fault tolerance.

So, to create an interface on R1:

/interface eoip add name=EoIP-Tunnel local-address=10.0.0.1 remote-address=10.0.0.2 tunnel-id=1
/ip address add address=172.16.0.1/30 interface=EoIP-Tunnel

On R2:

/interface eoip add name=EoIP-Tunnel local-address=10.0.0.2 remote-address=10.0.0.1 tunnel-id=1
/ip address add address=172.16.0.2/30 interface=EoIP-Tunnel

tunnel-id must match… If you are using winbox, then when creating EoIP interfaces, do not copy them! When copying, the MAC is saved, and a new one is not generated.

Traffic now flows inside the tunnel over IPsec.

OSPF and filters

But there are just few tunnels. We also need routing, preferably dynamic.

So on R1 do:

/routing ospf network add network=172.16.0.0/24 area=backbone
/routing ospf network add network=192.168.1.0/24 area=backbone
/routing ospf instance set router-id=192.168.1.1 redistribute-connected=as-type-1 [find where name=default]
/routing ospf interface add copy-from=[find where interface=EoIP-Tunnel] use-bfd=yes network-type=point-to-point
/routing ospf interface add copy-from=[find where interface=bridge] passive=yes

On R2:

/routing ospf network add network=172.16.0.0/24 area=backbone
/routing ospf network add network=192.168.2.0/24 area=backbone
/routing ospf instance set router-id=192.168.2.1 redistribute-connected=as-type-1 [find where name=default]
/routing ospf interface add copy-from=[find where interface=EoIP-Tunnel] use-bfd=yes network-type=point-to-point
/routing ospf interface add copy-from=[find where interface=bridge] passive=yes

The last command disables OSPF broadcast to the bridge.

What is the difference between the types, which routes can be transmitted further, you can read in documentation… The topic is extensive and is submitted to MTCRE in an acceptable manner.

Now that OSPF is configured, routers exchange routes, but technical ones as well. And what to do when there are tens and hundreds of them? In addition to them, there are also networks of providers, which also do not need to be exchanged.

The following combination of rules for filters R1 and R2 was obtained empirically:

/routing filter
add action=accept chain=ospf-out prefix=192.168.0.0/16 prefix-length=16-32
add action=discard chain=ospf-out
add action=discard chain=ospf-in prefix=172.16.0.0/24 prefix-length=30

The filtering principle is as follows: do not transmit anything to a neighbor except 192.168.XX.XX. If an additional route needs to be passed, a rule above the above is created.

Additionally

This completes the basic configuration of a pure IKEv2 VPN. Then you can add nodes, change encryption, add fault tolerance by combining EoIP into Bond. By the way, the initiator can be the respondent at the same time.

In order not to lose everything set up with such labor, the backup should be done with a passphrase. Otherwise, the private keys will not be included in it. And of course, the export command will not help in this case.

/system backup save password=1234567890

Another point is the frequent crash of OSPF. This is usually related to the MTU of the main link or EoIP tunnel. It is enough to reduce it, and OSPF bounces back.