MikroTik WireGuard: native or container VPN

A MikroTik can be a VPN client two ways: RouterOS 7's built-in WireGuard interface, or a container, which is how ForestVPN's router client ships. We ran both on one RouterOS 7.24.1 Cloud Hosted Router (CHR), a virtual router, and add CPU numbers from real boards, including the round we lost.

Can a MikroTik router run WireGuard as a VPN client?

Yes: RouterOS 7 has a WireGuard interface, and a peer on it makes the router a client of any server you hold a configuration for. MikroTik's WireGuard page lists the interface's properties, lists 13231 as the listen-port default and 1420 as the MTU, and shows import and export of configurations. A third-party guide, MikroTik Masters, published on 2025-01-30, states RouterOS 7.1 or later as its requirement.

That native interface speaks the protocol and nothing else. It does not register you anywhere, pick a server or build a firewall.

You bring a configuration and write the rest yourself:

• the router's own private key, the peer's public key and an endpoint
• the addresses, routes and NAT

In a .conf file the peer's permitted addresses are called AllowedIPs. RouterOS calls the same setting allowed-address, and this article uses both names.

The second route is a container. RouterOS can run Linux container images once the RouterOS container package is installed, and our client, the image suquant/fvpn (at the pinned tag on our download page), runs that way.

It talks to RouterOS over a veth, a virtual Ethernet link between the router and the container, registers the router as its own device, holds its own keys and prints a pairing code.

Its sibling image suquant/fvpnq is raw tunnelling from a config file and is what an exit node runs. It is not the client and not what this article means.

We do not hand out a WireGuard .conf file for the native route, so you need a server you already hold a configuration for.

Which RouterOS version do you need for WireGuard and for containers?

Both routes need RouterOS 7, and the container route adds a package and a higher floor.

Native route

The only floor we can cite is MikroTik Masters' RouterOS 7.1 or later, from a post dated 2025-01-30. Read MikroTik's own page for the release you run, because that guide is older than this one.

Container route

MikroTik's container page says the package is compatible with arm, arm64 and x86 architectures. It adds that remote-image pulls need a lot of free space in main memory.

Our client then asks for two things, according to our MikroTik download page:

• RouterOS 7.21 or later, with the container package. Older versions reject the install block.
• Device-mode, a RouterOS switch that keeps risky features off until someone with physical access turns them on, set to allow containers.

What is verified

MikroTik router setup records one hardware verification: a cAP ax (arm64, RouterOS 7.24.1) that registered, printed a pairing code, verified the signed server list and connected. That is the entire verified claim, and we will not stretch it. The choose-traffic and kill-switch recipes are separate pages with their own notes.

Some boards need a variant. The flash folder recipe describes 16 MB boards, such as the hAP ac², that keep only their flash folder across a reboot; our download page says "The install block handles it", and the recipe does so by pulling the image again at every boot. The recipe's own note reads: "Not yet verified on hardware."

What do RouterOS's WireGuard interface and a container client each need?

The native route needs nothing beyond RouterOS 7 and a config; the container route needs a package, a device-mode change and some RouterOS rules of your own before the LAN uses it. Here are the two side by side, with the sources named in the cells.

Those two speeds are not one test run twice. The throughput post explains why the two arms needed different traffic generators, and the section on CPU below carries the caveats.

How do you set up the native WireGuard interface on RouterOS 7?

You create the interface, give it an address and add one peer; the route to the tunnel's subnet comes from the address you gave the interface. That is three commands, in that order, plus a firewall rule on a listening side that filters its input. Below is what we ran on the lab's client router, followed by its own printout.

/interface/wireguard/add name=wg-lab
/ip/address/add address=10.99.0.2/24 interface=wg-lab
/interface/wireguard/peers/add interface=wg-lab \
    public-key="<peer public key>" \
    endpoint-address=192.0.2.2 endpoint-port=51820 \
    allowed-address=10.99.0.0/24 persistent-keepalive=5s comment=lab-peer

After the peer was in, the router showed this. Note the handshake counter and the connected route (flag DAc) that appeared for the tunnel's subnet:

> /interface/wireguard/print
0 R name="wg-lab" mtu=1420 listen-port=56422

> /interface/wireguard/peers/print detail
0  ;;; lab-peer
   interface=wg-lab name="peer1"
   endpoint-address=192.0.2.2 endpoint-port=51820
   allowed-address=10.99.0.0/24 persistent-keepalive=5s
   rx=92 tx=212 last-handshake=9s

> /ip/route/print
DAc 10.99.0.0/24  wg-lab   main

