Practicing a wireguard setup- many questions

RouterOS Beginner Basics
1

I’m trying to build a simple wireguard setup on a very simple test network. This is my own training environment with nothing else significant connected to the network, so if I botch a firewall rule or something, it’s not the end of the world. But I’m struggling to get it working. I read https://forum.mikrotik.com/viewtopic.php?t=182340 and several other threads but I am not able to solve this.

Assumptions:
-I have a WAN connection on sfp1 on my hex/s
-My routerOS bridge (LAN) is assigned the address 192.168.88.1
-There is a raspberry pi on the LAN – assigned 192.168.88.8
-My ISP is kind enough to really never change my public address, and as far as I can tell they don’t block anything.
-“Server” refers to the hex/s
-“Client” refers to a linux laptop I would like to connect, via wireguard, from over the internet, and be able to log in to the hex/s and to the raspberry pi.
-The public IP of my client laptop could be anything since I will travel around with it, including connecting to the internet via mobile hotspot.
-I would like my client laptop to have a LAN IP address of 192.168.88.100 once it is connected thru wireguard.
-No other wireguard peers are planned at this time-- I’ll experiment with that after I get a basic connection working.
-I don’t need the client laptop to be able to access the internet again through the hex/s right now, but I would like to configure that at a later time.

Network diagram:
netdiagram.png
Most of the online tutorials assume you are trying to set up a PTP wireguard tunnel with 10.0.0.x subnetting; for instance, one mikrotik device to another. Since I’m not connecting two mikrotik devices, I don’t understand how to adapt these tutorials to my situation. Here are the rules I have set up on the hex/s (the “server”). But they don’t seem to work…

/interface wireguard
add listen-port=51820 mtu=1420 name=wireguard1
/interface wireguard peers
add interface=wireguard1 public-key="[REDACTED]"

/ip address
add address=192.168.88.1/24 comment=defconf interface=bridge network=192.168.88.0
add address=192.168.88.100 interface=wireguard1 network=192.168.88.0

/ip firewall
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="Allow Wireguard/UDP/51820" dst-port=51820 log=yes protocol=udp
add action=drop chain=input comment="defconf: drop invalid" connection-state=invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="defconf: accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN

I can ping the public address of my hex/s from my client. nmap UDP scan of port 51820 says the port is closed. So naturally, Wireguard won’t connect.

Assuming that I have the right public IP, and the ISP is not blocking anything, and my client wireguard configuration is correct, (I’m reasonably confident in these points, and I’m verifying them separately), Can anyone advise me:

  1. In general, does my approach seem to reflect any gross misunderstandings of wireguard?
  2. Is it feasible, or reasonable practice, to just have my wireguard client take an IP address of 192.168.88.100, or should I be following the example of making 10.0.0.x subnets like many tutorials describe? If so, what purpose would this serve?
  3. Since my current configuration fails, what rules may I have forgotten or set incorrectly?

Any help is much appreciated. I’d like to just get a simple wireguard proof of concept working before I try doing things like setting up a Tailscale container, or adding other complexities. Everyone seems to say wireguard is simple to set up, but I’m struggling.

Thank you,
Colm

PS. I actually just noticed the announcement of the new BTH VPN feature http://forum.mikrotik.com/t/new-feature-back-to-home-vpn/168434/1 but I want to learn to do things the hard way first :slight_smile:

2

Hi,

Try to run nmap from the LAN side of the router to eliminate any firewall issues. Hopefully you should see the port listed as open.

Your IP configuration will not work, with the wireguard and the bridge having addresses in the same subnet. You will need to assign a separate subnet to the wireguard interface, e.g. something like:

 add address=192.168.89.1/24 interface=wireguard1 network=192.168.89.0

Also, you state that you intend the client to have 192.168.88.100. The same address as you assign to the wireguard interface. Each end of the wireguard need to have separate addresses the same subnet. If going for 192.168.89.1 for the wireguard interface as suggested above, the client can have any other address in the same subnet, e.g. 192.168.89.100.

3

https://forum.mikrotik.com/viewtopic.php?t=182340

4

See my 3rd sentence :laughing: I did read this, it was helpful to a degree, but I struggled with some of the explanations in that post.

5

xrlls,

Thanks for the reply!

Ah, I tried nmap from the LAN, and it turns out I could reach the port from LAN but not the WAN. I have reached out to my ISP to see if they are blocking it. They are very accommodating in general so hopefully this doesn’t become a problem. But I still don’t think this rules out a problem with my firewall, does it?.

