VPN Types Explained: WireGuard, IKEv2 and OpenVPN on MikroTik RouterOS 7

A VPN is an encrypted route between things that ought to trust one another. It is not an invisibility cloak, a replacement for patching, or a certificate of moral superiority issued by a YouTube sponsor.

This guide compares the VPN protocols that can realistically connect Windows, macOS, Linux, Android and iOS to a MikroTik router. It then builds two complete WireGuard deployments: a site-to-site tunnel between two offices and a road-warrior tunnel for travelling users. IKEv2 and OpenVPN configurations are included for the cases where native operating-system support or an obstinate hotel network changes the answer.

The examples target current RouterOS 7 releases. They are written for systems you own or are authorised to administer. Replace every example hostname, subnet, key and password before use.

Short answer: choose WireGuard for most new deployments. Choose IKEv2 when managed devices and native clients matter more than simplicity. Keep OpenVPN as a compatibility escape hatch. Do not begin a new PPTP deployment unless the time machine is also part of the change request.

What “works on every OS” actually means

No serious VPN protocol behaves identically on every operating system.

• WireGuard has maintained clients for Windows, macOS, Linux, iOS and Android. Linux includes kernel support on modern distributions; the other platforms use an official application.
• IKEv2/IPsec is built into Windows, macOS and iOS. Android and Linux support it well through strongSwan, NetworkManager or vendor applications, but certificate installation and split tunnelling differ by platform.
• OpenVPN has clients for every major desktop and mobile platform. It is not normally built into the operating system, but it is familiar, mature and useful where TCP 443 is the only traffic a restrictive network will tolerate.
• SSTP is convenient in Windows environments, but it is not a sensible universal standard.
• L2TP/IPsec survives because old equipment survives. It is a compatibility choice, not the first design for a new network.
• PPTP is cryptographically obsolete. Its presence in a menu is not an endorsement.

“Cross-platform” therefore means that a supported client exists, not that every checkbox, DNS rule and route is magically identical.

Protocol comparison

The recommendation in plain English

Use WireGuard unless a requirement gives you a reason not to. Its configuration is small enough to understand during an incident, and every device should have a separate key that can be revoked without inconveniencing the rest of the company.

Use IKEv2 when users must connect with native operating-system controls, when an MDM can distribute certificates and profiles, or when an organisation already operates a certificate authority properly.

Use OpenVPN when users frequently meet networks that interfere with UDP, or when an existing OpenVPN client estate is more valuable than a fashionable migration. TCP 443 can resemble ordinary TLS traffic sufficiently to pass many restrictive guest networks, although tunnelling TCP inside TCP can perform badly when packets are lost.

What MikroTik RouterOS offers

RouterOS 7 supports WireGuard, IPsec/IKEv2, OpenVPN, SSTP, L2TP, PPTP and ZeroTier on supported hardware. MikroTik also provides Back to Home for a simpler app-led remote-access deployment on supported RouterOS devices.

RouterOS additionally offers tunnel interfaces such as GRE, IPIP and EoIP. Those are useful building blocks, but they do not provide confidentiality on their own. If someone proposes plain GRE over the public internet as “the VPN”, ask where the encryption went. It may be hiding with the documentation.

A practical decision table

Pre-flight checks before touching the router

Changing a firewall remotely is rather like repairing a ladder while standing on it. Use RouterOS Safe Mode, keep an out-of-band recovery path, and schedule a maintenance window.

1. Export and back up the configuration

/export show-sensitive=no file=before-vpn
/system/backup/save name=before-vpn password="<LONG-BACKUP-PASSWORD>"

The text export is useful for review. The binary backup is useful for restoring the same router. Download both from the router and protect them; configuration backups are sensitive even when exported without secrets.

2. Patch RouterOS first

/system/package/update/check-for-updates
/system/package/update/download

Review the release notes, then reboot during the approved window:

/system/reboot

After RouterOS is stable, check whether RouterBOARD firmware also needs an upgrade:

/system/routerboard/print
/system/routerboard/upgrade

Do not paste an upgrade and two reboots into a blind remote session. Confirm each stage.

3. Give each site a stable endpoint

If you do not have a static public address, MikroTik IP Cloud can provide a DNS name:

/ip/cloud/set ddns-enabled=yes
/ip/cloud/print

Record the reported DNS name. A DDNS name solves a changing public address; it does not solve CGNAT.

