DEV Community

Ivan Osipenkov
Ivan Osipenkov

Posted on

WireGuard + MikroTik + RDP

#mikrotik #routeros #wireguard

WireGuard + MikroTik + RDP

A Practical Guide to Building a Modern VPN Infrastructure Without Losing Your Mind

Introduction

Modern networks stopped being truly local a long time ago.

Years ago, everything was simpler. The accountant worked in the office. The server lived in a small rack somewhere down the hall. Cameras were watched only by security staff. System administrators still believed they would eventually clean up the server room.

Now infrastructure is scattered everywhere.

Employees work from home. Someone connects from a phone. Someone logs in from another country. Management wants access to CRM systems from airports and hotels. Teachers connect to internal resources from coffee shops. Cameras need to stay online twenty-four hours a day. And ideally none of this should be exposed directly to the internet.

This is the point where VPN stops being an optional feature.

It becomes part of the foundation of a healthy infrastructure.

A good VPN is not just about security. It is also about predictability, segmentation, remote administration, centralized access, and the ability to make geographically distributed systems behave like a single local network.

And perhaps most importantly, it dramatically reduces the number of terrifying ideas like exposing RDP directly to the internet.

This guide is not about an ideal laboratory environment.

It is about real MikroTik and WireGuard deployments. With routing problems, broken firewall rules, MTU issues, NAT confusion, Windows firewall surprises, FastTrack problems, and all the strange situations that appear the moment theory collides with production networks.

The goal here is simple: build a WireGuard infrastructure that actually works and understand why it works.

What We Are Building

The final setup will look roughly like this:

Laptop / Smartphone
        │
        │ WireGuard
        │
Internet
        │
Public MikroTik IP
195.175.x.x
        │
        ├── VLAN Office     192.168.2.0/24
        ├── VLAN Cameras    192.168.1.0/24
        ├── VLAN Voice      192.168.20.0/24
        └── WireGuard       10.10.10.0/24
Enter fullscreen mode Exit fullscreen mode

At the end we will have:

  • secure RDP access;
  • access to internal VLANs;
  • internet routing through VPN;
  • separate peers for users and devices;
  • remote access from phones and laptops;
  • and a network that behaves predictably instead of emotionally.

Why WireGuard Instead of OpenVPN

WireGuard became popular not because it performs magic, but because it removes an enormous amount of unnecessary complexity.

It is easier to configure, faster under load, simpler to troubleshoot, and generally behaves in a much more predictable way.

OpenVPN is powerful, but it often feels like maintaining a legacy enterprise system from another era. Certificates, PKI infrastructure, endless configuration files, compatibility quirks, and debugging sessions that sometimes resemble archaeology.

WireGuard takes a very different approach.

There is an interface.
There are keys.
There are peers.
There are routes.

That is essentially it.

And surprisingly, that minimalism works extremely well.

A Few Words About Encryption and Keys

For beginners, terms like encryption and cryptographic keys can sound intimidating.

Fortunately, WireGuard simplifies most of this.

Unlike OpenVPN, there is no traditional certificate infrastructure with certificate authorities, certificate chains, and dozens of generated files.

WireGuard works with key pairs.

Each device receives:

  • a private key;
  • a public key.

The private key always stays on the device.
The public key is shared with peers.

This allows devices to authenticate each other and establish an encrypted tunnel through the internet.

From the outside, WireGuard traffic looks like normal UDP traffic. Inside that traffic is a fully encrypted private network.

RouterOS 7 and the Modern VLAN Approach

One important thing changed significantly in modern MikroTik environments.

RouterOS 7 is built around VLANs, not physical ports.

Older MikroTik setups were often designed like this:

ether1 = internet
ether2 = office
ether3 = cameras
Enter fullscreen mode Exit fullscreen mode

Modern designs usually look more like this:

bridge -> VLAN -> services
Enter fullscreen mode Exit fullscreen mode

IP addressing, DHCP, routing, firewall rules, and segmentation are now attached primarily to VLAN interfaces.

Physical ports became transport layers.

This is one reason WireGuard integrates so naturally into RouterOS.

From MikroTik's perspective, WireGuard is simply another network interface.

That means:

  • firewall rules apply to it;
  • NAT applies to it;
  • routing applies to it;
  • packet inspection tools work with it.

Understanding this makes troubleshooting dramatically easier later.

Step 1. Creating the WireGuard Interface 

/interface wireguard
add name=wg0 listen-port=51820 mtu=1420
Enter fullscreen mode Exit fullscreen mode

Using the terminal is strongly recommended. WinBox is convenient, but the terminal helps you understand RouterOS logic much more clearly.

WireGuard in MikroTik behaves like a regular network interface.

The only difference is that instead of a physical cable, it uses:

  • UDP;
  • encryption;
  • internet connectivity;
  • routing.

Why MTU = 1420

MTU means Maximum Transmission Unit.

