Remote MikroTik Management via VPS

Summary A public VPS makes a reliable bridge to reach MikroTik routers behind NAT, double NAT, or CGNAT — the router initiates an outbound OpenVPN tunnel to the VPS, and you reach the router (or any LAN device behind it) through that tunnel. This guide walks through VPS provisioning, OpenVPN server setup with easy-rsa, MikroTik client configuration, port forwarding for WebFig and LAN services, and the hardening checklist that keeps the setup safe long-term.

How does VPS-based MikroTik remote access work?

A public VPS acts as a stable rendezvous point with a permanent public IP. The MikroTik initiates an outbound VPN tunnel to the VPS (it never accepts inbound connections, so NAT and CGNAT on the customer side don’t matter), and the VPS holds DNAT rules that map public ports to the tunnel’s far end. Administrators reach the router and LAN devices through the VPS’s public IP, with traffic encrypted end-to-end through the VPN.

The flow looks like this: Administrator ⇄ Public VPS ⇄ MikroTik (behind NAT) ⇄ Internal device. This pattern works whether you use OpenVPN (covered here), WireGuard (see our WireGuard remote management guide), Tailscale (see the Tailscale tutorial), or SSH reverse tunnels — the principles are the same; the protocol differs.

Step 1: Create the VPS

Provision a small VPS at any provider — DigitalOcean, Vultr, Hetzner, AWS Lightsail all work. Specs:

• OS: Ubuntu 22.04 LTS.
• Size: 1 vCPU, 1 GB RAM is enough for management workloads with a handful of clients.
• SSH: add your SSH public key for secure root access.

For this guide:

• VPS IP: 138.197.120.24
• User: root

Step 2: Prepare the VPS with OpenVPN

SSH into the VPS and install the prerequisites:

ssh root@138.197.120.24
apt update && apt upgrade -y
apt install -y openvpn easy-rsa iptables

Create the PKI and server certificates with easy-rsa:

make-cadir ~/openvpn-ca
cd ~/openvpn-ca
./easyrsa init-pki
./easyrsa build-ca nopass
./easyrsa gen-req server nopass
./easyrsa sign-req server server
openvpn --genkey --secret ta.key

Enable IP forwarding (persist in /etc/sysctl.conf for reboots):

sysctl -w net.ipv4.ip_forward=1

Add a NAT masquerade rule so tunnel clients can egress through the VPS public interface (eth0):

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Create a minimal /etc/openvpn/server.conf (the standard OpenVPN documentation covers the file content) and start the service. Lock down SSH (keys only), enable a host firewall, and consider fail2ban for extra protection — the VPS is now reachable from the internet and worth securing properly.

Step 3: Build client credentials

On the VPS, generate a client certificate and collect the files the MikroTik will need:

• ca.crt
• client1.crt
• client1.key
• ta.key (if used)
• client.ovpn (client config)

A minimal client.ovpn:

client
dev tun
proto udp
remote 138.197.120.24 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client1.crt
key client1.key
cipher AES-256-CBC
verb 3

Step 4: Configure the MikroTik as OpenVPN client

Upload the client certs and client.ovpn to the MikroTik (drop them in the Files list). In a Winbox terminal:

/interface ovpn-client add name=vpn-to-vps connect-to=138.197.120.24 port=1194 \
    user=vpnuser password="senha123" profile=default-encryption add-default-route=no

/interface ovpn-client print

Expect status like:

status: connected
uptime: 00:00:45
remote-address: 10.8.0.1
local-address: 10.8.0.2

Adjust add-default-route to control whether the MikroTik sends all WAN traffic through the tunnel — for management-only use cases, leave it no.

Step 5: Access the MikroTik via the VPS

DNAT on the VPS forwards a public port to the router’s WebFig (or other service):

iptables -t nat -A PREROUTING -p tcp --dport 8081 -j DNAT --to-destination 10.8.0.2:80
iptables -t nat -A POSTROUTING -p tcp -d 10.8.0.2 --dport 80 -j MASQUERADE

Now http://138.197.120.24:8081 reaches the router’s WebFig through the tunnel.

Step 6: Access internal LAN devices

To reach a device behind the MikroTik (e.g., a camera at 192.168.88.100), add a DNAT rule on the VPS and a dst-nat on the MikroTik:

On the VPS:

iptables -t nat -A PREROUTING -p tcp --dport 8082 -j DNAT --to-destination 10.8.0.2:8082

On the MikroTik, forward the incoming tunnel port to the internal host:

/ip firewall nat add chain=dstnat protocol=tcp dst-port=8082 \
    action=dst-nat to-addresses=192.168.88.100 to-ports=80

Access the camera at http://138.197.120.24:8082. Traffic flow: public IP → VPS DNAT → OpenVPN tunnel → MikroTik dst-nat → internal device.

Step 7: Automation and hardening

A few practical habits that pay off long-term:

• Use SSH keys for VPS access and strong passwords on the MikroTik.
• Add a watchdog script on the MikroTik to auto-restart the tunnel if it drops.
• Use static IPs or DDNS for the VPS if you ever change providers.
• Expose only the ports you actively need; keep the rest firewalled.
• Log connections and alert on unexpected access attempts.

Example MikroTik watchdog script (restart the tunnel if it stops):

:if ([/interface ovpn-client get vpn-to-vps running] = false) do={
    /interface ovpn-client disable vpn-to-vps
    /delay 3
    /interface ovpn-client enable vpn-to-vps
}

Security checklist

• Keep the VPS OS and OpenVPN patched.
• Use unique client certs per MikroTik. Revoke compromised keys immediately by reissuing the CRL.
• Restrict the VPS firewall to known administrator source IPs where possible.
• Use HTTPS and authentication on every forwarded service. Plain HTTP through DNAT is an unnecessary attack surface.
• Run OpenVPN on a non-standard UDP port and rate-limit connections to slow internet-wide brute force.

Take the next step

A VPS-plus-OpenVPN tunnel works reliably and gives you full control. The trade-off is operational: every new MikroTik needs a fresh client cert, every key rotation needs coordination, every site that gets reset loses its tunnel until you re-onboard it manually. At one site this is manageable; at fifty, it consumes hours every week.

MKController’s NATCloud removes the manual tunnel plumbing. Each MikroTik comes online over an outbound tunnel to the control plane with no per-device cert babysitting and no VPS to maintain. You get centralized monitoring, secure remote access, and onboarding measured in minutes rather than hours. For the manual WireGuard variant of the same pattern, see our WireGuard remote management guide; for SSTP as a TLS-over-TCP alternative when UDP is blocked, see SSTP remote management.

Start your free MKController trial