4. Detect CGNAT before blaming cryptography

Compare the WAN address shown by RouterOS with the public address reported by a trusted external service. If the router receives a private address, or an address in 100.64.0.0/10, inbound connections probably cannot reach it without provider assistance.

Common options are:

1. ask the ISP for a public address;
2. let the NATed site initiate the tunnel to a reachable site;
3. use a small public WireGuard hub;
4. use MikroTik Back to Home on supported hardware.

CGNAT is especially common on mobile connections and some Baltic consumer services. Test it; do not infer it from the colour of the provider’s logo.

5. Ensure the LAN subnets differ

If both offices use 192.168.88.0/24, routing cannot know which office a packet means. Renumber one site before the migration, or design explicit one-to-one NAT as a temporary compromise. Renumbering is less glamorous and far healthier.

6. Confirm time synchronisation

WireGuard itself is forgiving, but certificates, logs and IKEv2 are not. Configure NTP and verify the clock before troubleshooting certificate validity.

Playbook 1: WireGuard site-to-site between two MikroTik routers

This example connects a Riga office to a Liepāja office.

Replace the hostnames and subnets. Never copy a private key from this guide, another router or a colleague’s laptop. RouterOS generates the interface key when the WireGuard interface is created.

Step 1: create the Riga interface

/interface/wireguard/add name=wg-s2s listen-port=51820 mtu=1420 comment="Site-to-site VPN"
/ip/address/add address=10.255.250.1/30 interface=wg-s2s comment="WireGuard transit"
/interface/wireguard/print detail where name=wg-s2s

Copy Riga’s public-key from the last command. Do not export or send the private-key.

Step 2: create the Liepāja interface

/interface/wireguard/add name=wg-s2s listen-port=51820 mtu=1420 comment="Site-to-site VPN"
/ip/address/add address=10.255.250.2/30 interface=wg-s2s comment="WireGuard transit"
/interface/wireguard/print detail where name=wg-s2s

Copy Liepāja’s public key.

Step 3: add each router as a peer

On Riga:

/interface/wireguard/peers/add \
    name=liepaja \
    interface=wg-s2s \
    public-key="<LIEPAJA-PUBLIC-KEY>" \
    endpoint-address=liepaja.example.net \
    endpoint-port=51820 \
    allowed-address=10.255.250.2/32,192.168.20.0/24 \
    persistent-keepalive=25s

On Liepāja:

/interface/wireguard/peers/add \
    name=riga \
    interface=wg-s2s \
    public-key="<RIGA-PUBLIC-KEY>" \
    endpoint-address=riga.example.net \
    endpoint-port=51820 \
    allowed-address=10.255.250.1/32,192.168.10.0/24 \
    persistent-keepalive=25s

allowed-address has two jobs in this design: it tells RouterOS which source addresses belong to the peer, and it identifies traffic that may be sent to that peer. Do not use 0.0.0.0/0 on several peers of the same interface and hope the router develops intuition.

If only Riga has a public address, omit endpoint-address and endpoint-port from Riga’s definition of the Liepāja peer. Liepāja should keep Riga as its endpoint and use persistent-keepalive=25s. Once Liepāja initiates the connection, Riga learns its current endpoint.

Step 4: add the routes

On Riga:

/ip/route/add dst-address=192.168.20.0/24 gateway=wg-s2s comment="Liepaja LAN via WireGuard"

On Liepāja:

/ip/route/add dst-address=192.168.10.0/24 gateway=wg-s2s comment="Riga LAN via WireGuard"

Step 5: permit the WireGuard handshake

On both routers, the UDP input rule must be above the final WAN input drop rule. On a largely default RouterOS firewall, this command places it before the named drop rule:

/ip/firewall/filter/add \
    chain=input action=accept in-interface-list=WAN \
    protocol=udp dst-port=51820 \
    comment="VPN: allow WireGuard site-to-site" \
    place-before=[find where comment="defconf: drop all not coming from LAN"]

If that comment does not exist, inspect /ip/firewall/filter/print and place the accept rule manually above the first matching WAN drop. A perfectly written rule below an unconditional drop is decorative.

Step 6: permit traffic between the two LANs

On Riga:

/ip/firewall/filter/add \
    chain=forward action=accept \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    comment="VPN: Riga to Liepaja" \
    place-before=[find where comment="defconf: drop all from WAN not DSTNATed"]