In simple terms, it defines the maximum packet size that can travel through the network without fragmentation.

If you leave the default Ethernet MTU of 1500, WireGuard adds additional headers and packets can become oversized.

This usually leads to extremely confusing symptoms:

  • some websites open while others fail;
  • Telegram works but YouTube struggles;
  • RDP freezes randomly;
  • speed becomes inconsistent;
  • VPN feels unstable.

1420 is generally a safe and practical value for WireGuard.

In mobile networks or CGNAT environments, lowering MTU even further to 1380 or 1360 sometimes improves stability.

A slightly less efficient VPN is still much better than a theoretically faster VPN that behaves unpredictably.

Step 2. Assigning an IP Address 

/ip address
add address=10.10.10.1/24 interface=wg0
Enter fullscreen mode Exit fullscreen mode

This becomes the MikroTik address inside the VPN network.

One of the most common mistakes is forgetting to assign an IP address to wg0.

When that happens, WireGuard may still show a successful handshake, but the tunnel is effectively unusable.

Handshake exists.
Ping does not.

This is a classic beginner trap.

Step 3. Creating a Peer 

/interface wireguard peers
add interface=wg0 public-key="CLIENT_PUBLIC_KEY" allowed-address=10.10.10.2/32 comment="Ivan Phone"
Enter fullscreen mode Exit fullscreen mode

The most important parameter here is:

allowed-address
Enter fullscreen mode Exit fullscreen mode

And despite what many beginners assume, this is not a firewall rule.

It defines which IP addresses MikroTik expects from that peer.

If the client uses:

10.10.10.2
Enter fullscreen mode Exit fullscreen mode

then the allowed address should be:

10.10.10.2/32
Enter fullscreen mode Exit fullscreen mode

Not /24.
Not /16.
Not “it kind of works”.

Otherwise routing conflicts and bizarre behavior start appearing very quickly.

Step 4. Configuring the Client

This is where many mysterious problems begin.

WireGuard says Connected.
Handshake exists.
Some websites open.
Others fail.
The external IP does not change.
Internet suddenly bypasses the tunnel.

Most of the time the problem comes down to one line:

AllowedIPs
Enter fullscreen mode Exit fullscreen mode

This parameter defines which traffic goes through the VPN.

If you use:

AllowedIPs = 0.0.0.0/0
Enter fullscreen mode Exit fullscreen mode

all internet traffic goes through the tunnel.

If you use:

AllowedIPs = 10.10.10.0/24, 192.168.2.0/24
Enter fullscreen mode Exit fullscreen mode

only internal networks go through the VPN.

This is called split tunneling.

It is not a bug.
It is routing behavior.

Example client configuration:

[Interface]
PrivateKey = CLIENT_PRIVATE_KEY
Address = 10.10.10.2/32
DNS = 8.8.8.8

[Peer]
PublicKey = SERVER_PUBLIC_KEY
Endpoint = 195.175.59.162:51820
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 25
Enter fullscreen mode Exit fullscreen mode

Step 5. Firewall: INPUT vs FORWARD

This is one of the most important concepts in RouterOS.

Beginners often configure FORWARD rules but forget INPUT entirely.

INPUT is traffic going to the router itself.

Examples:

  • pinging MikroTik;
  • WinBox access;
  • SSH;
  • WireGuard endpoint traffic.

FORWARD is traffic passing through the router somewhere else.

Examples:

  • VPN client accessing RDP;
  • traffic between VLANs;
  • internet access through MikroTik.

This leads to a classic scenario:

WireGuard connects.
Handshake works.
But pinging the router itself fails.

Why?

Because FORWARD was configured but INPUT was forgotten.

Allow WireGuard access to the router:

/ip firewall filter
add chain=input action=accept src-address=10.10.10.0/24 comment="ALLOW WG INPUT"
Enter fullscreen mode Exit fullscreen mode

Allow VPN access to internal VLANs:

/ip firewall filter
add chain=forward action=accept src-address=10.10.10.0/24 dst-address=192.168.2.0/24
Enter fullscreen mode Exit fullscreen mode

And allow return traffic:

add chain=forward action=accept src-address=192.168.2.0/24 dst-address=10.10.10.0/24
Enter fullscreen mode Exit fullscreen mode

Yes, established/related rules are often enough.

But for beginners, explicit rules are easier to understand and troubleshoot.

Step 6. Internet Access Through VPN and NAT

This is usually where administrators meet NAT in a very personal way.

Everything seems fine:

  • VPN connects;
  • internal addresses respond;
  • RDP works.

Then someone opens a browser.

Nothing loads.

The reason is simple.

When VPN clients access the internet through MikroTik, the provider sees something like this:

Source: 10.10.10.2
Enter fullscreen mode Exit fullscreen mode

And has absolutely no idea where that network exists.

That is why masquerade is required.

