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:

And under advanced:

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.

However, there is a poorly documented hidden “half-bridge” mode in the ZyXEL 660R routers. These cheap little single-port routers have the ability to push the public IP address and all it’s traffic onto a single device connected to the LAN port.

To do this, set the router up as normal with the username and password for your connection, then logout from the web interface. You’ll now need to telnet to the device, and enter the following:

poe bridge switch on
ip dhcp enif0 server lease 120
sys save

After this, reboot the router. Once it boots up and logs into your ISP, you should find that it gives you a single IP address on DHCP and that address will be an external fully public IP address.

Update: IntoTheUnknown uses this to build a SIP VoIP system, which of course can have problems when passing through any firewall or NAT conversion.