/ip/firewall/filter/add \
    chain=forward action=accept \
    src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    comment="VPN: Liepaja to Riga" \
    place-before=[find where comment="defconf: drop all from WAN not DSTNATed"]

Add the equivalent pair on Liepāja. In a stricter environment, replace the broad LAN rules with the exact servers and ports required—for example, permit staff to an internal HTTPS service rather than granting one building diplomatic immunity in the other.

If your firewall has a broad source-NAT or masquerade rule that also matches the tunnel, add a no-NAT rule before it. The default RouterOS masquerade usually targets only out-interface-list=WAN, so inspect before adding anything:

/ip/firewall/nat/print detail

Example no-NAT rule on Riga, required only when an existing rule would otherwise translate the traffic:

/ip/firewall/nat/add \
    chain=srcnat action=accept \
    src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    comment="VPN: do not NAT Riga to Liepaja"

Move it above the matching masquerade rule. Create the reversed version on Liepāja.

Step 7: test in layers

From Riga:

/interface/wireguard/peers/print detail where name=liepaja
/ping 10.255.250.2 src-address=10.255.250.1 count=5
/ping 192.168.20.1 src-address=192.168.10.1 count=5

The peer should show a recent last-handshake and increasing transmit/receive counters. Then test an actual permitted service from a workstation, not merely ICMP from the routers.

If there is no handshake, check the endpoint, UDP input rule, public key, ISP NAT and port forwarding. If there is a handshake but no LAN traffic, check routes, allowed-address, forward rules, return routes and NAT. These are different failures; shouting “the VPN is down” at both of them saves no time.

Playbook 2: WireGuard road warrior for all major operating systems

This design gives each travelling device its own tunnel address and key.

Step 1: create the server interface

On the MikroTik:

/interface/wireguard/add name=wg-road listen-port=51821 mtu=1420 comment="Road-warrior VPN"
/ip/address/add address=10.66.66.1/24 interface=wg-road comment="Road-warrior gateway"
/interface/wireguard/print detail where name=wg-road

Record the router’s public key.

Step 2: generate Alice’s keys on Alice’s device

Install WireGuard from the official project or the relevant operating-system store. Create a new empty tunnel in the application; it generates a private and public key locally. Send only Alice’s public key to the administrator.

On Debian or Ubuntu, the command-line equivalent is:

sudo apt update
sudo apt install wireguard
umask 077
wg genkey | tee alice-private.key | wg pubkey > alice-public.key

On Fedora:

sudo dnf install wireguard-tools

Generate a separate key pair on every device. A shared private key turns revocation into a company-wide password-changing festival.

Step 3: add Alice as a peer

/interface/wireguard/peers/add \
    name=alice-laptop \
    interface=wg-road \
    public-key="<ALICE-PUBLIC-KEY>" \
    allowed-address=10.66.66.2/32 \
    comment="Alice managed laptop"

The router does not need an endpoint for a roaming client. It learns the source address when Alice initiates a handshake.

Step 4: open only the required firewall paths

Allow the handshake before the final WAN input drop:

/ip/firewall/filter/add \
    chain=input action=accept in-interface-list=WAN \
    protocol=udp dst-port=51821 \
    comment="VPN: allow WireGuard road warriors" \
    place-before=[find where comment="defconf: drop all not coming from LAN"]

Permit road warriors to the office LAN before the final forward drop:

/ip/firewall/filter/add \
    chain=forward action=accept \
    src-address=10.66.66.0/24 dst-address=192.168.10.0/24 \
    comment="VPN: road warriors to office LAN" \
    place-before=[find where comment="defconf: drop all from WAN not DSTNATed"]

That grants the VPN subnet access to the whole LAN. A production rule should normally narrow the destination address and port. For example, allow an internal web application:

/ip/firewall/filter/add \
    chain=forward action=accept protocol=tcp dst-port=443 \
    src-address=10.66.66.0/24 dst-address=192.168.10.50 \
    comment="VPN: road warriors to intranet HTTPS"

Place the narrow rule before the final forward drop, then omit the broad LAN rule.

If the router will provide DNS to VPN clients, enable the resolver and allow it only from trusted internal networks:

