Site to Site Mikrotik IPSec tunnel

In the third part of the Mikrotik IPSec series, we will discuss the most common scenario – how to connect two remote sites using Mikrotik IPSec services. In this scenario, we will connect two separated LAN segments and establish communication between at least two hosts.

We will not cover the theoretical part of this process, nor the details of our virtual lab. If you are not feel comfortable with this article, please refer to these posts for a detailed explanation.

Our goal is to establish the communication between two or more hosts, using the Internet. We have at least one host on each side. They share some unencrypted data over different protocols. Therefore, in theory, any malicious person can intercept and sees our data exchange.


In our scenario, we need to establish communication between the Contoso and FabrikaM networks. Let me remind you of our environment.

0 - virtuelna struktura

The FabrikaM server is RouterOS x86-based VM. It uses script that every 10 minutes sending an e-mail. The e-mail server is in the Contoso network and it’s not accessible for other networks. Several recipients are located in the FabrikaM domain.

Before we begin, we need to fill in a IPsec configuration document. This document will help us to avoid mistakes.


Step one – communication between routers

Our first step in the building of this tunnel will be defining the IPSec peers. The IPSec peer is an end-point for IPSec tunnel. This end-point device is usually another router (like Mikrotik or Cisco) or firewall (like Cisco ASA).


In our case, we will establish communication between two Mikrotik routers. The Contoso router is the x86 VM with RouterOS v6.36. The FabrikaM router is also x86 VM, but with RouterOS v4.17.

There is no difference if the router is the hardware appliance (a.k.a. Mikrotik Routerboard), the software version installed on the hardware machine or it’s the pure virtual solution. All features are the same within the same RouterOS version.

We can configure all options either from the WinBox GUI tool or through the command line interface. In the RouterOS v6 the IPSec dialog is a quite tall and you can find a more convenience to work from the command line. I will show you both ways and you choose the one that fits you the best. As a bonus, you can use my demo scripts for your own work.


Configuring peer on the Contoso side

In the WinBox GUI tool, we should open IP > IPSec, then the Peers tab. We can add new peer definition with the button with plus sign. This is a dialog with the default options:


As we can see on the picture of the virtual lab, the public IP address of the FabrikaM router is

We will use the pre-shared key authentication method. The hash algorithm will be SHA-1 and the encryption algorithm will be AES-256. As the both routers are on the static public IP addresses, we can send initial contact and we don’t need to send the network traffic through NAT device. The DPD option will be enabled with interval of 120 seconds.

The lifetime for the tunnel will be 1 day and we will use DH group 2 for the tunnel key. Oh, and our little secret is Test1234. Please, don’t tell anyone.

Having all this, thus we configure the peer:


If you prefer the command line, our command will be:

/ip ipsec peer add address= port=500 auth-method=pre-shared-key secret=Test1234 hash-algorithm=sha1 enc-algorithm=aes-256

We can check a new peer definition with the command:

/ip ipsec peer print

As last, we can even check status of the connection:

/ip ipsec remote-peers print

As we can see, our router initiated the connection immediately. However, the connection is still not established. We missing the another party.



Configuring peer on the FabrikaM side

We need to perform similar adjustments on the FabrikaM side. The only difference is the IP address of the peer. Now this address is the public IP address of the Contoso router –

The dialog for IPSec Peer configuration is lesser and with fewer options:


We will change necessary parameters and our configuration will be:


Again, we can execute the commands from the terminal:

/ip ipsec peer add address= auth-method=pre-shared-key secret=Test1234 hash-algorithm=sha1 enc-algorithm=aes-256 dh-group=modp1024 send-initial-contact=yes dpd-interval=120s dpd-maximum-failures=5

/ip ipsec peer print

/ip ipsec remote-peers print


The scripts are slightly different as the syntax changed between RouterOS versions. If your run the script and it’s failed, check the syntax related to the peer IP address.


Checking the IKE  phase I tunnel status

When both sides are set, we should check the tunnel status. We are already familiar with the command

/ip ipsec remote-peers print

We can see from our example above that the tunnel state is established. We configured correctly both sides and they interconnected together.

We can check the tunnel status also from the WinBox. This is on the tab named Remote Peers. On the Contoso side:


Also from the FabrikaM side:


We have the tunnel between the routers. However, this tunnel is not useful. We cannot send any data through it yet. We need to declare to the router what we want with this tunnel and when to send traffic through it.


Step two – defining protection rules for the tunnel

We need to define the set of the rules that will protect the data exchange between the hosts. This set of the rules is named Proposal.

Every RouterOS device always have the default proposal. However, a configuration of the default proposal changes between the versions.

It’s a good practice to build the new proposal for every remote network. Therefore, we will set the new proposals on both sides.


New proposal on the Contoso side

We will choose the Proposals tab in the IPSec window. We can see that there is the default proposal. It looks like this in RouterOS v6.36:


As you can see, we have many different options. A good practice is to use strongest possible option that both sides supporting. In the real life, we can have on the one side older device or device with limited capabilities. In such case, we must fit these settings with the capabilities of the older device.

We will make our new proposal named FabrikaM. It will be slightly different the default:


The same task from the command line:

/ip ipsec proposal print

/ip ipsec proposal add name=FabikaM auth-algorithms=sha1 enc-algorithms=aes-256-cbc lifetime=30m pfs-group=modp1024

I need to point out that AES-CBC is the same as the algorithm used in previous versions of the RouterOS. Other versions of the AES algorithms are advanced.


New proposal on the FabrikaM side

We need to make the same changes on another side. In this case, we must fit all parameters between the sides. Of course, the name is optional and you can be creative here.

Keep in mind that the different configuration on every side is the most common mistake in the IPSec implementation.

Here is the default proposal in the older version 4.17:


Our proposal will looks like this:


Here is the command line:

/ip ipsec proposal print

/ip ipsec proposal add name=Contoso auth-algorithms=sha1 enc-algorithms=aes-256 lifetime=30m pfs-group=modp1024


Step three – defining rules that will trigger the tunnel

We are almost there. The last step in the IPSec configuration is to define one or more rules that will activate the tunnel. There is no default policy. We must create at least one to raise the tunnel.

The policies are enlisted on the Policies tab. We can make the new one from that tab too.

The number of the rules depends on whether we need communication between the multiple single hosts on every side or we will allow the whole network range. We can define the rule per single IP address (or per single host) or per network range (all hosts with IP addresses in that range can use that rule).

Those rules must be the same on both sides. That means that single host rule on the one side cannot communicate with network-based rule on another side.

Furthermore, every companion rules on both sides must using the same tunnel type, encryption protocols, lifetime, PFS group, etc. This is also common mistake in the configuration.


Configuring the Contoso side

The first step in the policy creation process is to define hosts or networks on both sides of the tunnel.

In our case, we will establish communication between two networks. The Contoso network range is and the FabrikaM network range is We’re on the Contoso router and therefore the Contoso network (LAN) range is the source address.


We should specify between which two public IPs we want this tunnel, the type of the tunnel, encryption protocol and the proposal. That must be configured on the second page.


Please, pay attention that the level should always be unique. That will establish new tunnel for every pair of the hosts that want to use this policy.

The commands are:

/ip ipsec policy print

/ip ipsec policy add src-address= dst-address= sa-src-address= sa-dst-address= ipsec-protocols=esp proposal=FabikaM tunnel=yes level=unique

/ip ipsec policy print


Configuring the FabrikaM side

We will do the similar configuration on the FabrikaM side. We just need to replace the values for the source and destination addresses.


The second page:


Here is the script:

/ip ipsec policy print

/ip ipsec policy add src-address= dst-address= sa-src-address= sa-dst-address= level=unique tunnel=yes ipsec-protocols=esp proposal=Contoso

/ip ipsec policy print


Step four – bypassing the masquerade (or outgoing NAT)

In the simple demonstration like this, the traffic will goes through the tunnel during the test. However, if we have outgoing NAT or masquerade, we must specify to the router that we have special traffic that shouldn’t be send through that NAT rule.

We need to define the following rules on the Contoso and FabrikaM sides respectively:

/ip firewall nat add chain=srcnat src-address= dst-address= action=accept

/ip firewall nat add chain=srcnat src-address= dst-address= action=accept

You can add them even through WinBox. It’s important that those rules exist and that they are on the top of the list of the IP Firewall NAT rules. Therefore, if the tunnel is not established, check these rules.


It’s a live

After a few minutes, the FabrikaM server will send the first e-mail. That will trigger the IPSec tunnel rules and establish the communication. When we want to check the e-mail, we will again trigger the IPSec communication.

We can check that from the WinBox on the Installed SA tab. On the Contoso side, this looks like this:


It’s a similar on the FabrikaM side:


Don’t be confused with different amounts of the exchanged bytes. The screenshots are not taken in the same time.

Of course, we can check this from the command line

ip ipsec installed-sa print

Here is the example from the Contoso router:


Our tunnel is running. We can check the e-mail from the workstation FabrikaM WS02:


It works. The tunnel is up and running. That was our goal.

The subject has MUM16 in the beginning, as this was part of my presentation for the MUM Serbia 2016.


Now it’s your turn

Although setting up IPSec tunnel is not too complicated, there are many pitfalls. It’s very easy to overlook some parameter. One small parameter can alter the whole configuration step and block the IPSec tunnel.

You can use the scripts that I provided here in your own lab. Change them. Try different settings and options. The entire file with scripts can be downloaded here:

Site-2-Site IPSec demo scripts

Don’t be afraid to experiment. You can learn a lot about the IPSec configuration when practicing it.

Stay tuned.


8 thoughts on “Site to Site Mikrotik IPSec tunnel

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.