Mikrotik as wireguard client

RouterOS General
1

I’m trying to set up a mikrotik as wireguard client, with no success. I have no experience with wireguard at all.

The config that is claimed to work on linux (I did not test it my self) is as follows:

[Interface]
PrivateKey = KF****GI=
Address = 10.2.0.2/32
DNS = 10.2.0.1

[Peer]
PublicKey = wq****o=
AllowedIPs = 0.0.0.0/0
Endpoint = 195.x.x.x:51820

How does this translate into mikrotik?

My attempt looks like this:

/interface/wireguard
add name=wg1 listen-port=51820 private-key="KF***GI="

/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=195.x.x.x endpoint-port=51820 interface=wg1 public-key="wq****o="

/ip address 
add address=10.2.0.2/32 interface=wg1

/ip route 
add dst-address=8.8.8.8/32 gateway=wg1

Well the wg1 interface has status running. But apart from that I see no signs of this working.

So I tried

/ip firewall mangle
add action=log chain=output dst-address=195.x.x.x log=yes log-prefix="WG: "

That rule has 0 matching packets when I ping 8.8.8.8 (from the router). So it looks like the router doesn’t even try to connect to the other endpoint.

Well, so what could be wrong? Routing? I tried

/ip route 
add dst-address=8.8.8.8/32 gateway=10.2.0.2

Route comes up as invalid, hence disabled.
Then I tried

/ip route 
add dst-address=8.8.8.8/32 gateway=10.2.0.1

I don’t know if 10.2.0.1 can act as a gateway, but it should work as a dns server, hence it should exist. Anyway, that route can’t do anything as long as the interface ip has a /32 subnet mask. So I changed that to /30.

Now, the ping returns status “22 (invalid argument)” rather that “time out” which was the status before this change. The mangle rule still has 0 matching packets.
Then I deleted the first route added (the one with “wg1” as gateway). And the ping status jumped back to “time out”. I tried to set preferred source to 10.2.0.2, but still ping times out, and 0 matching packets on the mangle rule.

Sure there could be that the ISP has blocked the connection. But I’d guess that even if that was the issue, the mangle rule should have had at least one matching packet. The problem must be something with my config. Where did I mess this up?

2

Hi,
I hope this helps you find a solution to your problem. Additionally, I posted a topic a long time ago you should take a look at that too.
http://forum.mikrotik.com/t/route-internet-traffic-mt-via-wireguard-tunnel-through-mt-wg-peer/154825/1
1.png
2.png
3.png
4.png
5.png
6.png
7.png

3

FIRST you should read this → https://forum.mikrotik.com/viewtopic.php?p=906311#p906311

Without looking at your config the following guidance is provided:
If the Wireguard is the client its very basic…
What is the endpoint port and endpoint public IP (could be actual IP or one defined by a dyndns name etc…)
Ensure you use keep alive setting lets say 35 seconds…
Ensure you correctly create an IP address for the wireguard interface that falls within a coordinated plan.
(AKA if the wireguard IP at the server LiNUX is 192.168.5.1/24 then use 192.168.5.2/24 for the Mikrotik.)

Ensure you correctly identify the ALLOWED IPs under peer settings. The allowed IPs should include.
a. 192.168.5.0/24 (to be able to ping the linux server or any other wireguard interfaces)
b. SUBNET(S) ( at the linux server )
c. SUBNET(S) ( at any other locations connected to the linux server, devices directly connnected to the linux server or accessible via other wireguard tunnels for example).

NOTE: If the intent is to solely access the internet via the LINUX server, or any combination of the above and internet you ONLY require
0.0.0.0/0 as the allowed IP as that covers everything.

In terms of FIREWALL RULES, ensure on the MT Device that the subnet or users needing access to the TUNNEL are permitted in the forward chain rules.
In terms of IP ROUTES, you will need manual routes to ensure users go through the wireguard to reach LInux or other SUBNETS… (table=main), and if you need to force local client users to use linux internet you will need manual routes with another table and route rules.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Looking at your config…

/interface/wireguard
add name=wg1 listen-port=51820 private-key=“KF***GI=”