/ip firewall nat
add chain=srcnat action=masquerade src-address=10.10.10.0/24 out-interface=Wan comment="NAT WG to Internet"
Enter fullscreen mode Exit fullscreen mode

This replaces the internal VPN address with the router's public IP address.

From the internet's perspective, the VPN client now appears to be physically located behind the MikroTik router.

FastTrack: Wonderful and Terrifying

FastTrack dramatically improves MikroTik performance.

It also causes some of the strangest networking problems administrators will ever encounter.

For ordinary internet traffic FastTrack is excellent.

For VPN tunnels, VLANs, NAT, and complex routing, it sometimes behaves like chaos acceleration.

If you encounter symptoms such as:

  • unstable RDP;
  • websites loading inconsistently;
  • some services working while others fail;
  • disappearing traffic,

check FastTrack.

Very often it turns out to be the culprit.

Typical WireGuard bypass rules:

/ip firewall filter
add chain=forward action=accept src-address=10.10.10.0/24
add chain=forward action=accept dst-address=10.10.10.0/24
Enter fullscreen mode Exit fullscreen mode

These rules should be placed above FastTrack.

Troubleshooting Without Superstition

The funny thing about network diagnostics is that symptoms lie constantly.

When users say:

“VPN is broken”

that could mean almost anything:

  • DNS problems;
  • missing NAT;
  • routing issues;
  • Windows firewall problems;
  • blocked UDP traffic;
  • MTU fragmentation.

Good troubleshooting is not intuition.

It is systematic elimination.

Handshake Exists but Ping Fails

Check:

/interface wireguard peers print detail
Enter fullscreen mode Exit fullscreen mode

If you see:

last-handshake
rx/tx
Enter fullscreen mode Exit fullscreen mode

then the tunnel itself is alive.

If 10.10.10.1 still does not respond, the issue is usually INPUT firewall rules.

Internet Does Not Work

Test:

ping 8.8.8.8
Enter fullscreen mode Exit fullscreen mode

If that works, routing and NAT are functioning.

Then test DNS:

nslookup google.com
Enter fullscreen mode Exit fullscreen mode

External IP Does Not Change

Usually caused by split tunneling:

AllowedIPs != 0.0.0.0/0
Enter fullscreen mode Exit fullscreen mode

RDP Fails

Very often the issue is not WireGuard at all.

It is Windows Firewall.

Windows frequently switches networks to Public mode and silently blocks RDP.

Check:

Get-NetConnectionProfile
Enter fullscreen mode Exit fullscreen mode

Fix:

Set-NetConnectionProfile -NetworkCategory Private
Enter fullscreen mode Exit fullscreen mode

Why You Should Never Expose RDP to the Internet

Because the internet is not a friendly environment.

Port 3389 is scanned continuously.
Password brute-force attacks never stop.
Security logs quickly become modern art.

Even with strong passwords and non-standard ports, VPN remains the safer solution.

WireGuard allows RDP to disappear completely from the public internet and remain accessible only through an encrypted tunnel.

This is the modern standard.

One Peer Per User

Do not create a single shared configuration for everyone.

Ever.

A proper design looks like this:

user1 -> 10.10.10.2
user2 -> 10.10.10.3
user3 -> 10.10.10.4
Enter fullscreen mode Exit fullscreen mode

This allows you to:

  • revoke individual access;
  • track activity;
  • simplify auditing;
  • avoid routing conflicts;
  • maintain sane infrastructure.

Separate peers for separate devices is also considered good practice.

Real-World Corporate Scenarios

WireGuard quickly stops being “just a VPN for RDP”.

It becomes the transport layer for distributed infrastructure.

Organizations use it for:

  • branch office connectivity;
  • remote employees;
  • NAS access;
  • virtualization platforms;
  • VoIP systems;
  • video surveillance;
  • backup infrastructure;
  • remote administration;
  • geographically distributed networks.

Site-to-Site VPN between offices is one of the strongest WireGuard use cases.

To end users everything behaves like one local network, even if offices are located in different countries.

WireGuard is also frequently used for:

  • bypassing regional restrictions;
  • secure internet access from other countries;
  • safe usage of public Wi-Fi;
  • secure remote access to internal resources.

At the same time, it is important to understand:

WireGuard is not magical anonymity.

It is secure routing.

Final Thoughts

A functional WireGuard deployment on MikroTik is surprisingly simple.

You need:

  • an interface;
  • an IP address;
  • peers;
  • firewall rules;
  • NAT;
  • routing.

Most problems are not caused by WireGuard itself.

They are caused by the surrounding network logic:

  • firewall rules;
  • routing;
  • FastTrack;
  • DNS;
  • NAT.

Once you begin understanding those systems, MikroTik stops looking chaotic.

And WireGuard stops being just another VPN.

It becomes part of a modern distributed infrastructure.

And after using a properly configured WireGuard setup, going back to exposing RDP directly to the internet feels like voluntarily sleeping next to a fire alarm.

Top comments (0)