MikroTik OpenVPN Setup: 🔒 Client Configuration & VPN Routing

OpenVPN on MikroTik: what actually works (and what doesn't)

Yes, you can run OpenVPN on MikroTik but mostly as a client, and only if the server config plays nice with RouterOS. That's the short version. The longer version involves cipher mismatches, certificate quirks, and a few routing decisions that can lock you out of your own router if you're not careful.

I've configured this setup more times than I can count, on everything from a hAP ac² in someone's home office to a CCR1009 sitting in a small ISP rack. It works. It works well, actually once you understand where MikroTik's OpenVPN implementation draws the line.

This guide focuses on the most common scenario: MikroTik as an OpenVPN client connecting to a remote OpenVPN server (often a VPS you control). We'll also cover when MikroTik can act as a server, why a lot of commercial .ovpn profiles fail, and how to fix the routing once the tunnel is up.

MikroTik OpenVPN support and RouterOS limitations

Before you copy a single setting, let's set expectations. MikroTik's OpenVPN implementation is real, but it's not a drop-in replacement for the desktop OpenVPN client. There are gaps. Knowing them up front saves hours.

Does MikroTik support OpenVPN client, server, or both?

Both, technically. RouterOS has an OVPN client (under PPP) and an OVPN server mode. In practice, most admins use it as a client. Why? Because the server side has historically lacked features like tls-auth, full UDP support in older versions, and push-route support though newer RouterOS releases have closed some of those gaps.

If you need a feature-complete OpenVPN server, run it on a Linux VPS and point your MikroTik at it. That's the path with the fewest surprises.

RouterOS version differences that affect OVPN

This part is honestly a moving target. Older RouterOS versions (pre-7) supported OpenVPN over TCP only, with a limited set of ciphers. RouterOS 7.x added UDP support and broadened the cipher list — including AES-GCM variants. If you're stuck on an older firmware, you'll feel the limits fast.

Common compatibility issues with commercial VPN profiles

Here's the painful truth. Most commercial VPN providers — NordVPN, ExpressVPN, Surfshark, you name it — ship .ovpn files designed for the desktop OpenVPN binary. They use options MikroTik doesn't honor: tls-crypt, compress lz4, auth-user-pass with embedded inline certs, push directives, you name it.

You can sometimes massage these profiles to work, but it's tedious. If you want a VPN that just works on MikroTik, run your own server.

Key takeaway: MikroTik OpenVPN works best when the server config is built with RouterOS compatibility in mind. Fighting a third-party profile is a losing game; building a matching server is the winning one.

What you need before configuring OpenVPN on MikroTik

Setup goes smoother when you've gathered everything before touching WinBox. Here's the checklist I run through every single time.

Information you need from the OpenVPN server

• Server hostname or public IP — the address your router will dial out to
• Port — typically 1194, but anything goes
• Protocol — TCP or UDP (UDP requires RouterOS 7+)
• Cipher — must match what the server is configured with
• Auth algorithm — SHA1, SHA256, etc.
• Authentication method — certificate only, or certificate + username/password

Required certificates, keys, and login details

You'll typically need three files: the CA certificate (ca.crt), the client certificate (client.crt), and the client private key (client.key). If your server uses username/password on top, grab those too.

One quick gotcha: if the private key is password-protected, you'll need that passphrase to import it into RouterOS. There's no way to recover it later.

How to configure a MikroTik OpenVPN client

Now we get into the actual work. I'll walk through this with WinBox in mind because that's how most admins do it, but every step has a CLI equivalent. I'll show both where it helps.

Step 1: Import certificates first

Don't skip this. The OVPN client interface needs the certs to exist before you can attach them. Upload your ca.crt, client.crt, and client.key files into the router's Files section — drag-and-drop in WinBox works fine.

Then in System → Certificates, click Import and select each file in turn. If your private key has a passphrase, RouterOS will prompt for it. After import, you should see entries with names like cert_1, cert_2. The flag column tells you what's there: K means a private key is attached, T means trusted, A means authority.

Step 2: Create the OVPN client interface

Navigate to PPP → Interface → + and select OVPN Client. (In some RouterOS builds it's under Interfaces → OVPN Client directly.) You'll get a dialog with a bunch of fields. Here's what each one means in practice:

• Name — anything memorable. I usually use ovpn-out1 or vpn-to-vps.
• Connect To — your server's hostname or IP
• Port — match the server (1194 by default)
• Mode — ip for routed (TUN), almost always what you want
• User / Password — if your server uses auth-user-pass
• Profile — leave as default unless you've created a custom one
• Certificate — pick the client cert you imported
• Auth — match server (e.g. sha1, sha256)
• Cipher — match server (e.g. aes-256-cbc)
• Verify Server Certificate — turn this on if you imported the CA and want strict checking

Or if you prefer the terminal:

/interface ovpn-client add \
  name=ovpn-out1 \
  connect-to=vpn.example.com port=1194 \
  protocol=udp \
  user=myuser password=mypass \
  certificate=client_cert \
  auth=sha256 cipher=aes-256-cbc \
  add-default-route=no \
  disabled=no

Notice add-default-route=no. Leave it that way for now. We'll handle routing manually in the next section, and you really don't want the default route flipping while you're testing.

Step 3: Verify the tunnel is up

Hit Apply, then Enable. If everything's right, the interface will show R (running) within a few seconds. Open the interface and check the Status tab — you should see "connected" and an assigned IP.

If it's not coming up, check the logs:

/log print where topics~"ovpn"

The log messages are usually enough to diagnose the issue. Auth failed? Wrong creds. TLS error? Cert problem. Connection refused? Server isn't listening or a firewall is in the way.

How to import OpenVPN certificates into MikroTik correctly

I covered the basics above, but cert problems are so common they deserve their own section. Here's where most setups go sideways.

Which certificate files RouterOS accepts

RouterOS handles .crt, .cer, .pem, and .key files natively. PKCS#12 bundles (.p12 or .pfx) work too — and they're often easier because the cert and key come together. If your server admin can export a .p12, take it.

What RouterOS doesn't love: certs embedded inside .ovpn files between <ca>...</ca> tags. You'll need to extract those into separate .crt files first. Open the .ovpn in any text editor, copy each block (including the -----BEGIN CERTIFICATE----- lines), and save as a separate file.

How to mark certificates as trusted

After import, double-click the CA cert in System → Certificates and tick Trusted. Without this, the OVPN client may refuse to verify the server. From the CLI:

/certificate set ca_cert trusted=yes

What to do if certificate import fails

The usual suspects, ranked by frequency:

• Wrong format. A DER-encoded cert won't import as PEM. Convert with OpenSSL: openssl x509 -inform der -in cert.der -out cert.pem
• Bad passphrase on the private key. Try the import again and watch the password field carefully.
• Key/cert mismatch. The client cert and key must be a matched pair. If they aren't, the import succeeds but the tunnel fails at TLS handshake.
• Missing intermediate CA. If your server uses a chain, you need to import every cert in it.

Pro tip: if you're setting up your own server anyway, use a VPS-hosted OpenVPN deployment where you control the entire certificate chain. No more guessing what the provider's CA bundle actually contains.

MikroTik VPN routing: full tunnel and split tunnel

The tunnel's up. Now what? By default, no traffic uses it. You decide what gets routed through. This is where MikroTik OpenVPN setups most often go wrong — the connection works, but no traffic flows, or worse, you lock yourself out.

How to route all traffic through OpenVPN (full tunnel)

Full tunnel means every packet from your LAN exits through the VPN. Useful for branch offices, privacy, or accessing resources that whitelist your VPS IP.

Warning: changing the default route can lock you out of remote management instantly. If you're configuring this from a remote location, set up a recovery method first — either a scheduled config rollback or out-of-band access.

Here's the safer way. Add a route through the OVPN interface with a lower distance than the existing default:

/ip route add dst-address=0.0.0.0/0 gateway=ovpn-out1 distance=1 comment="VPN default"

Or in the OVPN client settings, set add-default-route=yes. Either approach works. The CLI route gives you more control over distance and routing marks.

How to route only selected subnets through the VPN (split tunnel)

Split tunnel sends some traffic through the VPN and the rest through your normal ISP. This is the right choice when you only need to reach a remote office subnet, an admin VPS, or specific cloud resources.

Two approaches. Simple route-based:

/ip route add dst-address=10.50.0.0/16 gateway=ovpn-out1 comment="Remote office"

Or per-source policy routing if you want only certain LAN devices to use the tunnel:

/ip firewall mangle add chain=prerouting src-address=192.168.88.50 \
  action=mark-routing new-routing-mark=via-vpn passthrough=no

/ip route add dst-address=0.0.0.0/0 gateway=ovpn-out1 \
  routing-mark=via-vpn distance=1

The mangle rule tags packets from a specific host, and the marked route sends only those packets through the VPN.

How to avoid losing MikroTik management access

Before you flip the default route, add a static route for your management network so it always uses the local gateway:

/ip route add dst-address=YOUR.MGMT.IP/32 gateway=ISP-gateway distance=1

Validate routing before walking away. If the trace shows your VPS as the second hop, full tunnel is working. If it shows your ISP, your route isn't being preferred — check distances and gateway reachability.

MikroTik firewall and NAT rules for OpenVPN traffic

Tunnel up, route in place, still nothing? It's almost always NAT, DNS, or a firewall rule. In that order. Here's how to fix each.

When masquerade is required

If your LAN clients are using private IPs (192.168.x.x, 10.x.x.x) and you want them to reach the internet through the VPN, you need to masquerade outgoing traffic on the OVPN interface:

/ip firewall nat add chain=srcnat out-interface=ovpn-out1 \
  action=masquerade comment="VPN egress NAT"

Without this, the VPS sees raw private IPs and has no way to send replies back. Packets vanish into the void. Frustrating to debug if you don't know to look here.

DNS settings that prevent resolution issues

Common scenario: tunnel works, you can ping 8.8.8.8, but google.com doesn't resolve. That's DNS. By default, your LAN clients are still using whatever DNS they had before — possibly your ISP's, which may be unreachable through the VPN, or which leaks queries outside the tunnel.

Fix it by pushing a public or VPS-hosted DNS resolver to clients. Configure DHCP to hand out 1.1.1.1 or your VPS's resolver, and make sure RouterOS's own DNS isn't quietly responding with cached ISP results.

Firewall rules that can break the tunnel

If you have a strict input/forward chain, the OVPN interface might be getting dropped. Check that:

• Forward chain allows traffic from LAN to ovpn-out1 and back
• Input chain allows the OVPN interface for established/related
• Interface lists include ovpn-out1 in the WAN list (so existing WAN-style rules apply)

Quick summary: if the tunnel is up but traffic fails, check route, then NAT, then DNS in that exact order. Nine times out of ten, that sequence finds the problem.

MikroTik OpenVPN troubleshooting steps

This section is the one you'll bookmark. Real failure modes, real causes, real fixes.

The diagnostic order

When OpenVPN won't behave, work through this sequence. Don't skip steps — even if you're sure the issue is "obviously" cert-related.

1. Can you reach the server's IP from the router? /ping vpn.example.com
2. Is the port open? /tool/torch on the WAN interface, or test from another machine
3. Are the OVPN logs showing handshake attempts? /log print where topics~"ovpn"
4. If handshake fails, is it auth, cert, or cipher?
5. If handshake succeeds but no traffic, route → NAT → DNS

Authentication failed and TLS errors

"Auth failed" almost always means credentials. But sometimes it means the client cert isn't matched to the server's CA. The error message is the same. Check both.

TLS errors on the other hand are usually one of three things: untrusted CA, system clock drift on the router, or a cert that's actually expired. The clock issue is sneaky — if your MikroTik just booted and hasn't synced NTP yet, certs can appear "not yet valid." Fix the time first.

MTU, MSS, and unstable tunnel issues

If your tunnel works for small packets but breaks on anything large (web pages load partially, SSH sessions hang), it's MTU. OpenVPN adds overhead, and if the underlying network can't fragment, big packets get dropped silently.

Two fixes, applied together:

/interface ovpn-client set ovpn-out1 mtu=1400

/ip firewall mangle add chain=forward protocol=tcp tcp-flags=syn \
  out-interface=ovpn-out1 action=change-mss new-mss=clamp-to-pmtu

The MSS clamp tells TCP sessions to negotiate smaller segment sizes, which keeps everything within the tunnel's MTU.

OpenVPN vs WireGuard vs L2TP on MikroTik

Honest take: if you're starting fresh in 2024 or later, WireGuard is usually the better pick on MikroTik. It's simpler, faster, and has been native in RouterOS since version 7. OpenVPN still earns its keep when you're connecting to existing infrastructure, when policy demands it, or when you need username/password auth without a separate identity layer.

For deeper comparisons, check out WireGuard vs OpenVPN and OpenVPN vs L2TP.

Key takeaway: for new MikroTik deployments, WireGuard is often the easiest road. Choose OpenVPN when compatibility, existing infrastructure, or specific auth requirements push you that way.

Using a VPS-hosted OpenVPN server for MikroTik

I've hinted at this throughout, but it deserves a proper section. The cleanest, most predictable MikroTik OpenVPN setup pairs your router with a VPN server you control on a VPS.

Why a VPS gives more control than a third-party VPN profile

• Cipher and auth control — pick exactly what RouterOS supports, no fighting with tls-crypt
• Fixed public IP — useful for whitelisting, DNS, and stable site-to-site routing
• Custom routing — push your own routes, define your own subnets
• Audit trail — your logs, your retention policy, your call
• Lower latency — pick a region close to your router

Recommended server requirements for a MikroTik VPN endpoint

OpenVPN is CPU-bound. The cipher does the work, and a small VPS can saturate quickly under load. Rough sizing:

• Light use (1–5 clients, casual traffic): 1 vCPU, 1 GB RAM, any modern Linux
• Branch office (10–25 clients, business traffic): 2 vCPU, 2 GB RAM
• Heavy throughput (gigabit-class): 4+ vCPU, AES-NI capable CPU, fast network port

Build a reliable MikroTik VPN stack

Launch a VPS-hosted OpenVPN endpoint, choose a region close to your router, and connect with settings you fully control. No more provider profiles that don't match RouterOS. No more guessing what cipher the other end speaks. Just a VPN that works the way you configured it.

Get started with MikroTik VPS hosting, browse Linux VPS options, or pick a VPS and build from scratch.