Creating a fail-safe IPSec VPN tunnel between Mikrotik RouterOS and Kerio Control

Starting with version 8.1 of Kerio Control, you can use not only the proprietary Kerio VPN protocol to create VPN tunnels, but also the completely correct IPSec. And of course, I immediately wanted to cross Mikrotik and Kerio Control.

In this article I will talk about several connection schemes. So, the first scheme.

Combining two subnets. It's simple.

And immediately a little digression on the topic of the direction of the connection. Those. which end of the tunnel accepts, and which initiates the VPN connection. The scheme when Kerio Control initiates the connection is chosen to simplify the provision of fault tolerance of VPN tunnels in case Kerio Control and Mikrotik have several WAN interfaces. I will dwell on this in detail in the fourth part of this article. In all cases, I will use authentication with a predefined key (password).

To connect about IPsec between Kerio Control and Mikrotik RouterBoard on RouterOS 6.1, you need to create a new IPsec tunnel on the Control side with the following settings:

• Common parameters. Active mode (Control initiates connection to Mikrotik). Enter the IP address or DNS name of the Mikrotik external interface. In the example - 109.172.41.XXX
• Authentication Predefined key. Enter a strong password.
• Local id The arbitrary name of the Control gateway or the external IP address of the Control. In the example - drgs1-gtw02
• Remote ID External Mikrotik address. If the WAN address of the Mikrotik interface is different from the external address, specify the WAN interface address in Mikrotik. A classic example, when a provider issues a DHCP IP address to the Mikrotik network interface from its gray LAN, to which it forwards packets arriving at the external static IP address that was issued to you. This article describes just such an option. Therefore, in the example - 10.48.113.102.
• Remote networks. Specify the network \ mask of the local subnet for Mikrotik. For example 192.168.88.0/24.
• Local area networks. Specify the network \ local subnet mask behind Kerio Control. For example 192.168.10.0/24.

To configure the tunnel on the Mikrotik side, you need to connect to the router via Winbox and add firewall rules that allow IKE, IPSec-esp, IPSec-ah, or temporarily for debugging all UDP traffic (I really don’t recommend allowing all UDP - angry people are used as DNS forwarders, at least) in the input chain. To do this, in the terminal window, you must run the following commands:

/ip firewall filter add chain=input comment="Allow IKE" dst-port=500 protocol=udp
/ip firewall filter add chain=input comment="Allow IPSec-esp" protocol=ipsec-esp
/ip firewall filter add chain=input comment="Allow IPSec-ah" protocol=ipsec-ah
/ip firewall filter add chain=input comment="Allow UDP" protocol=udp

The result of the command will be added firewall filter rules. I think that this is obvious to everyone, but for beginners, I note that these rules should be above the prohibition rules in the input chain. In my example, the rule above is number 13.



Next, you need to edit (or create) the encryption policies (Proposals) in the IPsec configuration. Bring your settings in accordance with the figure or execute the command indicated below in the terminal window.



This is a team that edits an existing policy value. If you have no default values ​​in the proposal (empty at all, there are none), you need to create them in accordance with the figure. And in this case, the command does not need to be executed .

/ip ipsec proposal set [find default=yes] enc-algorithms=3des,aes-128 pfs-group=none

We need to configure peer and we will dwell on this especially. It should be noted that in Router OS version 6.0 or more, some settings regarding IPsec Peers and IPSec Policies have changed. In particular, new options have been added to Peers settings. Now for Peer, you can specify whether Mikrotik initiates or accepts the connection (analogue passive / active in Kerio Control). The caveat is that the “passive” parameter cannot be set via the GUI. It is neither in Winbox, nor in the web-based interface for managing the router. By default, when creating a peer through Winbox, it becomes active and begins to continuously try to establish a connection to the address specified in its settings. Therefore, to create the passive end of our tunnel, it is necessary to use the CLI and in the terminal window execute the command where instead of “password” you need to specify a predefined key,

/ip ipsec peer add address=109.172.42.XXX/32 dh-group=modp1536 exchange-mode=main-l2tp generate-policy=port-override hash-algorithm=sha1 passive=yes secret=password

The result of the command will be a created peer that is waiting for a connection. If your WAN interfaces are behind the NAT provider, set the NAT-Travesal checkbox.



