📜 ⬆️ ⬇️

Overview of IPSec in Mikrotik

IPSec (IP Security) is a set of protocols and algorithms for encrypting data in IPv4 and IPv6 networks. It doesn't sound complicated, but IPSec does not set clear rules for encrypting traffic; instead, developers implement a set of tools (protocols and algorithms) that the administrator uses to create a secure channel for data.


I want to talk about the topic of IPSec in RouterOS a little deeper than a simple HOWTO, with minimal immersion in theory and examples of how to configure and debug IPSec. This is not a guide and without practice on a test bench, it is not recommended to start setting up real tunnels and VPN servers.


Advantages and disadvantages of IPSec


Strengths:



Weak sides:



Protocols included with IPSec



Globally, all the protocols you will deal with during configuration can be divided into two groups: key exchange protocols and data protection protocols.


Key Exchange Protocols (IKE)
The main task is to authenticate the participants of the connection and agree on the parameters and encryption keys to protect the transmitted information.



In practice, most IPSec connections are implemented using IKE, due to outdated equipment, or the reluctance to change something with administrators.


Data Security Protocols (ESP, AH)
The main task is to protect user data.



IPSec connection setup procedure



The participants of an IPSec connection are called peers (peers), which indicates their equivalence in the established connection. A configuration close to the client-server is possible, but when building persistent IPSec tunnels, any of the peers can be an initializer.


  1. One of the peers initializes the IPSec connection
  2. Key information is exchanged, peer authentication, connection parameters negotiation
  3. Based on the received key information, an auxiliary encrypted tunnel is formed.
  4. Using an encrypted tunnel, peers determine data encryption parameters and exchange information to generate keys.
  5. The result of the previous phase is a set of rules and keys for data protection (SA).
  6. Periodically peers update encryption keys

One of the key concepts in IPSec is the SA (Security Association) - it is a peer-coordinated set of information encryption and hashing algorithms, as well as encryption keys.


Sometimes you can find a division on:



The operation of the key agreement protocols


IKE protocol can operate in two modes: mainly (main) and aggressive (aggressive), IKEv2 protocol contains one mode.


Ike main



The first phase consists of six packages:
1-2: Matching the encryption parameters of the secondary tunnel and various IPSec options
3-4: Exchange of information to generate a secret key
5-6: Peer authentication using an auxiliary encrypted channel


The second phase consists of three packages:
1-3: Using an encrypted auxiliary channel. Coordination of traffic protection parameters, information exchange for generating a secret key


IKE Aggressive



The first phase consists of three packages:
1: Sending a proposal for installing an auxiliary encrypted channel and information for generating a secret key
2: Response to the proposal, information for generating a secret key, data for authentication
3: Authentication data


The second phase consists of three packages:
1-3: Using an encrypted auxiliary channel. Coordination of traffic protection parameters, information exchange for generating a secret key


In aggressive mode, the initiator sends only one set of parameters in the offer. Peer authentication information is exchanged prior to the installation of a secure auxiliary tunnel. Aggressive mode is consistent faster, but less secure.


IKEv2



In IKEv2, the phases are named: IKE_SA_INIT and IKE_AUTH. But if in the text below I’m talking about Phase1 and Phase2, then this also applies to IKEv2 phases.


Each IKEv2 phase consists of two packets:
IKE_SA_INIT: Coordinating the encryption parameters of the secondary tunnel, sharing information to generate the private key


IKE_AUTH: using an encrypted auxiliary channel. Authenticating peers, negotiating traffic protection parameters, exchanging information for generating a secret key


Security Assotiations Database (SAD)


The result of the work of IKE (and IKEv2) are Security Assotiations (SA), which determine the parameters of traffic protection and encryption keys. Each SA is unidirectional and the IPSec connection contains a pair of SA. All SAs are stored in the SAD database and are available to the administrator for viewing and resetting.


Data encapsulation



IPSec provides two options for encapsulating data:



Security Policy Database (SPD)