/ip/dns/set allow-remote-requests=yes
/ip/firewall/filter/add chain=input action=accept protocol=udp dst-port=53 src-address=10.66.66.0/24 comment="VPN: DNS UDP"
/ip/firewall/filter/add chain=input action=accept protocol=tcp dst-port=53 src-address=10.66.66.0/24 comment="VPN: DNS TCP"

Place both DNS rules above the input drop. Never expose the RouterOS resolver to the WAN.

Step 5: create a split-tunnel client profile

Alice’s configuration:

[Interface]
PrivateKey = <ALICE-PRIVATE-KEY>
Address = 10.66.66.2/32
DNS = 10.66.66.1

[Peer]
PublicKey = <MIKROTIK-WG-ROAD-PUBLIC-KEY>
Endpoint = vpn.example.net:51821
AllowedIPs = 10.66.66.0/24, 192.168.10.0/24
PersistentKeepalive = 25

The private key remains on Alice’s device. Import the configuration into the WireGuard app on Windows, macOS, iOS or Android. On Linux:

sudo install -m 600 alice.conf /etc/wireguard/wg0.conf
sudo wg-quick up wg0
sudo wg show

Enable it automatically only after a successful test:

sudo systemctl enable wg-quick@wg0

This split tunnel sends only VPN and office subnets through MikroTik. Ordinary internet browsing continues to use the local connection.

Step 6: optional full tunnel

To send all IPv4 traffic through the office, change the client peer to:

AllowedIPs = 0.0.0.0/0

Then allow and NAT internet-bound VPN traffic on the router:

/ip/firewall/filter/add \
    chain=forward action=accept \
    src-address=10.66.66.0/24 out-interface-list=WAN \
    comment="VPN: road warriors to internet" \
    place-before=[find where comment="defconf: drop all from WAN not DSTNATed"]

/ip/firewall/nat/add \
    chain=srcnat action=masquerade \
    src-address=10.66.66.0/24 out-interface-list=WAN \
    comment="VPN: road-warrior internet NAT"

Do not add ::/0 until IPv6 addresses, routing, DNS and firewall policy also exist inside the tunnel. Otherwise the result ranges from an IPv6 leak to an afternoon of mysterious timeouts.

Step 7: validate the road-warrior deployment

1. Connect from mobile data, not the office Wi-Fi.
2. Check /interface/wireguard/peers/print detail for a recent handshake.
3. Ping 10.66.66.1, then an explicitly permitted LAN host.
4. Open the actual service and confirm its logs show Alice’s VPN address.
5. For full tunnel, verify the public address changes to the office connection.
6. Test DNS resolution and disconnection behaviour.
7. Disable Alice’s peer and confirm access stops.

If ordinary websites work but internal names do not, the encryption is probably fine; investigate DNS. If names resolve but the service times out, inspect the forward firewall and the server’s own host firewall.

Alternative 1: IKEv2 road warrior with certificates

IKEv2 is attractive when Windows, macOS and iOS users should connect through native controls and an administrator can manage certificates. The price is a more exacting setup.

The following is a compact baseline, not a substitute for your organisation’s PKI policy. Use a resolvable server name such as vpn.example.net, verify time synchronisation, and protect the CA private key.

Create the CA and server certificate

/certificate/add \
    name=vpn-ca-template common-name=NMFF-VPN-CA \
    key-usage=key-cert-sign,crl-sign days-valid=3650
/certificate/sign vpn-ca-template name=NMFF-VPN-CA

/certificate/add \
    name=vpn-server-template common-name=vpn.example.net \
    subject-alt-name=DNS:vpn.example.net \
    key-usage=tls-server days-valid=825
/certificate/sign vpn-server-template ca=NMFF-VPN-CA name=NMFF-VPN-SERVER
/certificate/print

Use the actual signed certificate names printed by the router in the remaining commands.

Create the IKEv2 policy and address pool

/ip/ipsec/profile/add \
    name=ike2-vpn hash-algorithm=sha256 \
    enc-algorithm=aes-256 dh-group=ecp256

/ip/ipsec/proposal/add \
    name=ike2-vpn auth-algorithms=sha256 \
    enc-algorithms=aes-256-cbc pfs-group=none

/ip/pool/add name=ike2-pool ranges=10.88.0.10-10.88.0.200

/ip/ipsec/mode-config/add \
    name=ike2-conf address-pool=ike2-pool address-prefix-length=32 \
    split-include=192.168.10.0/24 system-dns=no static-dns=192.168.10.1