When configuring Peer, we specified the option to automatically generate IPsec policies. Therefore, we do not need to create anything in / ip ipsec policies. The necessary policies will be created automatically after the connection is established. If you didn’t forget to enable it in Kerio Control’s tunnel settings, this will happen immediately after adding the peer.
After that, the tunnel on the Kerio Control side should go into the “Connected” status. In Mikrotik, on the Policies tab, an automatically created policy should appear for the subnets that were specified when configuring Kerio Control in Remote Networks and Local Networks. In “Installed SAs” you will see that your tunnel ends are “friends” and finally in “Remote Peers” you will see the connection status.





The tunnel is installed. But for traffic to pass between the subnets behind Kerio Control and Mikrotik, you need to add a rule to the NAT rules of the firewall that will not allow the traffic that you send to the tunnel to be masked. If you do not make this rule, the networks will not be friends, even if the tunnel is installed. To do this, in the terminal window, you must run the command:

/ip firewall nat add chain=srcnat dst-address=192.168.10.0/24 src-address=192.168.88.0/24

Important! The rule must be above the rules of masquerading. That is, to be the highest in the list of NAT rules.

After that, the connection to the internal addresses between the subnets 192.168.88.0/24 and 192.168.10.0/24 should work. This completes the configuration of the tunnel between the two subnets. But that was easy. More interesting ...

Network integration for Mikrotik and several VPN networks for Kerio Control

Let's consider a more complex option when it is necessary to provide local network access for Mikrotik to local networks for Kerio Control, connected to the central office using other VPN tunnels using the Kerio VPN protocol (for example). A sample diagram is shown in the figure below.



It would seem easier? In configuring the VPN tunnel in Kerio Control, you just need to add a list of all subnets to which you need to access from the local network for Mikrotik and about which Head Office already knows, in the "Local Area Networks" list. And, accordingly, expand the range of addresses in the NAT rule in Mikrotik that will not be disguised, for example, by creating a group of such addresses in the “Address List” and specifying this group in the destination of the rule.

Add, reinstall the tunnel. We see that the tunnel has established, in IPsec Policies, automatic policies for all subnets, which we specified in the tunnel settings on the Kerio Control side, have fun. In Installed SAs, we see created SAs for all subnets. Bingo? But it wasn’t here ...

Thoughtful smoking of the Internet on the topic of IPsec in Mikrotik and combining local networks behind different types of routers made it clear that with this scheme everyone has the same problem - the inability to explain to Mikrotik exactly where to send packets. In almost all types of IPSec routers, a tunnel is a separate network interface, which is logical. But not in Mikrotik, and therefore it is impossible to determine for him the route of packets to the remote subnet. In practice, in conjunction with Kerio Control - Mikrotik persistently sent packets through the last added SAs. Packets honestly arrived at the central office and Kerio Control was discarded there. In no article did I find an explanation of the logic of Mikrotik's behavior in this case. I tried everything, it seems, possible options with the same result. With zero.

Five days of a brain storm, a lost dream, a two-day binge - behind. The thought of the solution described below visited me on the second day of the search for a solution, but at first it was marked as an extremely crooked solution. Why I will explain the crooked and visible flaws a little later. But, as you know, in fishlessness - and cancer is fish.

If Mikrotik works perfectly with one subnet in IPSec policies, then we need to logically combine our subnets behind the Kerio Control subnet mask. Those. aggregate subnets behind Kerio Control into one. Addresses in the subnets 192.168.10.0/24, 192.168.20.0/24, 192.168.30.0/24 and 192.168.40.0/24 will be within the same subnet 192.168.0.0/18, add this subnet to the list “Local networks” when configuring the tunnel in Kerio Control and establish a tunnel connection. Mikrotik will create a single IPsec Policies and create a single SAs. Now he simply cannot be mistaken where to send packets. A ping test should show the availability of all subnets per Control for the network behind Mikrotik. If you are checking ICMP accessibility with Mikrotik, you should start ping not from the WAN interface, but from the bridge, for example. This is a very common mistake, which leads to moaning in the style of CTNT, nothing works, we all die, paws break and the tail falls off, save-help.

To return packets from the remote VPN networks to the network behind Mikrotik, you need to add an analog of the rule to Mikrotik, which does not allow masquerade packets sent to the tunnel. Because all traffic to the network for Mikrotik from VPN networks will go from the VPN interface of the central branch, we need traffic rules that would deceive Mikrotik by changing the source from the VPN address to the address from the subnet that Mikrotik knows about. The rules in the figure. Address 192.168.10.2 - The internal address of the gateway of the central office.



After that, traffic exchange between subnets will go in all directions.