The base of rules determining which traffic should be encrypted, data protection protocol, encapsulation type and a number of other parameters.
The SPD check position can be displayed on the Packet Flow schematic.



Overcoming NAT


IPSec uses network layer protocols to transfer data that NAT cannot handle. To solve the problem, the NAT-T protocol is used (extension in IKE and part of IKEv2). The essence of NAT-T is the additional encapsulation of IPSec packets into UDP packets that NAT processes.


IPSec in Mikrotik


IPSec is available for free on any device running RouterOS with the Security package installed.


Hardware encryption


For offloading the CPU, hardware acceleration of encryption is added to some models of MikroTik routers, a full list can be found on the wiki .
The most budget options: RB750Gr3 , RB3011 , HAP AC ^ 2 .


On my own, I checked the IPSec speed between two RB1100AHx2 and between two RB750Gr3.


To achieve maximum results on RB1100AHx2, you need:



On RB750Gr3 without optimizations around 200Mb / sec.


Routers on single-core Qualcomm show a result of 10-40mb / sec, depending on the model, optimizations and congestion with other processes.


I recommend to get acquainted with the presentation from the employee mikrotik, there are topics on how to optimize settings to reduce the load on the CPU and increase the speed, which I did not add to the text.


Differences 6.42.X and 6.43.X


Depending on the version of RouterOS used, the IPSec configuration menu will vary.





There are already new changes in the testing version, so read the Release Notes before updating.



IPSec configuration



Menu [IP] -> [IPSec] is not as scary as it seems at first glance. The diagram shows that the main configuration items are: Peers and Profiles.
The Remote Peers and Installed SAs tabs are informational.


Peers and Peers Profiles


IPSec peers configuration to establish an IKE connection and create an auxiliary secure tunnel.


image


Setting up IPSec remote peers



Notes
  • Starting at 6.43, RouterOS swears when using PSK without additional authentication. If you do not want to further configure the keys, certificates, or xAuth, you can switch to IKEv2 or ignore the warning.
  • As peers, you can specify specific IP or subnet (relevant for Client-Server VPN)
  • If there are conflicting rules, a rule with a more accurate subnet will be used to connect to the peer (by analogy with routes)
  • XAuth and rsa key authentication does not work in IKEv2
  • For IKEv2, Mikrotik made their xAuth implementation incompatible with other platforms.
  • Passive mode is usually used to create Client-Server VPN (L2TP / IPsec or IKEv2 mode config), but can be useful when connecting a large number of Site-to-Site tunnels to a single point, to reduce spurious traffic.
  • If you plan to use xAuth, then the "server" should be passive. Users for the server are created in [IPSec] -> [Users]
  • When using Generate policy, choose the port-strict mode.

Setting Profiles (Proposals) for Phase 1 Matching


image



Notes
  • Additional options for IKE have become part of IKEv2, settings ignored
  • The ratio of DH groups with their numbers (group numbers are used by other vendors)
  • When sending offers (Proposals), the system sorts pairs of algorithm + group dh from more resistant to less resistant

Policies and Policy Proposals


Policies check passing packages for compliance with the conditions and apply the specified actions. If you return to Packet flow, then blocks with IPSec Policy are reconciliation with policies. The actions specify: IPSec security protocol (ESP or AH), suggestions for SA negotiation, encapsulation mode.
image


The package passes the policy one by one until it matches the terms of one of them.


Policy setting


Rumors
  • Usually it is not required to specify a specific Src. and Dst. Port, but in general the ability to encrypt the traffic of a separate application is interesting
  • Not all ip protocols are presented in the Protocols list (for example, no gre), you can specify the number of the desired protocol manually.
  • Templates are not politicians! They are used if generate-policy is set in the peer configuration
  • What to do if certain SAs for the policy were not found. Previously, there was a problem with L2TP / IPSec, when several clients could not connect due to a single NAT (using IKE), this bug is solved (provided that these clients are not windows) if you set level = unique. Otherwise, go to IKEv2
  • When setting policies, use [Safe mode], one awkward movement and you risk losing access to the router via Level3