I appreciate the explanation about IP addresses. So, if I understand the concepts correctly:
-The wireguard interface needs its own IP address
-The wireguard interface IP address needs to be in a different subnet than the bridge (ie assign wireguard 192.168.89.1/24)
-There’s just no way the remote client can have an IP address in the 192.168.88.0/24 subnet (aha!)
-I can have the remote client claim any IP address in the 192.168.89.0/24 subnet except the wireguard interface address
-I need a routing rule to send inbound traffic from the wireguard interface to the bridge interface (I will review “(3) CONFIGURING THE IP ROUTES” in anav’s wireguard guide which I believe will explain this)

Hopefully things will go smoothly once I address these issues. Sometimes I get hung up on one or two faulty assumptions which causes everything else go to #*($@ :slight_smile:

Colm

6

If you have clear traffic requirements the config design is more easily and correctly discovered.

7

What can I do to better clarify my traffic requirements?

8

a. identify all user(s)/device(s) groups of users/devices including admin
b. identify all traffic flows that they need to accomplish…


Stating your laptop needs an IP address X, is not a requirement of traffic flow its a wish, not based in networking but some other desire and not germane to the config.
Unless you have a specific reason which will be demonstrated at b. above…

9

Anav,
Thanks for the explanation, I think I understand you better:

a) users/user groups/devices

  1. I am the only physical user of any of the devices.
  2. I am admin on the LAN (mikrotik HEX/s), and the raspberry pi, and the remote client (“laptop”).
  3. Also, see the simple network diagram attached to my initial post which identifies all the devices. (let me know if I need to annotate anything else, and I’ll update it)
  4. If this does not sufficiently answer the question, please let me know what more specific details would be helpful.

b) all specific traffic flows

  1. The laptop needs to be able to connect from over the internet, via wireguard, to the HEX/s and login as admin, and also, to into the raspberry pi by ssh (including ideally VNC over ssh tunnel, specifically, Remmina)
  2. Again, if this does not answer the question sufficiently, please guide me on what info is missing.

I’m confused by your last sentence (“…Stating your laptop needs an IP address X, is not a requirement of traffic flow its a wish, not based in networking…”) because clearly, assigning an IP address is a requirement somewhere in the configuration. I picked x.x.x.100 arbitrarily because it deconflicts with some other irrelevant IP assignments that are out of scope of my question. I don’t necessarily care which host number the IP address has, as long as I can control it, but it obviously can’t be nothing, so could you perhaps expand a little bit more what you mean?

Thanks again, and I really appreciate your having taken the time to help me understand this stuff.
Colm

10

Hi,

You got it right, except for the last point; regarding configuration of routes; it is not necessary to configure any routes to networks that are directly connected to the router, as the router will setup these routes automatically. You should see these routes in

ip/route

with a separate entry for your wireguard interface, and another for your bridge interface.

/Xrlls

11

A small clarification to the above statement regarding routes:
Your client will need to have route telling it that your LAN is reachable through the Wireguard tunnel. A host only configures routes to directly connected networks, and the routes to anything on the remote side of the tunnel, e.g. the LAN as seen from the VPN client, has to be configured manually.

12

In terms of wireguard speak, allowed IPs and IP routes have a close connection.
Incoming remote subnets, or if visiting remote subnets ( from local users ) means two things.
First that they are not local and thus routes are not automatically created for them and thus you need to create these routes.
Concomittantly the remote subnets coming or remote subnets local users are going to visit have to be identifed in allowed IPs.

Thus they are related to a certain extent.

13

Xrlls,
Got it, thank you! This has been very helpful. I think I understand the concepts better now than if I had just followed a rote tutorial and made it work, but didn’t understand what was happening. I also like how anav’s guide takes time to explain actual reasons.

I can try implementing this soon when I get back to the physical LAN location and I will report back how everything is working. If everything goes well I’ll mark this as solved.

anav,
Thank you also for this great explanation. I wasn’t familiar with “DAC” so I found the original Chen et al 2011[1] paper for some pleasure reading :slight_smile:
Your reply also makes me think about some other wireguard things I had not considered, which was further unexpected help. My new questions are not RouterOS-specific, so maybe a little off-topic for this forum, but I am enjoying this journey very much.

Colm

[1] https://ieeexplore.ieee.org/document/5783491

14

simply refers to the symbol you will see if you check your live IP routes, and it is found by all routers automatically generated by the router (local interface routes)