> /ping 10.99.0.1 count=5
    sent=5 received=5 packet-loss=0% min-rtt=2ms1us avg-rtt=3ms397us

The five pings crossed the tunnel with no loss. The R flag means the interface is running. The handshake is the proof that matters: a non-empty last-handshake means the peer answered, whatever a ping says later.

Routes and ports

That DAc route is the connected route RouterOS creates from the interface address, 10.99.0.2/24. It does not come from the peer or its allowed-address: RouterOS creates no routes from that field, which is why the next section has to add a default route by hand. A peer subnet outside the interface's own subnet needs its own /ip/route entry.

MikroTik's table says 13231 is the default listen port. Our 7.24.1 interface, created without a listen-port, came up on 56422. Set listen-port explicitly whenever a firewall rule or a peer's configuration depends on it.

On the peer side

• On a router whose input chain drops unsolicited traffic, the listening side needs an accept rule for UDP on its listen port, placed above the drop. MikroTik's page adds the same kind of rule. Our peer had no such drop rule, so this run did not show it being needed.
• Set persistent-keepalive on a router that sits behind NAT, so the mapping does not expire when the link is quiet.

What the guides stop at

Proton's MikroTik page continues past the peer with four steps:

1. A masquerade rule on the interface.
2. Two routes that split the address space in half (0.0.0.0/1 and 128.0.0.0/1).
3. A DNS server change.
4. A host route for the endpoint through the normal gateway.

Those steps turn "the ping works" into "the LAN uses it". We did not run Proton's service, and this describes what its page says, nothing about how it performs.

What does AllowedIPs 0.0.0.0/0 do to the router's own traffic?

It lets every destination through the peer, and once you point a default route at the interface the router's own traffic goes with the rest. Here "the router's own traffic" means RouterOS's own pings, DNS lookups and update checks, which leave by whatever route says so. On the native route the router is no bystander.

We tested it on the same virtual router. It had no other default route before the change, so the run shows where the router's traffic goes once the tunnel holds the default, not a contest with an existing WAN default route.

Before the change the router had no route to the lab host and three pings failed with "no route". Then we widened the peer's allowed address to 0.0.0.0/0 and added a default route through the interface:

/interface/wireguard/peers/set [find comment=lab-peer] \
    allowed-address=0.0.0.0/0
/ip/route/add dst-address=0.0.0.0/0 gateway=wg-lab comment=default-via-tunnel

> /ping 198.51.100.1 count=5
    sent=5 received=5 packet-loss=0%

> /ip/firewall/filter/print stats where comment~"count"
;;; count: labhost icmp arrived on WAN link
0 input  passthrough      0        0
;;; count: labhost icmp arrived through tunnel
1 input  passthrough    280        5

On the peer, a counter on the WAN link read 0 packets and a counter on the tunnel read 5. All five pings went into the tunnel.

That is why a copy-pasted "send everything" recipe can cut a router off from its own management traffic: if the peer cannot answer, nothing the router sends beyond its directly connected networks gets out. Our post on a VPN that connects but carries nothing goes through the symptoms that follow.

How do you run the container client on RouterOS?

You enable container mode once, with physical access, then give the container a veth interface, a mount for its state and a pinned image. MikroTik documents the first step as /system/device-mode/update container=yes, confirmed by a reset-button press, or by a cold reboot on x86.

Physical access is the point. The same MikroTik page warns that once the container feature is enabled, containers can be added, started and removed remotely, and that a router is as secure as anything you run in a container. Enabling it is a decision. Do not treat it as a formality.

On our virtual router the confirmation was different, because it has no button. The update printed a countdown, "turn off power in 5m to activate changes", and the change applied after a power-off. The device-mode printout then read container: yes. On hardware, expect the reset button the documentation names.

Container objects

The setup follows the pasted block on our download page, and our lab used these objects (state and root on the attached disk, for a reason given below):

/interface/veth/add name=veth-fvpn address=172.31.254.2/30 \
    gateway=172.31.254.1
/ip/address/add address=172.31.254.1/30 interface=veth-fvpn
/container/mounts/add list=fvpn-state src=disk1/forestvpn \
    dst=/etc/forestvpn mode=rw
/container/add remote-image=suquant/fvpn:0.3.17 interface=veth-fvpn \
    root-dir=disk1/fvpn mountlists=fvpn-state logging=yes start-on-boot=yes \
    privileged=yes name=fvpn

That block is shortened to the objects that matter. The real one on the download page also carries the entrypoint and the arguments, so paste that one, not ours.

Our first pull failed with "check registry failed: resolving error" because the router had no DNS server yet. After we gave it one the pull downloaded three layers and the container started.