Setting up offers (Proposals) to negotiate SA



Groups


Used to associate policy templates and peers.


image


In one of the old versions of RouterOS, there was a bug with the default non-working group.


Mode Config


Sending and receiving IP parameters without using additional protocols. Allows you to create a self-contained Client-to-Server VPN only IPSec.




Keys and Users


Used for advanced peer authentication.
Keys
RSA keys: generation, import, export. Not supported in IKEv2.



Users
XAuth user database for "server". The client specifies the xAuth settings in the peer configuration. It is possible to forward xAuth authentication to a RADIUS server.



Remote peers


A list of all peers installing and installing an auxiliary tunnel (Phase 1). You can delete peers to update secondary tunnel keys.


image


image


Installed SAs


SAD database or list of all agreed SAs. You can see the data protection algorithms and keys used.


image


image


The Hardware AEAD flag indicates the use of hardware encryption.


image


The administrator can reset the SA, but only simultaneously all of the same type (esp or ah).


IPSec and Firewall


In the Firewall, you can check whether the traffic is inbound or outbound IPSec policy or not. The obvious use is L2TP / IPSec, you can prevent the installation of L2TP connections if the traffic was not previously encrypted.



Protocols and ports used in IPSec



IPSec and Endpoinds


And now about the sore ...
The wiki mikrotik has tables with hashing and encryption algorithms for: Windows , iOS , OS-X .


I did not find any information about the client built into the android vpn, but in general it works with the proposals from windows. IKEv2 does not support Android, you must use StrongSwan .


Configuration examples


Scheme and basic configuration for examples with Site-to-Site tunnels:



#Mikrotik1 /ip address add address=10.10.10.10/24 interface=ether1 network=10.10.10.0 add address=192.168.100.1/24 interface=ether2 network=192.168.100.0 /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1 /ip route add distance=1 gateway=10.10.10.1 dst-address=0.0.0.0/0 #Mikrotik2 /ip address add address=10.20.20.20/24 interface=ether1 network=10.20.20.0 add address=192.168.200.1/24 interface=ether2 network=192.168.200.0 /ip firewall nat add action=masquerade chain=srcnat out-interface=ether1 /ip route add distance=1 gateway=10.20.20.1 dst-address=0.0.0.0/0 

IPSec in tunnel mode



Step configuration:


  1. Create Proposals for IKE Phase1
  2. Create a feast. Specify the address, proposals, exchange mode, key PSK. I chose IKEv2, you can use main / agressive as desired
  3. Create Proposals for SA
  4. Specify the subnets between which we create the tunnel
  5. Specify the SA addresses, tunnel mode and proposals to encrypt traffic
  6. Editing the NAT rule

Mikrotik1


Console option:


 #1 /ip ipsec peer profile add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no #2 /ip ipsec peer add address=10.20.20.20/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec #3 /ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=ipsec-tunnel-sa #4-5 /ip ipsec policy add dst-address=192.168.200.0/24 proposal=ipsec-tunnel-sa sa-dst-address=10.20.20.20 sa-src-address=10.10.10.10 src-address=192.168.100.0/24 tunnel=yes #6 /ip firewall nat set 0 ipsec-policy=out,none 

Mikrotik2


Console option:


 #1 /ip ipsec peer profile add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no #2 /ip ipsec peer add address=10.10.10.10/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec #3 /ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=tets-ipsec-sa #4-5 /ip ipsec policy add dst-address=192.168.100.0/24 proposal=tets-ipsec-sa sa-dst-address=10.10.10.10 sa-src-address=10.20.20.20 src-address=192.168.200.0/24 tunnel=yes #6 /ip firewall nat set 0 ipsec-policy=out,none 

And then NAT?

To work in tunnel mode, you need a fake route to the remote subnet, or a default route, otherwise the packets will not go further Routing decision. There are usually no problems with the first option, but with the default route and Source NAT (the first and second are present on the vast majority of home and office routers) there will be problems.