/ip/ipsec/policy/group/add name=ike2-policies
/ip/ipsec/policy/add \
    group=ike2-policies proposal=ike2-vpn \
    src-address=0.0.0.0/0 dst-address=10.88.0.0/24 template=yes

/ip/ipsec/peer/add \
    name=ike2-road exchange-mode=ike2 passive=yes profile=ike2-vpn

/ip/ipsec/identity/add \
    peer=ike2-road auth-method=digital-signature \
    certificate=NMFF-VPN-SERVER generate-policy=port-strict \
    mode-config=ike2-conf policy-template-group=ike2-policies

pfs-group=none is deliberate for broad road-warrior client compatibility in MikroTik’s official example. If policy requires different algorithms, test every supported client rather than choosing by aesthetic preference.

Create and export one client certificate

/certificate/add \
    name=alice-ikev2-template common-name=alice \
    key-usage=tls-client days-valid=825
/certificate/sign alice-ikev2-template ca=NMFF-VPN-CA name=NMFF-ALICE

/certificate/export-certificate \
    NMFF-ALICE type=pkcs12 export-passphrase="<UNIQUE-EXPORT-PASSWORD>"
/certificate/export-certificate NMFF-VPN-CA type=pem

Transfer the files through a protected channel, install the CA and client identity on the intended managed device, and delete loose export files after enrolment. Use a separate client certificate per user or device.

Permit IKEv2 at the WAN

/ip/firewall/filter/add chain=input action=accept in-interface-list=WAN protocol=udp dst-port=500,4500 comment="VPN: allow IKEv2"
/ip/firewall/filter/add chain=input action=accept in-interface-list=WAN protocol=ipsec-esp comment="VPN: allow IPsec ESP"

Place both above the final WAN input drop. Also ensure IPsec policy traffic is accepted before FastTrack and restrictive forward rules, following the current MikroTik IPsec documentation.

Windows, macOS and iOS can use their native IKEv2 clients. Linux and Android commonly use strongSwan or NetworkManager. The server identity must match vpn.example.net; a certificate for an IP address or a different name will not become correct because everyone is tired.

Treat split-include as route delivery, not access control. Enforce permitted destinations and ports in the router firewall.

Alternative 2: OpenVPN over TCP 443

OpenVPN is useful when the road warrior regularly encounters guest networks that block unfamiliar UDP traffic. RouterOS has its own OpenVPN implementation, so copy a RouterOS-specific configuration rather than assuming every community tutorial applies.

After creating suitable CA, server and per-client certificates, define an address pool and PPP profile:

/ip/pool/add name=ovpn-pool ranges=10.77.0.10-10.77.0.100
/ppp/profile/add \
    name=ovpn-road local-address=10.77.0.1 \
    remote-address=ovpn-pool dns-server=192.168.10.1

/ppp/secret/add \
    name=alice-ovpn password="<LONG-UNIQUE-PASSWORD>" \
    service=ovpn profile=ovpn-road

On RouterOS versions that support named OpenVPN server instances:

/interface/ovpn-server/server/add \
    name=ovpn-road disabled=no \
    certificate=NMFF-VPN-SERVER \
    default-profile=ovpn-road \
    protocol=tcp port=443 mode=ip \
    cipher=aes256-gcm auth=null \
    require-client-certificate=yes \
    tls-version=only-1.2

Allow TCP 443 on the WAN above the input drop and add narrow forward rules from 10.77.0.0/24 to the required internal services.

RouterOS does not implement OpenVPN cipher negotiation in exactly the same way as a standard OpenVPN server. Set the cipher explicitly on both sides. With AES-GCM, auth=null is expected because GCM already authenticates the encrypted data. Disable compression; it adds risk and is not required for a sound design.

A minimal client profile has this shape:

client
dev tun
proto tcp-client
remote vpn.example.net 443
nobind
persist-key
persist-tun
remote-cert-tls server
cipher AES-256-GCM
auth none
verb 3

<ca>
...CA certificate...
</ca>
<cert>
...Alice client certificate...
</cert>
<key>
...Alice private key...
</key>

Import it into OpenVPN Connect on Windows, macOS, iOS or Android, or use the distribution’s OpenVPN package on Linux. Keep the private key out of tickets, chat messages and shared drives.