What the log showed

In order, the log showed:

1. A new machine key written.
2. The interface fvpn0 started.
3. The status page started.
4. The signed server list verified.
5. A new device registered and a pairing code printed.

That is a virtual router, not the hardware verification, which remains the cAP ax on the install page. The log also explains why the native commands above do not apply here: you never type a private key, a peer or an endpoint. The client makes its own key and fetches its exit.

Disk choice

MikroTik's page recommends container volumes on an attached disk. Our download page answers "Do I need a disk?" with no for the plain container install, and its block puts root and state on built-in storage. The lab used disk1 only because the virtual router's built-in space was nearly full.

LAN traffic

Out of the box only the container's own traffic uses the tunnel. The install script says so itself: with its LAN option left off, the LAN keeps its normal connection. To send LAN devices through it you paste the routing script from the router's status page, which adds the mangle rules and the routing table, and the choose-traffic page explains its modes.

Does a WireGuard container use less CPU than RouterOS's own WireGuard?

On the one pair of hardware runs we hold, our core in a container used about half the CPU per megabit that RouterOS's own tunnel did, and it lost on latency. On two physical MikroTik routers on 2026-09-01, an RB3011UiAS as sender and a cAP ax as receiver, both on RouterOS 7.24.1, the throughput post records 122 Mbit/s for our core, run as fv in a RouterOS container started by hand, and 66.8 Mbit/s for RouterOS's kernel tunnel.

Show the data

Container core	122 Mbit/s
RouterOS kernel tunnel	66.8 Mbit/s

CPU per megabit and round-trip time tell the other half. Each figure is a single run, from the same post.

The kernel tunnel won on round-trip time. These limits matter more than the numbers:

• The two arms used different traffic generators, dd | nc for ours and bandwidth-test for the kernel tunnel, because no one generator ran on both.
• The figures belong to those two boards. We have not repeated them on other models, on OpenWrt, or on the virtual router, where software emulation would say nothing about a real board.
• If your router is a different board, measure for yourself.

Whether WireGuard is quicker than OpenVPN on a MikroTik is a question we cannot answer. We never timed OpenVPN there.

FastTrack can also skip the rules a tunnel needs; see how FastTrack interacts with a tunnel.

What does the MTU do to a MikroTik tunnel?

A wrong MTU looks like this: the handshake succeeds, small packets such as pings work, and large downloads stall. If the interface is running and pages hang, suspect that before a dead tunnel.

Tunnel headers eat into the packet, so the largest packet that fits inside it is smaller than the link underneath allows. The RouterOS WireGuard interface defaults to an MTU of 1420, per MikroTik's page, and our native run printed mtu=1420.

There are two fixes:

• Lower the interface MTU in steps and test again.
• Clamp the TCP maximum segment size on the router. The container's tunnel runs at an MTU of 1416, and the routing script on the choose-traffic page adds two mangle rules that set change-mss to 1336 for it.

That clamp ships with the container route's script, so on the native route you write your own. The connected-but-no-internet post has the longer version.

We never tried an MTU other than the default 1420, so we cannot suggest a better value for your link.

For the general rule and how to find a working value, see the WireGuard MTU guide.

Does a MikroTik kill switch work?

On the container route the kill switch is part of ForestVPN's routing script, in every mode. As the MikroTik kill switch help page lists it, the script adds a routing table whose default route is the container with a blackhole behind it, a routing rule that never lets a marked packet fall back to the main table, and forward drops. The page records a test on a cAP ax test LAN running RouterOS 7.24.5, and gives a stop-the-container leak test you can repeat.

It covers only the traffic you selected, and it is IPv4 only. The native route ships no kill switch at all; you would write the equivalent rules yourself. We did not exercise either in the lab run described here.

Should you use RouterOS's WireGuard interface or a container VPN client?

Choose the native interface if you already hold a WireGuard configuration for a server you run or rent and want to write every route yourself. Choose the container if you want a client that looks after its own keys and exit, and you accept the package, device-mode and RouterOS rules it asks for.

Whichever you pick, test with a stop. Bring the tunnel down on purpose and watch what the LAN does. A guide that ends at "ping works" never shows you that.

Where to go next:

• The container route's LAN steering is on the choose-traffic page.
• The MikroTik vs OpenWrt comparison sets this recipe against the OpenWrt one.
• For an OpenWrt router, the OpenWrt WireGuard post covers the manual route.

ForestVPN's tunnel in the container uses the unmodified Noise_IKpsk2 handshake the WireGuard project specifies. The WireGuard comparison page sets the protocols side by side.

Ask about this