Remember Packet Flow. Packages go through Source NAT earlier than IPSec policies, the rule with masquerade is unaware that the traffic is meant to be sent to the “ephemeral” tunnel and will broadcast the headers of packets to be sent to IPSec when the packet with the changed header gets sent to Policies source address the header will not fit the rule and the packet will fly away to the default route, which, having seen the destination address from the private network, will most likely drop it.


There are several solutions to the problem:


  • Using the fake route
  • Using additional accept rules before SourceNAT
  • Expose src-nat only to packets for which there are no IPSec policies (in the example)
  • Exclude traffic from connection tracking with RAW

Check connection
image


  1. We see a neighbor in the Remote Peers
  2. We see installed SA (traffic counters will not change until you let it go)
  3. Established status and flag (A) ctive in politics

IPIP / IPSec



Pre-configuration of IPIP tunnel:


 #Mikrotik1 #Настройка интерфейса ipip /interface ipip add allow-fast-path=no clamp-tcp-mss=no name=ipip-vpn remote-address=10.20.20.20 #Установка ip адреса на ipip интерфейс /ip address add address=10.30.30.1/30 interface=ipip-vpn #Статический маршрут до удаленной подсети /ip route add distance=1 dst-address=192.168.200.0/24 gateway=10.30.30.2 #Mikrotik2 #Все аналогично, меняются только адреса и подсети /interface ipip add allow-fast-path=no clamp-tcp-mss=no name=ipip-vpn remote-address=10.10.10.10 /ip address add address=10.30.30.2/30 interface=ipip-vpn /ip route add distance=1 dst-address=192.168.100.0/24 gateway=10.30.30.1 

Step by Step IPSec Configuration:


  1. Create Proposals for IKE Phase1
  2. Create a feast. Specify the address, proposals, exchange mode, PSK key
  3. Create Proposals for SA
  4. Specify the subnets between which we create the tunnel
  5. Specify the addresses of SA, the type of traffic that we will encrypt and proposals

Mikrotik1


Console option:


 #1 /ip ipsec peer profile add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no #2 /ip ipsec peer add address=10.20.20.20/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec #3 /ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=ipsec-tunnel-sa #4-5 /ip ipsec policy add dst-address=10.20.20.20/32 proposal=ipsec-tunnel-sa protocol=ipencap src-address=10.10.10.10/32 sa-dst-address=10.20.20.20 sa-src-address=10.10.10.10 

Mikrotik2


 #1 /ip ipsec peer profile add dh-group=modp2048 enc-algorithm=aes-128 hash-algorithm=sha256 name=ipsec-tunnel-ike nat-traversal=no #2 /ip ipsec peer add address=10.10.10.10/32 exchange-mode=ike2 profile=ipsec-tunnel-ike secret=test-ipsec #3 /ip ipsec proposal add auth-algorithms=sha256 enc-algorithms=aes-256-cbc name=tets-ipsec-sa #4-5 /ip ipsec policy add dst-address=10.10.10.10/32 proposal=tets-ipsec-sa protocol=ipencap src-address=10.20.20.20/32 sa-dst-address=10.10.10.10 sa-src-address=10.20.20.20 

For the inattentive, the real difference is the configuration of the tunnel and transport mode in IPSec Policies:
image


Connection test is similar to tunnel mode.


L2TP / IPSec


The previous examples are well suited for creating persistent VPNs between two peers, with static external IP addresses.


If the address of one of the peers is dynamic (and is usually located behind a NAT), you must use another Client-to-Server VPN.
image


Preliminary L2TP configuration:


 #Создание пула адресов для клиентов /ip pool add name=pool-l2tp ranges=192.168.77.10-192.168.77.20 #Создание профиля для клиентов /ppp profile add change-tcp-mss=yes local-address=192.168.77.1 name=l2tp-ipsec only-one=yes remote-address=pool-l2tp use-compression=no use-encryption=no use-mpls=no use-upnp=no #Создание учетных записей /ppp secret add name=user1 password=test1 profile=l2tp-ipsec service=l2tp add name=user2 password=test2 profile=l2tp-ipsec service=l2tp add name=user3 password=test3 profile=l2tp-ipsec service=l2tp #Включение сервера L2TP (без автонастройки ipsec) /interface l2tp-server server set authentication=chap,mschap2 default-profile=l2tp-ipsec enabled=yes 