Now about the disadvantages of this method. With this scheme, it is impossible to give out “routes” to the local network (I intend to put the word in quotation marks, since in reality there are no routines that are usual for understanding in the Mikrotik routing table to remote subnets at all) only for specific remote subnets connected to Head Office. Theoretically, there is a possibility that you cannot logically combine addresses on remote subnets into one using a mask. Because they can generally be in different classes of networks. Due to the fact that a huge number of addresses fall into the range, in theory there is a possibility that you will need to use other addresses from this range not in the IPSec tunnel, which will be impossible. Attentionif your Mikrotik address falls into this range (!!!) then the installation of the tunnel will cause you to lose contact with Mikrotik. In this case, access it through Winbox at the MAC address and disable the tunnel or disable it on the Kerio Control side. After that, either take the local Mikrotik address out of the range that it receives from Contol when installing the VPN tunnel, or this (i.e. the option with LAN aggregation for Kerio Control) is not your case at all.

In general, I would say that the solution is crooked until impossible. Crooked, but working. In an existing infrastructure, you may have to rewrite local subnet addresses. But the RouterOS developers left me no choice. Adding an interface for IPSec in Wishlist, as far as I know, for a long time. In English-language forums, I have repeatedly seen petitions to developers full of tears and despair.

We use the Mikrotik router as a VPN client

Using Mikrotik as a client will make it possible to forget about dancing with IPSec and non-routable routing. But keep in mind that there will be no access to the network for Mikrotik from the local network for Kerio Control. And this is logical. Note that since Kerio Control is licensed for connections, including VPN clients - this type of connection reduces the counter of licensed connections by one. Well, or if in a simple way - it uses a single connection license.

Everything is extremely simple here. Create a user in Kerio Control or edit an existing one. On the “Rights” tab, set the “Users can connect via VPN” checkbox.



We add a rule to traffic rules that allows you to connect to Kerio Control using the L2TP protocol from the Internet or you can restrict the source to a list of trusted addresses. In the figure, I am allowed to connect only to the list of trusted addresses of remote administrators.



On the Mikrotik side, you need to add a new L2TP Client interface by executing a command in the terminal window:

add comment="L2TP VPN Client" connect-to=109.172.42.XXX disabled=no max-mru=1460 max-mtu=1460 name=INTERFACE-NAME password=password user=username

You need to replace the values ​​of the address, interface name, connection name and password with Kerio Control, your arbitrary interface name and your username / password that you created or edited in the user settings. The result of the command should be a newly created interface that will immediately establish a connection to the server.



A new address will appear in the Mikrotik address list, dynamically assigned to it by the Kerio Control VPN server.



In order for the local network for Mikrotik to gain access to the network for Kerio Control, you need to add static routes to the routing table. To do this, you need to execute commands in the terminal window, replacing the interface name with your existing one:

/ip route add comment="Route to 192.168.20.0/24" distance=1 dst-address=192.168.20.0/24 gateway=INTERFACE-NAME
/ip route add comment="Route to 192.168.30.0/24" distance=1 dst-address=192.168.30.0/24 gateway=INTERFACE-NAME
/ip route add comment="Route to 192.168.40.0/24" distance=1 dst-address=192.168.40.0/24 gateway=INTERFACE-NAME

The result will be added static routes to remote subnets behind Kerio Control via the VPN interface.

Now add the masquerading rule to Mikrotik. To do this, we execute the command in the terminal window:

/ip firewall nat add action=masquerade chain=srcnat out-interface=INTERFACE-NAME src-address=192.168.88.0/24

That's all, access from the local network for Mikrotik to the network for Kerio Control and to all networks connected to it via other VPN tunnels. Do not forget to fix my values ​​in the teams on your own.

Providing VPN Tunnel Failover

Well, the sweetest snack. The promised story about the organization of tunnel resiliency. Prior to Kerio Control 8.1, in the configuration of an active connection, it was impossible to specify more than one address of the receiving end of the tunnel, therefore, to ensure fault tolerance of VPN tunnels, I would vote for the scheme when Kerio Control in the central office accepts connections. In this case, fault tolerance could be provided by monitoring the incoming channels of the central office and automatically changing the only DNS name to which the branches establish connections. I use the DynDNS service and the PRTG Network Monitor monitoring system for this. The brief essence of the method is as follows. Using PRTG, the availability of the channels of the central office is checked, and if the channel is dropped, on which the branches establish connections, then through the DynDNS API, PRTG automatically changes the DNS name registered on the DynDNS service to which the branches establish a connection by pulling a link on the Internet. The working method is 146%. I checked on more than fifty tunnels connected to the central office by a classic star. In case of recovery, you can change the IP address back, you can leave it as it is. Here as you wish.

