It’s unfortunate that the Mikrotik RouterOS manual on IPsec is not great – it’s sorely lacking in details and good examples, and what examples it does have are not well explained.
Recently I had to setup several Mikrotik RouterOS to ZyXEL VPNs and through I would document how it’s done.
First, a quick diagram to explain the setup we’re going to cover. Just imagine that the 10.0.0.0/24 network in the middle is in fact the internet.
We’ll configure the ZyXEL’s “public” address as 10.0.0.1 and the RB’s as 10.0.0.2.
First, the ZyXEL. It’s an older ZyXEL 652H, but the same settings apply to almost all of the VPN enabled ZyXEL devices. Create the VPN as you normally would on the ZyXEL, ensuring to use subnet’s for your local and remote networks, as well the IP addressess of the ZyXEL and Mikrotik for the Peer IDs:
Now, on RouterOS we start by configuring the policy for this VPN. This is the equivelent of the first page of the ZyXEL configuration. Open the IP->IPsec window in WinBox, and create a new policy as follows:
Next, switch to the “Peers” tab and create a new peer, using the public address of the ZyXEL as the address:
There’s a few confusing extras here that don’t appear on the ZyXEL.
- Proposal Check – Determines how proposed lifetimes are handled. Setting this to “Obey” is the most flexible as it will make RouterOS conform to whatever the remote site proposes.
- DH Group – Mikrotik use the actual algorithm names as opposed to the normal “DH1” or “DH2”. The table below shows the mapping between these:
Diffie-Hellman Group Name Reference Group 1 768 bit MODP group RFC2409 Group 2 1024 bits MODP group RFC2409 Group 3 EC2N group on GP(2^155) RFC2409 Group 4 EC2N group on GP(2^185) RFC2409 Group 5 1536 bits MODP group RFC3526 Note: I was not able to get group 2 to work. It results in a proposal mis-match error.
- Generate Policy – Appears to dynamically generate the policies depending on what details have been supplied by the remote side. May be of use for dynamic VPNs.
- Lifebytes – Session will be reconnected after X bytes have been encrypted. Best to leave this alone.
- DPD – Mikrotik do not offer any explanation for this, other than that experiments on the official forums seem to confirm that it only appears works with other RouterOS devices. Juniper’s documentation explains that it stands for “Dead Peer Detection”.
There’s one last step after this. In RouterOS, NAT is performed before IPsec takes place. This means that any general masquerade or 1:1 NAT rules will take place before the VPN is reached, and the now NAT’d addresses will not be directed across the VPN. To avoid this we need to add a NAT rule at the very top of the table:
By placing this rule at the top of the NAT table under IP->Firewall, when a packet is directed from the RouterOS LAN towards the VPN destination subnet, the “accept” action will cause the NAT table to stop processing, and thus never reach any other NAT rules.
There is no way to force RouterOS to establish the connection other than by sending traffic.It’s also important to note that v4.0 of RouterOS appears to suffer from a bug that causes the VPN to establish but not correctly route traffic across it.
I connected Cyberguard SG300 with mikrotik router.
This blog was very useful.
Thank You!
you save my ass thank you thank you thank you :))
Thankyou very much! This was very helpful.
Good one especially the last step on NAT bypass rule!
Hi
Such A Useful Implementation For IPSEC
I Wonder IF you Can Write Something Like This For OPENVPN Configuration Using Mikrotik
thanks
Hi, I’m trying to connect from Watchguard x20ew to Zyxel P2612. I wonder, where did you get the IP Address you placed in ADDRESS INFORMATION? I am confused what to enter there. thanks.
Ow.. kindly disregard my last comment. I read it carefully and realized that it was their Public IP Addresses.
What a motherfucken great article!.Very powerfully clear