Why do I ignore IPSec auto configuration

In the configuration of ipip, gre, eoip, l2tp there is an auto-configuration of ipsec connections, in fact the system creates dynamic rules for Peers and Policies for you, but firstly - we are not looking for easy ways, secondly, when upgrading from 6.42 to 6.43, automatically created tunnels broke and not the fact that this will not happen again.


Step by Step IPSec Configuration:


  1. Create a new group (you can use default)
  2. Create Proposals for IKE Phase1
  3. Create a feast, or rather a subnet. Swears on the PSK key, but if we are dealing with windows as a client, then we have a choice: Certificates or PSK.
  4. Set passive = yes and send-init-contact = no, generate-policy = port-strict (accept port from client)
  5. Create Proposals for SA
  6. Create a template for generating policies
  7. Specify proposal for SA

Mikrotik configuration

image
On the screenshot of the error - indicate dst. port and src. port is not needed


Console option:


 #1 /ip ipsec policy group add name=l2tp-ipsec #2 /ip ipsec peer profile add dh-group=modp1024 enc-algorithm=aes-256 hash-algorithm=sha256 name=l2tp-ipsec-ike #3-4 /ip ipsec peer add address=0.0.0.0/0 generate-policy=port-strict passive=yes policy-template-group=l2tp-ipsec profile=l2tp-ipsec-ike secret=secret-ipsec-pass send-initial-contact=no #5 /ip ipsec proposal add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=l2tp-ipsec-sa pfs-group=none #6-7 /ip ipsec policy add dst-address=0.0.0.0/0 group=l2tp-ipsec proposal=l2tp-ipsec-sa protocol=udp src-address=0.0.0.0/0 template=yes 

Configuring a firewall to create L2TP connections only after IPSec


 /ip firewall filter #Разрешаем IKE, NAT-T и ipsec-esp add chain=input protocol=17 dst-port=500,4500 action=accept add chain=input protocol=50 action=accept #Разрешаем L2TP, только если есть политика ipsec для данного трафика add chain=input protocol=17 dst-port=1701 ipsec-policy=in,ipsec action=accept add chain=input protocol=17 dst-port=1701 action-drop 

IKEv2 VPN


The variant with L2TP is popular, but thanks to the mode config you can configure the VPN server using only IPSec. This is a promising type of VPN, but rarely used so far, so besides the configuration of the server part, I will give an example of setting up a strongSwan client on android.


image


Of course, not everything is so rosy. Most of the "user" OS (in particular, Windows and Android) agree to work with such a VPN only if they are authenticated by certificates or EAP.


Certificates are my weak point, if someone knows how to correctly generate a self-signed certificate that windows imports and will use in a connection - write in the comment.


Pre-generation certificates:


 #Root CA и сапомодпись /certificate add name=ca common-name="IKEv2 CA" days-valid=6928 /certificate sign ca ca-crl-host=<IP роутера> #Сертификат для сервера vpn /certificate add common-name=<IP роутера> subject-alt-name=IP:<IP роутера> key-usage=tls-server name=vpn days-valid=6928 #Подпись серверного сертификата /certificate sign vpn ca=ca #Сертификат для клиента #Клиенты с одним сертификатам не смогут работать одновременно, поэтому генерируйте по одному для каждого #Для отмены доступа необходимо сделать Revoke клиентского сертификата /certificate add common-name=client key-usage=tls-client name=client days-valid=6928 #Подпись клиентского сертификата /certificate sign client ca=ca 