/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=195.x.x.x endpoint-port=51820 interface=wg1 public-key=“wq****o=”
keep alive setting = 35 seconds

/ip address
add address=10.2.0.2/24 interface=wg1

IP ROUTE NEEDS WORK… How many subnets do you have on the mickrotik device and which ones need to use the linux for internet???

/ip route
add dst-address=0.0.0.0/0 gateway=ISPgatewayIP table=main { this is your normal rule on the mikrotik which needs to stay }
add dst-address=0.0.0.0/0 gateway=wg1 table=useWG { this is the route needed to force users identified by route rules to use wg for all traffic }

/routing table add name=useWG fib { create the necessary table }

/route rule add src-address=SUBNETA action=lookup table=useWG
/route rule add src-address=SUBNETB action=lookup table=useWG
/route rule add src-address=individualUSER_IP action=lookup table=useWG
…
as required.

Note1: Action Lookup means the router will use the new table for those identified BUT if the wg tunnel goes down USers/Subnets will then be moved to the next available route which will be the local one.
Note2: If you dont want any fallback, its either linux internet or Nothing, then use ACTION= LOOKUP-ONLY-IN-TABLE.

FIREWALL RULES - cannot make any assessment as not visible…

4

Even without any changes, with original posted config (maybe the goal is to use tunnel only for traffic to 8.8.8.8, there’s nothing wrong with that), it should show some signs of life, i.e. outgoing udp packets to 195.x.x.x:51820.

5

Thanks for the ideas on various routings over the tunnel, once the tunnel is established. The problem here however is that the mikrotik doesn’t even try to establish the tunnel. (In the final setup I will be using multiple routing tables as well.)

Routing 8.8.8.8 over the tunnel is my test towards an ip I know for sure will reply. Just for testing the tunnel

Setting presistent-keeepalive did not make any difference.

[admin@RB] > /interface/wireguard/peers/print proplist=rx,tx,last-handshake
Columns: RX, TX
# RX  TX
0  0   0

I’m not sure if these counters counts on the tunnel or the packets between endpoints. They are 0, and the mangle rule the for sure will count any packets heading towards the remote endpoint, no matter if they reach the destination, has also 0 packets.

I’m sure there is a basic setting somewhere that I’m missing. This is, by the way, my first RoS 7 configuration. I tested this router as client for both sstp and l2tp/ipsec, and they work, so my config is not totally off. What could be the missing setting for wireguard?

6

This is crazy!
Out of desperation I figured I should reset to default configuration, thinking maybe there were something new with RoS7 that I missed out when I was starting with blank config.
SO, I took backup using winbox backup button, and ran /export compact file=wg-failed.rsc
Then I reset config, restoring default.
Well. As this thing is using wlan as wan connection, I had to restore the wlan settings from the exported config. Then I realized that my export did not include the wireless keys. (The export command apparently has got ‘hide-sensitive’ as default since the days when I was configuring mikrotiks on a daily basis.) Well. I had to find the wireless key for my wan connection, and the fastest place to find that would be to restore the backup I just made and do a new export of config.
While I was there, why not try to ping over the wireguard tunnel… AND IT WORKED!

I’ve experienced strange things with MTs before, but this was probably the strangest.

What I learned: When wireguard doesn’t work - backup the config - reset to factory default - restore the backup you just made.

7

Already had to do that twice myself coming from ROS6 to 7.
Couldn’t reach remote lan, after clean reset it worked with the exact same config. Not a single thing changed except for default settings, which I did not touch.

I am still convinced there is something in the background carrying over wrongly from 6 to 7 which breaks stuff.

8

I did not include the config in the upgrade. I did the upgrade while default config was running. After the upgrade I did reset configuration and asked it to run a script “my_defaults.rsc” rather than factory defaults. That script failed to run, so I ended out doing another reset configuration to start all blank and manually paste line by line from the “my_defaults”, adopting each line to RoS7. So the problematic config was setup manually from blank. Hence I though I had missed out on something. I can’t reproduce this issue, hence it is pointless to file a bug report.