WireGuard Remote Access on MikroTik: A Safer Basic Pattern

Build a simple WireGuard remote-management tunnel using explicit subnets, peer keys, allowed addresses, firewall rules, and validation steps.

Category: VPNUpdated: September 17, 2026Reading time: 6 min
Before production changes: back up your configuration, verify interface names and IP ranges, and use a maintenance window for remote or customer-facing systems.

WireGuard is a compact VPN protocol that works well for secure remote administration and site-to-site connectivity. A clean deployment uses a dedicated tunnel subnet, unique keys per peer, narrow allowed-address rules, and firewall rules that expose only the management services you actually need.

Video walkthrough

Choose a tunnel subnet

Use a small private subnet that does not overlap the LAN, subscriber pools, or other VPNs. For example, 10.77.0.0/24 can be used for the tunnel if it is unused elsewhere.

Create the WireGuard interface

Create the interface and assign the router a tunnel address. The router will generate a private/public key pair.

/interface wireguard add name=wg-remote listen-port=51820
/ip address add address=10.77.0.1/24 interface=wg-remote

Keep the private key private. Share only the public key with peers.

Add a peer with narrow allowed addresses

Give each remote peer its own tunnel address and key. On the MikroTik side, the peer's allowed address should normally be that peer's tunnel IP, such as 10.77.0.2/32, unless the peer routes additional subnets.

/interface wireguard peers add interface=wg-remote public-key="PEER_PUBLIC_KEY" allowed-address=10.77.0.2/32

Firewall the tunnel deliberately

Permit the WireGuard UDP port on the internet-facing firewall only where required, then control what the VPN subnet can access. Do not expose Winbox, SSH, API, or web administration directly to the public internet just because WireGuard exists.

Endpoint and keepalive

A peer behind NAT may need a persistent keepalive so the NAT mapping remains available. A common value is 25 seconds. If the router itself is behind CGNAT, direct inbound WireGuard may not be possible without a public endpoint, relay, VPS, or another reachable peer.

Validation

Use /interface wireguard peers print detail to confirm the latest handshake and transfer counters. Ping the remote tunnel IP first, then test only the management service you intend to use. A successful handshake does not automatically prove that firewall and routing are correct.

Frequently asked questions

Does WireGuard need TCP port forwarding?

No. WireGuard uses UDP.

Can I use it behind CGNAT?

Outbound tunnels work, but accepting unsolicited inbound traffic usually requires a publicly reachable endpoint or relay design.

Should every technician share one private key?

No. Use separate peer keys so access can be revoked individually.

Next step

Document the result of your test and keep a known-good export. If your network behaves differently from the example, diagnose the topology rather than adding more rules blindly. Continue with a related guide from the tutorial library.