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.
Strengths:
Weak sides:
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.
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.
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:
IKE protocol can operate in two modes: mainly (main) and aggressive (aggressive), IKEv2 protocol contains one mode.
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
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.
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
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.
IPSec provides two options for encapsulating data:
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.
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 is available for free on any device running RouterOS with the Security package installed.
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.
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.
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.
IPSec peers configuration to establish an IKE connection and create an auxiliary secure tunnel.
Setting up IPSec remote peers
Setting Profiles (Proposals) for Phase 1 Matching
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.
The package passes the policy one by one until it matches the terms of one of them.
Policy setting
Setting up offers (Proposals) to negotiate SA
Used to associate policy templates and peers.
In one of the old versions of RouterOS, there was a bug with the default non-working group.
Sending and receiving IP parameters without using additional protocols. Allows you to create a self-contained Client-to-Server VPN only IPSec.
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.
A list of all peers installing and installing an auxiliary tunnel (Phase 1). You can delete peers to update secondary tunnel keys.
SAD database or list of all agreed SAs. You can see the data protection algorithms and keys used.
The Hardware AEAD flag indicates the use of hardware encryption.
The administrator can reset the SA, but only simultaneously all of the same type (esp or ah).
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
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 .
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
Step configuration:
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
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
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:
Check connection
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:
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
#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:
Connection test is similar to tunnel mode.
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.
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
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:
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
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.
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 /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
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.
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.
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):
/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:
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:
The router prompts about the error of the proposals on phase2 and shows what is configured locally and what is remote.
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).
For IKE:
For IKEv2:
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/