SSTP Remote MikroTik Management

Summary SSTP (Secure Socket Tunneling Protocol) wraps PPP inside a TLS session on TCP port 443, making the tunnel look indistinguishable from normal HTTPS to firewalls, proxies, and CGNAT layers in between. RouterOS ships a complete SSTP server and client. This guide walks the minimum five-command server setup, the matching client config on a remote MikroTik, NAT for reaching LAN hosts across the tunnel, and the security checklist that keeps the deployment safe over time.

How does SSTP work for MikroTik remote management?

SSTP tunnels PPP inside a TLS/HTTPS session on TCP port 443. From the network’s perspective the traffic is indistinguishable from any other HTTPS connection — which is exactly why SSTP passes through corporate proxies, captive portals, hotel Wi-Fi, and CGNAT layers that block UDP-based VPNs like WireGuard or OpenVPN-UDP. The session flow is straightforward: client opens TLS to the server on 443, server presents its TLS certificate, a PPP session is established inside the TLS tunnel, and traffic flows encrypted end-to-end with whatever cipher RouterOS negotiates (typically AES-256-CBC/SHA1 on modern versions).

For MikroTik fleets specifically, SSTP is the right choice when the customer site sits behind something that blocks every other VPN. The trade-off versus WireGuard is throughput (TLS overhead is real on small CPUs) and versus OpenVPN is ecosystem (SSTP shines on Windows clients but has narrower third-party support). For broader remote-management context, see our WireGuard remote management guide and the VPS-based management guide.

Advantages and limitations

Strengths: works through restrictive firewalls and proxies; uses port 443, almost universally open; strong TLS encryption on modern RouterOS; native support on Windows; flexible authentication (username/password, certificates, or RADIUS).

Limitations: higher CPU than lightweight VPNs because of TLS overhead; throughput typically lower than WireGuard on the same hardware; needs a valid SSL certificate for reliable client behavior (browsers and Windows clients warn on self-signed). Older TLS versions are insecure — keep RouterOS updated and disable legacy SSL/TLS.

Step 1: Create or import the TLS certificate

Use Let’s Encrypt or a commercial CA for production. Self-signed works for lab testing but causes client warnings. The minimum to create a self-signed cert for testing:

/certificate add name=srv-cert common-name=vpn.yourdomain.com key-usage=key-cert-sign,crl-sign
/certificate sign srv-cert ca-cert=srv-cert
/certificate set srv-cert trusted=yes

The common-name should match the hostname clients will use to connect.

Step 2: Create a PPP profile

The profile defines the server-side and client-side IPs the tunnel will use:

/ppp profile add name=srv-profile local-address=10.10.10.1 remote-address=10.10.10.2

Step 3: Add a PPP secret

The secret is the per-user credential. Use long passwords or migrate to certificate authentication for fleets larger than a handful of users:

/ppp secret add name="usuario" password="senha123" profile=srv-profile service=sstp

Step 4: Enable the SSTP server

/interface sstp-server server set enabled=yes \
    certificate=srv-cert authentication=mschap2 default-profile=srv-profile

The router now listens on port 443 and accepts SSTP connections.

Step 5: Configure the SSTP client on the remote MikroTik

On the remote device:

/interface sstp-client add name=sstp-to-hq connect-to=vpn.yourdomain.com \
    user="usuario" password="senha123" profile=default-encryption add-default-route=no

/interface sstp-client print

Expected status:

status: connected
uptime: 00:02:15
encoding: AES256-CBC/SHA1

The encoding line shows the negotiated cipher. Modern RouterOS versions support stronger ciphers — verify your release’s defaults.

Reach an internal host across the tunnel

To reach a device behind the remote MikroTik (e.g., 192.168.88.100), use dst-nat:

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

Access the device via the SSTP tunnel endpoint plus the mapped port:

https://vpn.yourdomain.com:8081

Traffic flows through the HTTPS-style tunnel and reaches the internal host.

Security best practices

• Use valid, trusted TLS certificates from Let’s Encrypt or a commercial CA.
• Prefer certificate or RADIUS authentication over shared passwords for fleets.
• Restrict allowed source IPs at the firewall layer when possible.
• Keep RouterOS updated for modern TLS stacks and cipher support.
• Disable old SSL/TLS versions and weak ciphers.
• Monitor connection logs and rotate credentials periodically.

For broader management-plane security context, see our Winbox security best practices and device-mode security guide.

Alternative: SSTP server on a VPS

Host the SSTP hub on a VPS instead of a MikroTik when you want stable cloud-side aggregation. Windows Server has native SSTP support; SoftEther VPN on Linux is multi-protocol and supports SSTP plus several others — it works well as a protocol bridge so MikroTiks and Windows clients can land on the same hub without public IPs at every site.

SSTP vs. other VPN options

When to choose SSTP

Choose SSTP when the VPN must traverse corporate proxies or strict NAT, when Windows client integration matters, or when port 443 is the only outbound port reliably open. If raw speed and minimal CPU usage matter more than firewall traversal, WireGuard is the better default — see our WireGuard tutorial.

Take the next step

SSTP is the right pragmatic choice for hard-to-reach networks — it leverages HTTPS to stay connected where other VPNs fail, and a few RouterOS commands set up reliable remote access for branches, servers, and field devices.

If configuring certificates and per-device tunnels feels like busywork at fleet scale, MKController’s NATCloud offers centralized remote access and monitoring without per-device PKI management.

Start your free MKController trial