Step-by-step configuration of IKEv2 VPN:


  1. We create a pool of addresses for distribution to clients
  2. Create a mode config profile for distributing IP settings to clients
  3. Create groups to link Peers and templates policies
  4. Create Proposals for IKE Phase1
  5. Create a profile to connect peers. Authentication via certificates, IKEv2 protocol, passive mode
  6. Specify the profile mode config profile, a group of 3 steps and enable policy generation
  7. Create Proposals for SA
  8. Create a template for generating policies
  9. Specifying Proposals for SA

Mikrotik setup

image


 #1 /ip pool add name=pool-ike ranges=192.168.77.10-192.168.77.20 #2 /ip ipsec mode-config add address-pool=pool-ike address-prefix-length=32 name=ikev2-vpn static-dns=77.88.8.8 system-dns=no #3 /ip ipsec policy group add name=ikev2-vpn #4 /ip ipsec peer profile add enc-algorithm=aes-256,aes-128 hash-algorithm=sha256 name=ikev2-vpn #5-6 /ip ipsec peer add address=0.0.0.0/0 auth-method=rsa-signature certificate=vpn exchange-mode=ike2 generate-policy=port-strict mode-config=ikev2-vpn passive=yes policy-template-group=ikev2-vpn profile=ikev2-vpn send-initial-contact=no #7 /ip ipsec proposal add auth-algorithms=sha256,sha1 enc-algorithms=aes-256-cbc,aes-128-cbc name=ikev2-vpn #8-9 /ip ipsec policy add dst-address=0.0.0.0/0 group=ikev2-vpn proposal=ikev2-vpn src-address= 0.0.0.0/0 template=yes 

Configuration strongSwan on android.

You must first transfer the client and ca certificates to your phone.
https://habrastorage.org/webt/tp/pk/ad/tppkadaifd1k7xi6hf3jxgg7vcs.png


For big-eyed: A cross near the wi-fi is because Most of the system applications are blocked by AFWall +.


If the connection is successful, there will be: a dynamic policy, an entry in remote Peers and a pair of SA.


image


image


image


The RouterOS x86 demo license has no restrictions on the number of IPSec tunnels, including IKEv2 VPN. You can deploy RouterOS x86 demo (do not confuse with RouterOS CHR free, everything is sad there) on the VPS and get a personal VPN server with a minimum of administrative effort, without buying a license for RouterOS or RouterOS CHR.


A couple of words about the analysis of IPSec logs


The logs in Mikrotik are a separate story, and sometimes they are detailed enough to analyze the problem, but the lack of commonplace features: clear, copy, find, forces you to install a separate syslog server.


As for IPSec, here’s a quick log analysis option (leaving only the one you need on a separate tab):


image


 /system logging action add memory-lines=100000 name=ipsec target=memory /system logging add action=ipsec topics=ipsec,error add action=ipsec topics=ipsec,debug,!packet add action=ipsec topics=ipsec,info 

And a couple of examples of typical IPSec configuration problems:


Proposals matching problem on Phase1

image


  1. We read the error message. The problem with the negotiation of Proposals in the first phase.
  2. We look above, the router itself tells what sent a feast, and what is configured locally

Problem of coordination of proposals IKE_SA_INIT

In the logs you will see something like the following:



Analyzing traffic


In the request you can see the proposals from the feast:



In the answer, we see that there are no suitable proposals:



Proposals negotiation problem for SA


The router prompts about the error of the proposals on phase2 and shows what is configured locally and what is remote.


Proposals negotiation problem IKE_AUTH


We see that connection and authentication of peers have occurred, but further the error of proposals. You will not see details in the debug, in wireshark too (the IKE_AUTH traffic is encrypted).


PSK authentication error

For IKE:



For IKEv2:


Wrong IKE mode

image
We see that Phase1 breaks on timeout, although the packets between peers go. But the size of the incoming packet is much larger, if we analyze via wireshark, we will see that the remote peer uses aggressive mode.



We see that from us packets are sent to UDP: 500, and come to UDP: 4500 and quite large. Here the remote peer is on IKEv2 mode.


And finally, read the troubleshooting section of the wiki . And all the material about IPSec is desirable for review, I described only the basic set of tools and settings.



Source: https://habr.com/ru/post/438176/