Use UDP OpenVPN when performance is more important and the network permits it. Use TCP 443 as the compatibility fallback it is, not because the number 443 sprinkles extra security upon the packets.

The easy CGNAT option: MikroTik Back to Home

Back to Home is intended for simple remote access when the router is behind NAT or CGNAT. On supported RouterOS hardware and versions, the mobile application configures an end-to-end encrypted tunnel and MikroTik can relay traffic when direct connection is impossible. A WireGuard configuration can also be shared with a computer.

The normal setup is performed in the MikroTik Back to Home mobile app. Useful RouterOS checks include:

/ip/cloud/set ddns-enabled=yes
/ip/cloud/set back-to-home-vpn=enabled
/ip/cloud/print

Back to Home is excellent when the objective is “reach my network without learning every part of IKE.” It is less suitable when a business needs exact identity lifecycle, many segmented roles, central logging and reproducible infrastructure-as-code.

Hardening after the tunnel works

A handshake proves that keys were accepted. It does not prove the security policy is good.

Restrict router administration

Permit WinBox and SSH only from management networks and, if required, the VPN subnet:

/ip/service/set winbox address=192.168.10.0/24,10.66.66.0/24
/ip/service/set ssh address=192.168.10.0/24,10.66.66.0/24
/ip/service/disable telnet
/ip/service/disable ftp

Do not expose WinBox, SSH or the web administration interface to the whole internet merely because the VPN project ran late.

Prefer one identity per device

• Give every WireGuard device a distinct key and /32 address.
• Give every IKEv2 or OpenVPN device a distinct client certificate.
• Record the owner, device, issue date and revocation action.
• Disable or remove a peer immediately when a device is lost or retired.
• Never email a bundle containing both the configuration and its unprotected private key.

Segment VPN access

Do not automatically add a VPN interface to the trusted LAN interface list. Explicit firewall rules make privilege visible. Developers may need Git and staging; finance may need an accounting service; neither group necessarily needs the router management plane.

Log what matters

Record configuration changes, authentication failures, peer inventory and certificate expiry. Forward logs to a protected collector if the router is important enough that an incident could erase its local evidence.

Keep a tested removal procedure

For WireGuard, disable the affected peer:

/interface/wireguard/peers/disable [find where name="alice-laptop"]

Then confirm its existing access stops. Revocation procedures deserve a rehearsal before a laptop is stolen at an airport.

Troubleshooting matrix

Common mistakes worth avoiding

1. Overlapping office subnets. Encryption cannot resolve ambiguous routing.
2. One WireGuard key for everybody. It makes audit and revocation nearly useless.
3. An accept rule below a drop rule. RouterOS evaluates firewall rules in order.
4. Treating split routes as authorisation. A route tells a client where to send traffic; the firewall decides what is permitted.
5. Exposing management services instead of the VPN. The VPN exists so that management need not be public.
6. Using PPTP because it connected quickly. So did many regrettable things in 2003.
7. Ignoring IPv6. A perfect IPv4 full tunnel does not govern traffic that leaves over native IPv6.
8. Testing only from inside the office. Hairpin behaviour can disguise a broken public endpoint.
9. Changing algorithms without client testing. Standards contain choices; operating systems contain opinions.
10. Skipping recovery. Safe Mode, a backup and console access are part of the VPN configuration, even though they do not make the diagram prettier.

Final recommendation

For two MikroTik sites, deploy WireGuard with unique non-overlapping LANs, explicit routes, narrow forward rules and a reachable endpoint at at least one site.

For road warriors, start with WireGuard and issue one key per device. Use a split tunnel unless policy requires inspection of all traffic; if full tunnelling is required, design IPv6 and DNS deliberately.

Choose IKEv2 when managed native clients and certificate lifecycle are already organisational strengths. Keep OpenVPN over TCP 443 as a tested fallback for hostile networks. Use Back to Home for supported small deployments behind CGNAT where simplicity is the central requirement.

The best VPN is not the one with the longest acronym. It is the one whose routes, keys, firewall rules and removal procedure your team can still explain at two in the morning.

Official references

• MikroTik WireGuard documentation
• MikroTik WireGuard peer CLI reference
• MikroTik IPsec and IKEv2 documentation
• MikroTik RouterOS software specifications and VPN support
• MikroTik Back to Home documentation
• MikroTik OpenVPN documentation
• WireGuard official installation guide
• OpenVPN Connect documentation