It would seem that in the case of Mikrotik it also hinders to do the same? But here is the bandwagon from RouterOS. In peer settings, although you can specify the DNS name of the receiving end of the tunnel, but when you save it, it will be resolved and recorded as an IP address. In this case, you will have to invent scripts that will monitor channels (instead of PRTG) on Kerio Control and change the peer settings if the current channel to which the connection is established becomes unavailable. Plus a lot of dancing with IPSec policies. And I see this as a terrible headwash.

Now Kerio Control itself is remarkably able to provide fault tolerance in the event that it initiates a connection, in the tunnel configuration you can specify several IP addresses (or DNS names) of the receiving end of the tunnel. Thus, by creating on the Mikrotik side two peers that accept the connection, the desired fault tolerance can be achieved. Well, we drove our city ... An approximate diagram is shown in the figure. It is necessary to ensure the survivability of the tunnel when any WAN interface on Kerio or ISP on Mikrotik crashes (they are named differently to avoid confusion).



Let's start by setting up Mikrotik. Because Since it does not understand DNS names in the value of the IPsec Peers settings address, we will have to create two peers for both WAN interfaces of the central office. To do this, go to the terminal window and enter the command, replacing the address values ​​and the predefined key with your own:

/ip ipsec peer add address=109.172.42.XXX/32 dh-group=modp1536 exchange-mode=main-l2tp generate-policy=port-override hash-algorithm=sha1 nat-traversal=yes passive=yes secret=PASSWORD
/ip ipsec peer add address=95.179.13.YYY/32 dh-group=modp1536 exchange-mode=main-l2tp generate-policy=port-override hash-algorithm=sha1 nat-traversal=yes passive=yes secret=PASSWORD

I draw your attention to the fact that if you already created the peer according to the instructions given in the previous parts of the article and decided to use Winbox instead of the CLI and copied the peer already created before , then the passive setting (the same one that determines whether Mikrotik initiates or accepts connections) is not copied. Therefore, at this point, I highly recommend using the command line tools. The result of the command should be the successful creation of two peers awaiting connection from Kerio Control.

But this is not enough. If WAN1 falls on Kerio Control, the tunnel will be successfully reinstalled, but if ISP1 falls on Mikrotik, then the “remote ID” of the tunnel settings in Kerio Control in which we specified the gray ISP IP on the Mikrotik ISP interface will not match the real value . And instead of successfully reconnecting, we get a nice error in the Kerio Control administration console - "ID Mismatch."

Ambush? An ambush ... And I almost despaired because the fountain of thoughts had run out, I absolutely did not understand how to automate the change of this ID. He conjured with the hosts file, but to no avail. It's time to remember the words of one clever uncle with, probably, a completely gray-haired ass, who in the furry year told me - if nothing helps, then it's time to look into the manuals and logs. Well ... the manuals are not about us (the author’s homeric laughter here), he climbed into the Kerio Control debug-log, having previously included all messages related to IPSec in it. What can I say - the seeker, let him find it. In our case, when the “remote ID” parameter can dynamically change depending on which IP address the tunnel is connected to - in the Kerio Control tunnel settings, you can specify the value “% any” in the remote ID.
In the hostnames, enter through the semicolon all the addresses ISP1 AND ISP2 on Mikrotik and the value "% any" in "Remote ID" as in the figure below.



We save, apply, with happy eyes, look at the changed status of the tunnel on “Connected” and proceed to the verification. We emulate the fall of the main channel on Kerio Control by changing the places of the backup and main channel - the tunnel reconnected and was alive. We emulate the fall of the main channel on Mikrotik by pulling out the provider’s lace from it. While Kerio Control mastered that the tunnel was gone - it took about two minutes, but he still took the VPN to the reserve. Bingo!

All experiments were carried out on Kerio Control 8.1 and RouterOS 6.1. The names of the variables and ROS settings in the terminal commands given here correspond to this version (6.1). To date, version 6.10 has several changed settings names, but with minimal tuning everything works on the current versions of Kerio Control 8.2 and RouterOS 6.10. All of the above may be a little less than the ravings of a crazy IT specialist, I do not pretend to the correct wording and definitions and will gladly accept comments and recommendations, because for me Mikrotik is a new and mysterious animal, unlike Kerio Control, which is an almost read book.