GUIDE / REMOTE ACCESS

Remote access.

You need to reach your router from somewhere that isn't its LAN. The obvious move is to port-forward Winbox or expose SSH on a public IP. Don't. RouterOS management services have a history of CVEs, and a public-facing management port is in the first sweep of every botnet that scans port 8291 or 22. This page walks the safer paths.

The right answer, in order of preference

  1. WireGuard VPN to your router (v7 only). Lowest setup cost, smallest attack surface, ships built in.
  2. IPsec site-to-site when you're connecting an office network and want a permanent tunnel.
  3. L2TP/IPsec when WireGuard isn't available (RouterOS v6 routers, or clients without WireGuard support). Older but reliable.
  4. SSH on a non-standard port, key-only auth, source-restricted — when a VPN is genuinely impractical (e.g. you need to script from a cloud CI box that won't carry a VPN). Defence-in-depth required; see Winbox / SSH hardening.
  5. Never: Winbox on a public port. Webfig on a public port. /ip service api exposed. The CVE list is long enough that any of these is a "when", not "if", problem.

Before any of this works

Remote access requires a way for the outside world to reach something on your router. Three common shapes:

  • Public IPv4 on the WAN — your ISP gives you a routable IPv4 address (not RFC1918, not CGN). Check with /ip address print; if WAN address is 100.64.0.0/10 you're behind CGN and need a different shape.
  • IPv6 — most ISPs delegate a /56 or /60. Your router gets a routable IPv6 address automatically. Works for VPN endpoints but client OSes need IPv6 connectivity at the other end.
  • An overlay you control — Tailscale, Cloudflare Tunnel, a relay VM. None of these need ISP cooperation and they neatly avoid the "what's my WAN IP today" problem on dynamic-IP connections. The VPN endpoint becomes the overlay's address, not your ISP's IP.

Dynamic-IP / DDNS

If your WAN IP changes daily, you have two viable options:

  • MikroTik IP cloud DDNS — built in. /ip cloud set ddns-enabled=yes gives you a <serial>.sn.mynetname.net hostname that tracks the router's WAN address. Free, no third-party account.
  • Third-party DDNS (DuckDNS, no-ip, dynu) via a scheduled script that POSTs the current IP. More work, but lets you pick a hostname.
v6 3 lines · 101 bytes 
/ip cloud set ddns-enabled=yes update-time=yes
/ip cloud print
# the hostname is the "dns-name" field
v7 3 lines · 101 bytes 
/ip/cloud set ddns-enabled=yes update-time=yes
/ip/cloud print
# the hostname is the "dns-name" field

Behind carrier-grade NAT (CGN)

A surprising number of residential and mobile connections sit behind CGN — your router's "WAN" IP is in the 100.64.0.0/10 range and the real internet-routable IP belongs to your ISP's NAT box. Port-forwards don't work; you can't open ports on a NAT you don't control. Options:

  • Ask the ISP for a public IPv4 (some offer it as a paid upgrade).
  • Use IPv6 if the ISP delegates it — IPv6 doesn't traverse CGN.
  • Use an overlay (Tailscale, ZeroTier, Cloudflare Tunnel) so the "where are you reachable" question moves to a third party.
  • Run a small VM with a public IP and use it as a VPN concentrator — your router dials out to it permanently, you VPN to the VM.

Once you're inside the VPN

From a connected VPN client you can use Winbox, Webfig, or SSH normally — the router treats VPN-side addresses as LAN-equivalent. Two things to set up first:

  • Restrict management services to the VPN subnet. /ip service set winbox address=10.10.10.0/24 (where 10.10.10.0/24 is your VPN subnet). Anything outside that range gets refused without a response. See IP services.
  • Firewall rule to accept management traffic from the VPN subnet — input chain, accept TCP/SSH+Winbox+Webfig from the VPN range, before the default-drop. See input chain.

What never goes public

For the avoidance of doubt, the management surface that should never be reachable from the open internet:

  • Winbox (port 8291).
  • SSH (port 22), unless source-restricted to specific known IPs.
  • Webfig over HTTPS (port 443) — and definitely not HTTP (port 80).
  • /ip service api (port 8728) or api-ssl (8729).
  • SNMP (port 161) — read-only or otherwise.
  • Bandwidth Test Server (port 2000).

Everything in that list goes behind the VPN. Yes, even SSH with keys. The cost of a CVE in any one of them is a re-flashed router; the cost of a VPN is one extra hop.