MikroTik

Posted: **Wed Apr 14, 2021 2:47 am**

This document is a tutorial on how to set up wireguard VPN on MikroTik for road warrior clients like iOS devices. RouterOS v7.x is needed.

Wireguard is like a series of point to point tunnels, but the same IP can be used on the side of the Wireguard system itself.* In this example, we have assigned a dedicated Wireguard subnet 192.168.66.0/24, separate from our main internal network on the Mikrotik. The Wireguard server router has the IP 192.168.66.1/24, and the Wireguard clients are 192.168.66.2, 192.168.66.3, etc. You end up with the following point to point tunnels formed:

192.168.66.1 (the Wireguard server router itself) <-----------> Wireguard client on 192.168.66.2
192.168.66.1 (the Wireguard server router itself) <-----------> Wireguard client on 192.168.66.3
etc.

These Wireguard client IPs are assigned statically, and typically use private IPs that are completely unrelated to their public IPs that these clients may actually be on. There is currently no dynamic means (ex. DHCP) for handing out IPs to Wireguard clients, which might make it unsuitable for very large RoadWarrior setups as manual configuration is needed for each user.

* Note: Technically, the Wireguard server router does not need an IP on this subnet, but if you do not give it one, you need to create static routes for your clients to be accessible. These routes are unnecessary if the Wireguard server router has an IP on this subnet as a "dynamic connected" route will exist, auto-created by the MikroTik, and this strategy will be easier for most users.

MikroTik Wireguard server config:

# a private and public key will be automatically generated when adding the wireguard interface
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireguard peers
# the first client added here is ipv4 only
add allowed-address=192.168.66.2/32 interface=wireguard1 public-key="replace-with-public-key-of-first-client"
# the second client is dual stack - public IPv6 should be used - replace 2001:db8:cafe:beef: with one of your /64 prefixes.
add allowed-address=192.168.66.3/32,2001:db8:cafe:beef::3/128 interface=wireguard1 public-key="replace-with-public-key-of-second-client-dual-stack"
/ip address
add address=192.168.66.1/24 interface=wireguard1 network=192.168.66.0
/ipv6 address
add address=2001:db8:cafe:beef::1/64 interface=wireguard1

Example iOS wireguard client config (acts as "second client" above):

Interface: (whatever name you want to specify)
Public key: the client should automatically generate this - add this to the server above replacing "replace-with-public-key-of-second-client-dual-stack"
Addresses: 192.168.66.3/24,2001:db8:cafe:beef::3/64          (note these are different subnet masks than in the server config)
DNS servers: as desired - if you want to use the wireguard server for dns, specify 192.168.66.1

Peer:
Public key - get the public key from the wireguard interface on the mikrotik and place here
Endpoint - mydyndns.whatever:13231
Allowed IPs: 0.0.0.0/0, ::/0

This config will result in the client sending all traffic through the MikroTik Wireguard server. If you do not want all traffic sent through (i.e. split include), limit the peer's "Allowed IPs" to whatever subnets it should access through the tunnel rather than 0.0.0.0/0 and ::/0

You also need to create an input chain firewall rule to allow UDP traffic to destination port 13231 in order for the Wireguard tunnel to be established in the first place.

/ip firewall filter add action=accept chain=input comment="Allow Wireguard" dst-port=13231 protocol=udp

The traffic you send when connected to Wireguard will come from your Wireguard client IP, 192.168.66.2 or 192.168.66.3 in my example. As a result, you have to make sure that your MikroTik firewall is allowing this traffic, that it is being NATted etc. If your config is based on the MikroTik default configuration, one way you can do this is by adding the Wireguard interface itself to your LAN interface list, which should take care of both allowing the traffic through and NATing it.

Posted: **Sun Apr 18, 2021 10:24 pm**

I would like to apply this setup on 7.1b5 in Webfig. However I'm not able to set the allowed-address for the server peer config, the field gets cleared when pressing Apply and is not saved when pressing OK. Is this some bug? Any other way to make this work? Thanks... I'm new to RouterOS.

Posted: **Tue Apr 20, 2021 2:22 am**

I would like to apply this setup on 7.1b5 in Webfig. However I'm not able to set the allowed-address for the server peer config, the field gets cleared when pressing Apply and is not saved when pressing OK. Is this some bug? Any other way to make this work? Thanks... I'm new to RouterOS.

Yes, I have had this happen a few times - you have to set them from the command line for now. For example:

/interface wireguard peers print

prints the list of wireguard peers - note the ID number of the peer you want to change, and then set it from the command line:

/interface wireguard peers set <ID> allowed-addresses=whatever,whateverelse

Posted: **Fri May 28, 2021 8:18 pm**

Could you please explain the correct firewall addition to allow this to work? I have tried a number of things without success. Also, does it need a static route? Is WireGuard assigning the IP address to the client as the peer IP? Can it be on the same network as my DHCP subnet everything else is on? Thanks in advance!

Posted: **Sat May 29, 2021 5:17 am**

Could you please explain the correct firewall addition to allow this to work? I have tried a number of things without success. Also, does it need a static route? Is WireGuard assigning the IP address to the client as the peer IP? Can it be on the same network as my DHCP subnet everything else is on? Thanks in advance!

Four questions, four answers:

1. You will need a firewall rule like this:

/ip firewall filter add action=accept chain=input comment="Allow Wireguard" dst-port=13231 protocol=udp

2. It doesn't need a static route, no

3. No, wireguard has no means of dynamic address assignment for clients - everything is static and is specified on the client side too

4. No, it cannot

Posted: **Sat May 29, 2021 7:20 pm**

My Wireguard Diagram using Beta5.
A. IOS phone to RBG wireguard server
B. External PC behind an MT RB4011 router acting as a wireguard client connected to a different RBG wireguard server.
C. The iphone and external PC are associated with a different WG server Interface on the RBG (2 WG interfaces each with one peer, vice ONE interface and two peers).
D. The WireGuard interfaces do not require any subnet or IP address.

Notes:
1. Both MT wireguard devices (server and client) are behind a primary router.
2. The IOS smartphone connection is used to manage the CCR1009, the RBG and the RB4011 routers through the wireguard interfaces.
3. The IOS smartphone and external PC wireguard connections are used to provide internet through the CCR WAN connection.
4. Throughput is approx 300up and 300down with primary routers connected to the same 1Gig fiber network (within 15km).
5. Plan will be to remove RBG once wireguard is moved out of beta.
...

Drawingwireguardvers4.png

Posted: **Sat May 29, 2021 7:43 pm**

Hi

Thanks for your example. Very appreciated.

Unfortunately I cannot replicate it. May you have any hint based on my configuration?

After activating the client in macOS (same applies to iOS), it shows "activated", but I cannot ping the wireguard server (nor access the webfig. I tried all ip-addresses). The keys are for test purpose only.

Wireguard-Server on Mikrotik hEX S, which is attached to ISP with fiber

mikrotik.jpeg

Wireguard-Client on macOS

macOS client.jpg

Thanks in advance.

Simon

This is just intended as a basic config example for how to set up wireguard VPN on MikroTik for road warrior clients like iOS devices:

MikroTik wireguard server config:

# a private and public key will be automatically generated when adding the wireguard interface
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireguard peers
# the first client added here is ipv4 only
add allowed-address=192.168.66.2/32 interface=wireguard1 public-key="replace-with-public-key-of-first-client"
# this client is dual stack - public IPv6 should be used - replace 2001:db8:cafe:beef: with one of your /64 prefixes.
add allowed-address=192.168.66.3/32,2001:db8:cafe:beef::3/128 interface=wireguard1 public-key="replace-with-public-key-of-second-client-dual-stack"
/ip address
add address=192.168.66.1/24 interface=wireguard1 network=192.168.66.0
/ipv6 address
add address=2001:db8:cafe:beef::1/64 interface=wireguard1

iOS wireguard client config (acts as "second client" above):

Interface: (whatever name you want to specify)
Public key: the client should automatically generate this - add this to the server above replacing "replace-with-public-key-of-second-client-dual-stack"
Addresses: 192.168.66.3/24,2001:db8:cafe:beef::3/64          (note these are different subnet masks than in the server config)
DNS servers: as desired - if you want to use the wireguard server for dns, specify 192.168.66.1

Peer:
Public key - get the public key from the wireguard interface on the mikrotik and place here
Endpoint - mydyndns.whatever:13231
Allowed IPs: 0.0.0.0/0, ::/0

This config will result in the client sending all traffic through the MikroTik wireguard server. If you do not want all traffic sent through (i.e. split include), limit the peer's "Allowed IPs" to whatever subnets it should access through the tunnel rather than 0.0.0.0/0 and ::/0

Posted: **Sat May 29, 2021 9:12 pm**

Unfortunately I cannot replicate it. May you have any hint based on my configuration?

Your wireguard interface for roadwarriors should also be in the LAN interface list - make sure you have done that.

Posted: **Sun May 30, 2021 1:27 am**

Thanks for your swift reply.

Still NOT working. Do you have any more ideas?

I added the following entry in the list section. Not sure if this is what you asked me to do.

LAN.jpg

I also tried to add it to the bridge, but this was not successful either. So I deleted it again.

BRIDGE.jpg

Looking forward to your feedback.

Best,
Simon

Your wireguard interface for roadwarriors should also be in the LAN interface list - make sure you have done that.

Posted: **Sun May 30, 2021 2:00 am**

Make sure the "allow wireguard" rule is above your drop rules on the input chain, specifically it should at least be above the "drop all" final input chain rule. It looks to me like you have it at the very end instead, which is too late. On mine I have it just above the "drop invalid" rule for the input chain, although that may not strictly be necessary.

Posted: **Sun May 30, 2021 5:03 am**

Server Router Key points:

1. The wireguard is a service on the router and thus one has to allow the initial unencrypted traffic to the router via the INPUT CHAIN, which entails the listening port, protocol UDP, interface (coming from) the wan. With a road warrior one cannot narrow it down further by source address. As stated already this needs to be right after the input chain default firewall rules (like after accept ICMP ping) and before any drop rules etc....

So what happens is that the client traffic will hit the internet, hit the server router and then be directed to the wireguard service. If you log this rule, you should get basically a one log entry if successful. The tunnel will be negotiated and established. Once that is done, the client will be able to travel through the tunnel to the wireguard interface. The traffic will be routed out the available main table routing already in place at the server router.

[2. Ensure one puts an IP Route on the MT Server Router that will direct return traffic from the internet back through the wireguard tunnel to the client device. Therefore the destination address is the lan subnet of the client device or the IP of the client device) and the gateway is the wireguard interface

Posted: **Sun May 30, 2021 5:23 am**

[2. Ensure one puts an IP Route on the MT Server Router that will direct return traffic from the internet back through the wireguard tunnel to the client device. Therefore the destination address is the lan subnet of the client device or the IP of the client device) and the gateway is the wireguard interface

This is only necessary if there isn't already one - for instance, if the wireguard is not being done by the same device. If it is being done by the same device (as in most cases), there will already be a connected route (C) to deliver the return traffic, and manually adding an extra route on the MikroTik is unnecessary and unhelpful.

Posted: **Sun May 30, 2021 12:56 pm**

Thanks @mducharme @anav for your extensive support.

I will test this next Sunday and give you an update

Best,
Simon

Posted: **Sun May 30, 2021 3:01 pm**

[2. Ensure one puts an IP Route on the MT Server Router that will direct return traffic from the internet back through the wireguard tunnel to the client device. Therefore the destination address is the lan subnet of the client device or the IP of the client device) and the gateway is the wireguard interface
This is only necessary if there isn't already one - for instance, if the wireguard is not being done by the same device. If it is being done by the same device (as in most cases), there will already be a connected route (C) to deliver the return traffic, and manually adding an extra route on the MikroTik is unnecessary and unhelpful.

When the server router gets return packets from the internet for a subnet or IP address that is not known to the router (wg client devices using the tunnel) not configured on the router, the IP route tells the router, oh, for these packets send them to the WG interface. Without these routes for both my client MT device and associated PC, and the iphone, there is no other magic way for them to get the return traffic??

As far as I am aware, wireguard config does not automatically create IP routes?
Perhaps, my example is unique being behind another MT router?
In this case you can see that I have to create an IP Route for internet return traffic, on the CCR first router, specifically for the return traffic of the client devices (iphone or external pc) to the LANIP/WANIP of the secondary wireguard server router. Then I do the same at the Server Router to point the return packets back at the tunnel.

Are you saying this is all done automatically when using only a single router? I do have masquerade sourcenat on both routers but this is not enough!

Posted: **Sun May 30, 2021 10:28 pm**

Are you saying this is all done automatically when using only a single router? I do have masquerade sourcenat on both routers but this is not enough!

Yes, it is automatic when using a single router. Your situation is different in that your Wireguard server is behind another router.

As an example, the router as a wireguard server directly connected to the internet with a public IP as the main gateway will have an IP of, for instance, 192.168.66.1/24. As a result of having this address, the router has a connected route to the wireguard interface for the subnet 192.168.66.0/24. Suppose the client is assigned 192.168.66.2/32. The client goes to a website, and since allowed-ips on the client side are 0.0.0.0/0, it sends everything across Wireguard to the router. The router masquerades this (as long as the wireguard interface is in the LAN interface list) and sends it to the internet. The response coming back is received by the router which knows it has to get the packet back to 192.168.66.2. It checks its routing table to see where 192.168.66.2 is, and sees that it already has a connected route for that subnet and that it belongs to the wireguard interface.

Posted: **Sun May 30, 2021 11:19 pm**

No still dont see it nor agree but I think you are missing a key point ----> I do not assign an IP or IP address to the wireguard interface in my design. It is only an interface period.

EDIT: This is a possible approach but creating the wireguard address IS the BETTER approach. Sob drilled it into me finally

Posted: **Sun May 30, 2021 11:59 pm**

No still dont see it nor agree but I think you are missing a key point ----> I do not assign an IP or IP address to the wireguard interface in my design. It is only an interface period.

OK I see. What benefit is there to not using an IP address on the wireguard interface? (Other than saving one IP address)

Posted: **Mon May 31, 2021 12:21 am**

No still dont see it nor agree but I think you are missing a key point ----> I do not assign an IP or IP address to the wireguard interface in my design. It is only an interface period.
OK I see. What benefit is there to not using an IP address on the wireguard interface? (Other than saving one IP address)

Why do you need an IP address? What functionality does adding an IP address on the WG provide??
Currently, from my iphone I can manage/configure every MT router attached somehow to Wireguard.
I can get internet from the WG server from my iphone.
The external PC connected to the wirguard server can get internet.
The external PC connected to the wireguard server can reach my printers on a different vlan if necessary...........

Posted: **Mon May 31, 2021 1:20 am**

Why do you need an IP address? What functionality does adding an IP address on the WG provide??
Currently, from my iphone I can manage/configure every MT router attached somehow to Wireguard.
I can get internet from the WG server from my iphone.
The external PC connected to the wirguard server can get internet.
The external PC connected to the wireguard server can reach my printers on a different vlan if necessary...........

I do not completely know, but it is present in all Wireguard documentation and tutorials that I have found to do this. You seem to have invented your own method that is different from all other Wireguard tutorials out there, and deviates from what the documentation states. I would suspect since all of the documentation shows to do this, that there is a reason for it, and it isn't just some completely useless practice.

Although I haven't tried it, something I suspect might not work with your setup is if you had two Wireguard clients connecting to your Wireguard server and you want them to be able to connect to each other. For instance, two iPhones connecting may not be able to ping each other, but be able to reach everything else. This works fine with an IP on the Wireguard server end, with one wireguard interface with 192.168.66.1/24 and two configured peers on 66.2 and 66.3.

Posted: **Mon May 31, 2021 1:48 pm**

I am not discounting your approach because their may be instances where it is useful, just haven't stumbled across them yet.
Out of curiosity do you just assign an IP address to a wireguard interface or do you assign a subnet and then give client devices an IP in that subnet??

When you say you can connect two clients together, what practical purpose is that used for?? Once folks have an internet connection through the server, they can use discord or a other apps to chat for example so looking for practical examples of why its necessary. I think its not a good idea for users to have a party on your wireguard server LOL, In fact having them on the same subnet if automatically allows connected client users to see each is bad security especially if you have no way of blocking them!!!!
I suspect that having two peers on the same interface WITHOUT an ip address structure probably prevents them from seeing each other automatically but not sure since havent tested it.

Posted: **Mon May 31, 2021 9:54 pm**

Out of curiosity do you just assign an IP address to a wireguard interface or do you assign a subnet and then give client devices an IP in that subnet??

The wireguard interface on the router gets 192.168.66.1/24, and the clients get 66.2/24, 66.3/24, etc. This is done exactly as described in the official wireguard documentation, including all of the major tutorials. If you are unfamiliar with this setup, I am guessing you have not read the documentation, as this is the normal wireguard setup.

When you say you can connect two clients together, what practical purpose is that used for?? Once folks have an internet connection through the server, they can use discord or a other apps to chat for example so looking for practical examples of why its necessary. I think its not a good idea for users to have a party on your wireguard server LOL, In fact having them on the same subnet if automatically allows connected client users to see each is bad security especially if you have no way of blocking them!!!!

There are a few scenarios where this could be important. You can have a roadwarrior-type setup to connect a main office and two branch offices, in the case where the branch offices are behind CG-NAT and cannot do a site-to-site as a result. In this case, it may not be desirable to block all communications from one branch office to the next.

Even with individual devices, certain applications (such as Skype) will attempt to establish the most direct link between the devices possible rather than sending everything through a central server. For instance, if you start a Skype call with someone on the same LAN or different subnets on the same corporate network, that traffic will not travel over the Internet, it goes directly between the two endpoints. In this event, if you are blocking traffic between the endpoints, this traffic will get blocked. Depending on the design of the collaboration app, it may have a means to detect this and fail over to using a central server as proxy, or it may not. If it does not, your employees connecting to the VPN may be prevented from video chatting with each other with certain apps while on the VPN, while being able to video chat perfectly fine with anybody outside of the company.

Posted: **Thu Jun 03, 2021 10:36 am**

There is another reason I can see for having IP addresses on the Wireguard interfaces themselves - easy troubleshooting. If Wireguard is not working and you don't know why, having the IPs on both sides on that interface, and using those to do ping tests, allows you eliminate certain kinds of routing issues and test the operation of the tunnel in a much more basic way.

Posted: **Fri Jun 04, 2021 2:52 am**

There is another reason I can see for having IP addresses on the Wireguard interfaces themselves - easy troubleshooting. If Wireguard is not working and you don't know why, having the IPs on both sides on that interface, and using those to do ping tests, allows you eliminate certain kinds of routing issues and test the operation of the tunnel in a much more basic way.

I do the same ping troubleshooting without IP address :-)
When the client pings they are pinging from a subnet so it you can test what the PC behind the subnet being directed can ping and then you can track it on the other end of the tunnel on the server end by IP address for example, not difficult, or any traffic for that matter.
All the troubles I've had (key some music), were stupid errors on my part that didnt need pinging in the end, it was simply not understanding packet flow.

Posted: **Fri Jun 04, 2021 3:13 am**

I do the same ping troubleshooting without IP address :-)

I know you do, but I am thinking more about what is easiest to understand for people who are not as technically proficient. If Wireguard does not seem to be working, it could be harder for them to trace down the issue if you do not have an address on both sides on the Wireguard interface. If you have an IP address the Wireguard interface on both sides, and they can't ping each other, you can be sure the issue is with Wireguard itself. If you set things up without any IP addresses and they can't ping each other, the problem could either be in the Wireguard configuration or in the routing.

Posted: **Fri Jun 04, 2021 3:20 am**

I do the same ping troubleshooting without IP address :-)
I know you do, but I am thinking more about what is easiest to understand for people who are not as technically proficient. If Wireguard does not seem to be working, it could be harder for them to trace down the issue if you do not have an address on both sides on the Wireguard interface. If you have an IP address the Wireguard interface on both sides, and they can't ping each other, you can be sure the issue is with Wireguard itself. If you set things up without any IP addresses and they can't ping each other, the problem could either be in the Wireguard configuration or in the routing.

Guaranteed the problem is routing LOL, Its not that difficult to put in the wireguard settings, although the tricky part is putting in 0.0.0.0/0 at the client site, peer entry for allowed IPs and to put in the endpoint with listening port appended at the client side, peer entry if there is not a separate entry for the port.

Posted: **Tue Jun 08, 2021 6:43 am**

Guaranteed the problem is routing LOL, Its not that difficult to put in the wireguard settings, although the tricky part is putting in 0.0.0.0/0 at the client site, peer entry for allowed IPs and to put in the endpoint with listening port appended at the client side, peer entry if there is not a separate entry for the port.

The problem is likely routing, but for people who are unfamiliar with wireguard they may not be aware of the need to specify the allowed addresses. I think it is simpler for most to just have the IPs on both sides of the interface You can do all sorts of weird/crazy things if you are experienced with wireguard, but those new to it are probably best off following the "standard" setups.

Posted: **Sat Jun 26, 2021 11:02 pm**

Hi Guys,

I am nowhere close to an expert, rather hobbyist.
I have WireGuard Server on RB4011 to which I can connect from my mobile.
I can even see my requests being routed from my mobile to other devices in my network using torch- like through VPN trying to load Audience AP WebFig.
So it is like: Mobile ---WG over Internet---> RB4011 Router --> Audience.
As said, on Audience I can see requests coming from mobile, however torch is only showing RX and nothing is being sent back at all which I am finding very weird and WG definitely works.

Now I am trying to avoid WG to have its own network, but instead added WG interface to my bridge and client is using IP from my main home network subnet.
I am using VLANs, but this doesn't seem to be a problem as pockets are leaving RB4011 to Audience and reported by Torch on Audience, but Audience is not responding with any pockets back.
How come? I am not running any fw on it and it is reachable from other ips in same subnet.

I am sure I am missing something stupid or not understand some basics here, but just can't crack it and wondering if can get some help.

It works with dedicated subnet for WG, but I am still not sure why do I need dedicated subnet at all, knowing packets were actually reaching my Audience.

Posted: **Mon Jun 28, 2021 3:19 am**

but instead added WG interface to my bridge and client is using IP from my main home network subnet.

Wireguard is a layer 3 tunnel, not layer 2, so it will not work adding it as a bridge port like that.

MikroTik should not even allow adding layer-3-only interface types to a bridge, and they do not in the case of GRE, so the fact that they incorrectly include wireguard in this list is probably a bug.

Posted: **Wed Jun 30, 2021 5:38 pm**

mducharme covered the salient points.
Cannot help further without seeing both configs........
/export hide-sensitive file=anynameyouwish

Posted: **Fri Jul 30, 2021 2:50 pm**

I am using 7.1b6 and CCR1009-7G-1C-1S+ and I also cannot get wireguard VPN to work with road warriors.

I have verified that the public / private keys are definitely setup correctly as once I change it at either the road warrior or the Mikrotik router, I only have transmitted packets on the client. However, if they are setup correctly, I have transmit and receive.

I added the corresponding forward rules and wireguard rules at the top of my firewall list to ensure this isn't an issue.allowed forward in both directions to be sure.
I tried once adding an IP for the router in the corresponding wireguard subnet, this will automatically create the route, it didn't work. I cannot access any device in one of my target subnets/allowed IPs.
Then I tried to remove the router IP for wireguard and add the route static, didn't work either. I don't have any forward traffic.

What I also noticed is that doing some changes to an active wireguard interface, especially deleting a peer or interface, results in the router partly freezeing, sometimes a reboot works, sometimes even that freezes and I need to cut power to it to get it working again which makes all these tests even more difficult.

Posted: **Fri Jul 30, 2021 9:56 pm**

I have done some furher testing and it might be an issue to the used router/hardware, see my post in another thread: viewtopic.php?f=1&t=175643&p=870251#p870251

I was able to get it working fine immediately with the same settings on a different Mikrotik router which is a RBwAPR-2nD vs my default router CCR1009-7G-1C-1S+

The RBwAPR-2nD is a a MIPSBE type router and the CCR1009-7G-1C-1S+ is a TILE based one. So maybe it is related to the used base architecture or maybe a more specialized router issue?

Posted: **Sat Aug 14, 2021 11:56 am**

I experienced same issue , same wireguard setting x86 vs ccr1009.

CCR 1009 is not working at all with beta 6.
It's only one way traffic

Posted: **Thu Sep 09, 2021 6:01 pm**

Is this strictly for iOS?

I tried replicating the settings. My android phone looks like it connects, but I have no WAN/LAN.

Also, I'm trying to understand the need for the different IPs in this set up.

Posted: **Thu Sep 09, 2021 8:28 pm**

I do not have an Android device, but this should work in the same way as iOS.

Wireguard is like a series of point to point tunnels, but the same IP can be used on the side of the wireguard system itself. So in this case there is a wireguard subnet 192.168.66.0/24 and you end up with the following point to point tunnels formed:

192.168.66.1 (the wireguard router itself) <-----------> wireguard client on 192.168.66.2
192.168.66.1 (the wireguard router itself) <-----------> wireguard client on 192.168.66.3
etc.

The traffic you send when connected to wireguard will come from your wireguard client IP, 192.168.66.x in my example. So you have to make sure that your firewall is allowing this traffic, that it is being NATted etc. If your config is based on the mikrotik default configuration, one way you can do this is by adding the wireguard interface itself to your LAN interface list

Posted: **Fri Sep 10, 2021 12:50 pm**

Thank you very much for the explanation. It actually helped me understand and fix the issue.

And now I have it working, it is actually very easy to set up.

Posted: **Sat Sep 11, 2021 1:02 am**

Make sure the "allow wireguard" rule is above your drop rules on the input chain, specifically it should at least be above the "drop all" final input chain rule. It looks to me like you have it at the very end instead, which is too late. On mine I have it just above the "drop invalid" rule for the input chain, although that may not strictly be necessary.

So I finally got Wireguard on a Road Warrior (macOS Monterey) working. The problem was that firewall rule was not in the proper position (see above). In addition the "WebFig" UI I used to configure the firewall seems to be buggy in 7.1 (I tired beta6 and rc3). It only worked after deleting the rule and re-adding it via the terminal.

Thanks for your help @anav @mducharme.
Cheers
Simon

Posted: **Thu Sep 16, 2021 12:12 am**

Is it possible to have ROS automatically kill WireGuard sessions when clients rejoin the LAN?

Posted: **Thu Sep 16, 2021 12:38 am**

Your question is to vague but if it can it would be a script............

Posted: **Sun Sep 26, 2021 11:45 am**

Hi there, thanks for the guide! Would like to ask for some assistance however, as am struggling to set this up over the weekend while following several guides.
I've managed to successfully establish a handshake between my android phone and the Tik, but there's no internet access and the log shows a barrage of the following message when enabling wireguard on my phone:

Buffer: memory Topics: Firewall, info WG: input: in:pppoe-outFEED out:(unknown 0), src-mac (phone mac), proto UDP, (sensitive, phone public IP) -> (sensitive, Tik public IP), len 124

.
The "no-internet-access" issue resolves if I configure the android client Allowed Addresses to my LAN subnet instead of 0.0.0.0/0, but I'm still getting the log barrage and I'm not certain that the traffic is properly routed through my pihole.

My network setup is as follows: ISP<-> ISP modem (bridge mode) <-> Mikrotik router (PPPoE) <-> LAN (Pihole DNS server)

# sep/26/2021 10:46:55 by RouterOS 7.1rc4
# software id = W9WG-AU8M
#
# model = 960PGS
# serial number = (sensitive)
/interface bridge
add arp=proxy-arp comment="LAN Bridge" name=bridge
/interface ethernet
set [ find default-name=ether1 ] comment="WAN Primary   - Modem" speed=\
    100Mbps
set [ find default-name=ether2 ] advertise=1000M-half,1000M-full comment=\
    " - Minion" poe-out=off speed=100Mbps
set [ find default-name=ether3 ] comment=" - Unraid" poe-out=off speed=\
    100Mbps
set [ find default-name=ether4 ] comment=" - SHIELD" poe-out=off speed=\
    100Mbps
set [ find default-name=ether5 ] comment=" - Camera" poe-out=forced-on speed=\
    100Mbps
set [ find default-name=sfp1 ] advertise=1000M-half,1000M-full comment=\
    " - Switch"
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface vlan
add interface=ether2 name=vlan4000-ether2 vlan-id=4000
add interface=ether3 name=vlan4000-ether3 vlan-id=4000
add interface=ether5 name=vlan4000-ether5 vlan-id=4000
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 name=pppoe-outFEED \
    user=(sensitive)
/interface list
add name=WAN
add name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.3-192.168.88.254
add name=dhcp_pool2 ranges=10.10.102.2-10.10.102.254
add name=dhcp_pool3 ranges=10.10.105.2-10.10.105.254
add name=dhcp_pool4 ranges=10.10.113.2-10.10.113.254
add name=dhcp_pool5 ranges=10.10.117.2-10.10.117.254
add name=dhcp_pool6 ranges=10.10.119.2-10.10.119.254
/ip dhcp-server
add address-pool=dhcp interface=bridge lease-time=10m10s name=dhcp1
/queue simple
add name=Minion_QOS packet-marks=Minion_Packets priority=1/1 target=ether2
/queue tree
add limit-at=5M max-limit=7M name="Jelly Out" packet-mark=jellyfinout parent=\
    global
/queue type
add kind=sfq name=sfq-default sfq-perturb=10
/queue simple
add max-limit=10M/100M name=sfq-default queue=sfq-default/sfq-default target=\
    192.168.88.0/24 total-queue=sfq-default
/queue tree
add limit-at=10M max-limit=10M name="Minion Out" packet-mark=Minionout \
    parent=global priority=1 queue=sfq-default
/routing bgp template
set default as=65530 disabled=no name=default output.network=bgp-networks
/routing ospf instance
add in-filter-chain=ospf-in name=default-v2 out-filter-chain=ospf-out
/routing ospf area
add instance=default-v2 name=backbone-v2
/routing table
add fib name=""
/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,pas\
    sword,web,sniff,sensitive,api,romon,dude,tikapp,rest-api"
add name=sniffer policy="ssh,read,!local,!telnet,!ftp,!reboot,!write,!policy,!\
    test,!winbox,!password,!web,!sniff,!sensitive,!api,!romon,!dude,!tikapp,!r\
    est-api"
/interface bridge port
add bridge=bridge ingress-filtering=no interface=ether2
add bridge=bridge ingress-filtering=no interface=ether3
add bridge=bridge ingress-filtering=no interface=ether4
add bridge=bridge ingress-filtering=no interface=ether5
add bridge=bridge ingress-filtering=no interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip settings
set rp-filter=strict
/ipv6 settings
set disable-ipv6=yes
/interface list member
add interface=ether1 list=WAN
add interface=bridge list=LAN
add interface=pppoe-outFEED list=WAN
/interface wireguard peers
add allowed-address=10.0.0.1/32 interface=wireguard1 persistent-keepalive=25s \
    public-key="[i](sensitive)[/i]"
/ip address
add address=192.168.88.1/24 comment="LAN Primary" interface=bridge network=\
    192.168.88.0
add address=192.168.42.1/24 comment="IoT vlan (eth1,2,5)" interface=\
    vlan4000-ether3 network=192.168.42.0
add address=192.168.42.1/24 interface=vlan4000-ether5 network=192.168.42.0
add address=192.168.42.1/24 interface=vlan4000-ether2 network=192.168.42.0
add address=10.0.0.1/24 interface=wireguard1 network=10.0.0.0
add address=192.168.1.2/24 comment="Modem Gateway" interface=ether1 network=\
    192.168.1.0
/ip cloud
set ddns-enabled=yes ddns-update-interval=1m
/ip dhcp-server lease
add address=192.168.88.253 client-id=1:cc:2d:e0:aa:7:6e comment=WiFi \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.252 client-id=1:cc:2d:e0:aa:7:70 comment=WiFi \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.98 client-id=1:b8:27:eb:cd:dc:1d comment=PiHole \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.57 client-id=1:0:4:4b:bd:d:5d comment="Nvidia Shield" \
    mac-address=[i](sensitive)[/i] server=dhcp1
add address=192.168.88.88 client-id=1:b8:ac:6f:90:e0:f8 comment=Unraid \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.8 client-id=1:b4:2e:99:3b:14:e5 comment=Minion \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.125 comment=HomeAssistant mac-address=\
    (sensitive) server=dhcp1
add address=192.168.88.128 client-id=1:74:4d:28:75:6e:30 comment=Switch \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.38 client-id=1:94:53:30:3b:99:9c comment=LaserPrinter \
    mac-address=[i](sensitive)[/i] server=dhcp1
add address=192.168.88.10 client-id=1:52:54:0:52:63:75 comment=macOS \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.20 comment="3D Printer" mac-address=[i](sensitive) [/i]\
    server=dhcp1
add address=192.168.88.95 client-id=1:2c:44:fd:c1:2e:c8 comment=\
    "Color Printer" mac-address=[i](sensitive)[/i] server=dhcp1
add address=192.168.88.19 client-id=1:b8:ac:6f:90:e1:0 comment=R710 \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.4 client-id=1:ca:37:29:9:d8:a7 comment="Phone" \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.11 client-id=1:30:a9:de:c3:52:bc comment=TV \
    mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.3 comment="Nintendo Switch" mac-address=\
    [i](sensitive)[/i] server=dhcp1
add address=192.168.88.9 client-id=1:8:ed:ed:5d:c6:8e comment=\
    "Dahua (camera)" mac-address=[i](sensitive) [/i]server=dhcp1
add address=192.168.88.22 client-id=1:52:54:0:3a:7b:82 mac-address=\
  [i]  (sensitive) [/i]server=dhcp1
add address=192.168.88.141 client-id=1:50:1e:2d:3f:50:ba comment=Anthem \
    mac-address=[i](sensitive) [/i]server=dhcp1
/ip dhcp-server network
add address=192.168.88.0/24 dns-server=192.168.88.98 gateway=192.168.88.1 \
    netmask=24
/ip dns
set allow-remote-requests=yes cache-max-ttl=1m servers=192.168.88.98
/ip firewall address-list
add address=192.168.88.2-192.168.88.254 list=allowed-to-router
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=\
    established,related hw-offload=yes
add action=accept chain=input comment="Accept WireGuard" dst-port=13231 \
    in-interface-list=WAN log=yes log-prefix=WG: protocol=udp
add action=accept chain=forward comment="Accept WireGuard" connection-state=\
    established,new disabled=yes dst-port=13231 in-interface=pppoe-outFEED \
    log=yes log-prefix=WG: protocol=udp
add action=accept chain=forward comment=\
    "Accept established,related,untracked" connection-state=\
    established,related,untracked
add action=accept chain=forward comment="Accept LAN >>> WAN" disabled=yes \
    out-interface=ether1 src-address=192.168.88.0/24
add action=drop chain=forward comment="drop all from WAN not DSTNATed" \
    connection-state=new in-interface-list=WAN
add action=drop chain=forward comment="Drop invalid" connection-state=invalid
add action=drop chain=input in-interface-list=!LAN
add action=drop chain=input comment="Drop Blacklisted Hosts through Router" \
    in-interface=ether1 src-address-list=BlackList
add action=drop chain=forward comment="Drop Blacklisted Hosts through Router" \
    in-interface=ether1 src-address-list=BlackList
add action=accept chain=input comment="Accept to Router" src-address-list=\
    allowed_to_router
add action=accept chain=input comment="Accept ICMP" protocol=icmp
add action=accept chain=input connection-state=established disabled=yes
add action=accept chain=input comment="accept local loopback (for CAPsMAN)" \
    dst-address=127.0.0.1
/ip firewall mangle
add action=mark-packet chain=forward comment=jellyfin_rx_mark \
    new-packet-mark=jellyfinout passthrough=yes src-address=192.168.88.88
add action=mark-packet chain=forward comment=Minion_rx_mark new-packet-mark=\
    Minionout passthrough=yes src-address=192.168.88.8
/ip firewall nat
add action=masquerade chain=srcnat comment="LAN - NAT (towards modem)" \
    out-interface=ether1
add action=masquerade chain=srcnat comment="LAN - NAT (towards web)" \
    out-interface=pppoe-outFEED
add action=dst-nat chain=dstnat comment=\
    "Pihole - run any upd traffic (except Pihole) through Pihole" \
    dst-address=!192.168.88.98 dst-port=53 protocol=udp src-address=\
    !192.168.88.98 to-addresses=192.168.88.98
add action=dst-nat chain=dstnat comment=\
    "Pihole - run any tcp traffic (except Pihole) through Pihole" \
    dst-address=192.168.88.98 dst-port=53 protocol=tcp src-address=\
    !192.168.88.98 to-addresses=192.168.88.98
add action=masquerade chain=srcnat comment=Pihole dst-address=192.168.88.98 \
    dst-port=53 protocol=udp src-address=192.168.88.0/24
add action=masquerade chain=srcnat comment=Pihole dst-address=192.168.88.98 \
    dst-port=53 protocol=tcp src-address=192.168.88.0/24
add action=dst-nat chain=dstnat comment="TCP inbound to port 443 >> 192.168.88.88:1444
    dst-port=443 in-interface=pppoe-outFEED protocol=tcp to-addresses=\
    192.168.88.88 to-ports=1444
add action=dst-nat chain=dstnat comment="UDP inbound to port 443 >> 192.168.88.88:1444
    dst-port=443 in-interface=pppoe-outFEED protocol=udp to-addresses=\
    192.168.88.88 to-ports=1444
add action=dst-nat chain=dstnat disabled=yes dst-port=13231 in-interface=pppoe-outFEED protocol=udp \
    src-port="" to-addresses=192.168.88.1 to-ports=13231
/ip route
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=pppoe-outFEED \
    pref-src="" routing-table=main scope=30 suppress-hw-offload=no \
    target-scope=10
/ip service
set telnet disabled=yes
set ftp disabled=yes port=2121
set www disabled=yes port=8081
set ssh disabled=yes
set www-ssl disabled=no tls-version=only-1.2
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set forwarding-enabled=remote strong-crypto=yes
/ip upnp interfaces
add interface=ether1 type=external
add interface=bridge type=internal
/system clock
set time-zone-name=Europe/Athens
/system identity
set name="hex PoE"
/system package update
set channel=development

Posted: **Mon Sep 27, 2021 3:20 am**

The "no-internet-access" issue resolves if I configure the android client Allowed Addresses to my LAN subnet instead of 0.0.0.0/0, but I'm still getting the log barrage and I'm not certain that the traffic is properly routed through my pihole.

Your wireguard interface is not in the Interface List called "LAN". Please see the last paragraph of this reply: viewtopic.php?f=23&p=882295#p878732

Posted: **Mon Sep 27, 2021 1:43 pm**

Your wireguard interface is not in the Interface List called "LAN". Please see the last paragraph of this reply: viewtopic.php?f=23&p=882295#p878732

Thanks for the prompt reply. I believe I'm missing something here:
I assigned the "wireguard1" interface to my LAN list as advised- by enabling wireguard on my phone while on LAN there's some torch activity, however no activity is listed if I attempt to enable it via cellular (i.e. no obvious change following the LAN interface addition).
The following settings appear to produce some results:

/ip firewall filter add action=accept chain=input comment="Accept Wireguard" dst-port=13231 protocol=udp in-interface-list=WAN

results in the log barrage as indicated in my initial post, along with some torch activity,

/ip firewall filter add action=accept chain=input comment="Accept Wireguard" dst-port=13231 protocol=udp in-interface-list=LAN

results in no torch activity,

/ip firewall filter add action=accept chain=input comment="Accept Wireguard" dst-port=13231 protocol=udp out-interface-list=WAN

- no activity,

/ip firewall filter add action=accept chain=input comment="Accept Wireguard" dst-port=13231 protocol=udp in-interface=wireguard1

- no activity,

/ip firewall filter add action=accept chain=input comment="Accept Wireguard" dst-port=13231 protocol=udp out-interface=wireguard1

- no activity.

Apologies for the cluelessness, I'm a newbie in routeros yet constantly trying to learn.

Posted: **Mon Sep 27, 2021 2:04 pm**

I see another issue:

/interface wireguard peers
add allowed-address=10.0.0.1/32 interface=wireguard1 persistent-keepalive=25s \
    public-key="[i](sensitive)[/i]"

10.0.0.1 is the IP of your router itself. You cannot assign the same IP to your client device (phone etc) that you have assigned to the router.

Posted: **Mon Sep 27, 2021 3:17 pm**

I see another issue:
Code: Select all
/interface wireguard peers
add allowed-address=10.0.0.1/32 interface=wireguard1 persistent-keepalive=25s \
    public-key="[i](sensitive)[/i]"
10.0.0.1 is the IP of your router itself. You cannot assign the same IP to your client device (phone etc) that you have assigned to the router.

No luck with changing the allowed address to 10.0.0.8/32 on routeros and the android client.
I'm somewhat confused by the fact that the log firewall entry shows input-in as "pppoe-outFEED" whenever there's activity/handshake instead of the assigned interface "wireguard1", it appears that the traffic is routed through WAN (pppoe-outFEED) instead of the previously assigned LAN (wireguard1) interface. Not sure if related to the solution, guess it's worth noting.
Edit: I inserted an accept-forward rule for the in. interface "wireguard1", log shows the above message along with WG: forward: in:wireguard1 out:bridge, proto UDP, 10.0.0.8:12117 (android peer)->192.168.88.98:53 (pihole).

The following configuration allows me to ping android peer <-> LAN, while torch on the wireguard1 interface shows some packets towards 10.0.0.1 (router), 192.168.88.98 (pihole DNS), and some (I believe) external public IPs when opening youtube for example, however internet is still inaccessible.

# sep/27/2021 15:18:14 by RouterOS 7.1rc4
# software id = W9WG-AU8M
#
# model = 960PGS
# serial number = *
/interface bridge
add arp=proxy-arp comment="LAN Bridge" name=bridge
/interface ethernet
set [ find default-name=ether1 ] comment="WAN Primary   - Modem" speed=\
    100Mbps
set [ find default-name=ether2 ] advertise=1000M-half,1000M-full comment=\
    " - Minion" poe-out=off speed=100Mbps
set [ find default-name=ether3 ] comment=" - Unraid" poe-out=off speed=\
    100Mbps
set [ find default-name=ether4 ] comment=" - SHIELD" poe-out=off speed=\
    100Mbps
set [ find default-name=ether5 ] comment=" - Camera" poe-out=forced-on speed=\
    100Mbps
set [ find default-name=sfp1 ] advertise=1000M-half,1000M-full comment=\
    " - Switch"
/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface vlan
add interface=ether2 name=vlan4000-ether2 vlan-id=4000
add interface=ether3 name=vlan4000-ether3 vlan-id=4000
add interface=ether5 name=vlan4000-ether5 vlan-id=4000
/interface pppoe-client
add add-default-route=yes disabled=no interface=ether1 name=pppoe-outFEED \
    user= **
/interface list
add name=WAN
add name=LAN
/interface lte apn
set [ find default=yes ] ip-type=ipv4
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip pool
add name=dhcp ranges=192.168.88.3-192.168.88.254
add name=dhcp_pool2 ranges=10.10.102.2-10.10.102.254
add name=dhcp_pool3 ranges=10.10.105.2-10.10.105.254
add name=dhcp_pool4 ranges=10.10.113.2-10.10.113.254
add name=dhcp_pool5 ranges=10.10.117.2-10.10.117.254
add name=dhcp_pool6 ranges=10.10.119.2-10.10.119.254
/ip dhcp-server
add address-pool=dhcp interface=bridge lease-time=10m10s name=dhcp1
/queue simple
add name=Minion_QOS packet-marks=Minion_Packets priority=1/1 target=ether2
/queue tree
add limit-at=5M max-limit=7M name="Jelly Out" packet-mark=jellyfinout parent=\
    global
/queue type
add kind=sfq name=sfq-default sfq-perturb=10
/queue simple
add max-limit=10M/100M name=sfq-default queue=sfq-default/sfq-default target=\
    192.168.88.0/24 total-queue=sfq-default
/queue tree
add limit-at=10M max-limit=10M name="Minion Out" packet-mark=Minionout \
    parent=global priority=1 queue=sfq-default
/routing bgp template
set default as=65530 disabled=no name=default output.network=bgp-networks
/routing ospf instance
add in-filter-chain=ospf-in name=default-v2 out-filter-chain=ospf-out
/routing ospf area
add instance=default-v2 name=backbone-v2
/routing table
add fib name=""
/user group
set full policy="local,telnet,ssh,ftp,reboot,read,write,policy,test,winbox,pas\
    sword,web,sniff,sensitive,api,romon,dude,tikapp,rest-api"
add name=sniffer policy="ssh,read,!local,!telnet,!ftp,!reboot,!write,!policy,!\
    test,!winbox,!password,!web,!sniff,!sensitive,!api,!romon,!dude,!tikapp,!r\
    est-api"
/interface bridge port
add bridge=bridge ingress-filtering=no interface=ether2
add bridge=bridge ingress-filtering=no interface=ether3
add bridge=bridge ingress-filtering=no interface=ether4
add bridge=bridge ingress-filtering=no interface=ether5
add bridge=bridge ingress-filtering=no interface=sfp1
/ip neighbor discovery-settings
set discover-interface-list=!dynamic
/ip settings
set rp-filter=strict tcp-syncookies=yes
/ipv6 settings
set disable-ipv6=yes
/interface list member
add interface=ether1 list=WAN
add interface=bridge list=LAN
add interface=pppoe-outFEED list=WAN
add interface=wireguard1 list=LAN
/interface wireguard peers
add allowed-address=10.0.0.8/32 interface=wireguard1 persistent-keepalive=25s \
    public-key="**"
/ip address
add address=192.168.88.1/24 comment="LAN Primary" interface=bridge network=\
    192.168.88.0
add address=192.168.42.1/24 comment="IoT vlan (eth1,2,5)" interface=\
    vlan4000-ether3 network=192.168.42.0
add address=192.168.42.1/24 interface=vlan4000-ether5 network=192.168.42.0
add address=192.168.42.1/24 interface=vlan4000-ether2 network=192.168.42.0
add address=10.0.0.1/24 interface=wireguard1 network=10.0.0.0
add address=192.168.1.2/24 comment="ISP Gateway" interface=ether1 network=\
    192.168.1.0
/ip cloud
set ddns-enabled=yes ddns-update-interval=1m
/ip dhcp-server lease
add address=192.168.88.253 client-id=1:cc:2d:e0:aa:7:6e comment=WiFi \
    mac-address=** server=dhcp1
add address=192.168.88.252 client-id=1:cc:2d:e0:aa:7:70 comment=WiFi \
    mac-address=** server=dhcp1
add address=192.168.88.98 client-id=1:b8:27:eb:cd:dc:1d comment=PiHole \
    mac-address=** server=dhcp1
add address=192.168.88.57 client-id=1:0:4:4b:bd:d:5d comment="Nvidia Shield" \
    mac-address=** server=dhcp1
add address=192.168.88.88 client-id=1:b8:ac:6f:90:e0:f8 comment=Unraid \
    mac-address=** server=dhcp1
add address=192.168.88.8 client-id=1:b4:2e:99:3b:14:e5 comment=Minion \
    mac-address=** server=dhcp1
add address=192.168.88.125 comment=HomeAssistant mac-address=\
    ** server=dhcp1
add address=192.168.88.128 client-id=1:74:4d:28:75:6e:30 comment=Switch \
    mac-address=** server=dhcp1
add address=192.168.88.38 client-id=1:94:53:30:3b:99:9c comment=LaserPrinter \
    mac-address=** server=dhcp1
add address=192.168.88.10 client-id=1:52:54:0:52:63:75 comment=macOS \
    mac-address=** server=dhcp1
add address=192.168.88.20 comment="3D Printer" mac-address=** \
    server=dhcp1
add address=192.168.88.95 client-id=1:2c:44:fd:c1:2e:c8 comment=\
    "Color Printer" mac-address=** server=dhcp1
add address=192.168.88.19 client-id=1:b8:ac:6f:90:e1:0 comment=R710 \
    mac-address=** server=dhcp1
add address=192.168.88.4 client-id=1:ca:37:29:9:d8:a7 comment="Thanos Phone" \
    mac-address=** server=dhcp1
add address=192.168.88.11 client-id=1:30:a9:de:c3:52:bc comment=TV \
    mac-address=** server=dhcp1
add address=192.168.88.3 comment="Nintendo Switch" mac-address=\
    ** server=dhcp1
add address=192.168.88.9 client-id=1:8:ed:ed:5d:c6:8e comment=\
    "Dahua (camera)" mac-address=** server=dhcp1
add address=192.168.88.22 client-id=1:52:54:0:3a:7b:82 mac-address=\
    ** server=dhcp1
add address=192.168.88.141 client-id=1:50:1e:2d:3f:50:ba comment=Anthem \
    mac-address=** server=dhcp1
/ip dhcp-server network
add address=192.168.88.0/24 dns-server=192.168.88.98 gateway=192.168.88.1 \
    netmask=24
/ip dns
set allow-remote-requests=yes cache-max-ttl=10m cache-size=10240KiB servers=\
    192.168.88.98
/ip firewall address-list
add address=192.168.88.2-192.168.88.254 list=allowed-to-router
add address=192.168.88.98 list=Pihole
/ip firewall filter
add action=fasttrack-connection chain=forward connection-state=\
    established,related hw-offload=yes
add action=accept chain=forward comment=\
    "Accept established,related,untracked" connection-state=\
    established,related,untracked
add action=accept chain=input comment="Accept WireGuard" dst-port=13231 \
   log=yes log-prefix=WG: protocol=udp
    add action=accept chain=forward comment="Accept WireGuard"  \
    in-interface=wireguard1 log=yes log-prefix=WG:
add action=accept chain=input comment="Allow traffic from LAN" in-interface=\
    bridge 
add action=add-src-to-address-list address-list=Artillery-blacklist \
    address-list-timeout=1d chain=input comment="Artillery Blacklist TCP" \
    connection-state=new dst-port=\
    1433,8080,21,5060,5061,5900,110,1723,1337,10000,5800,44443,16993,8291,23 \
    in-interface-list=WAN log=yes log-prefix="Artillery-blacklist TCP" \
    protocol=tcp src-address-list=!whitelist tcp-flags=""
add action=add-src-to-address-list address-list=Artillery-blacklist \
    address-list-timeout=1d chain=input comment="Artillery Blacklist UPD" \
    dst-port=123,5060,5061,3478,8291,23,25,53 in-interface-list=WAN log=yes \
    log-prefix="Artillery-blacklist UDP" protocol=udp src-address-list=\
    !whitelist
add action=drop chain=input comment="Drop Artillery Blacklist input" \
    in-interface-list=WAN src-address-list=Artillery-blacklist
add action=drop chain=forward comment="Drop Artillery Blacklist Forward" \
    in-interface-list=WAN src-address-list=Artillery-blacklist
add action=accept chain=forward comment="Accept LAN >>> WAN" disabled=yes \
    out-interface=ether1 src-address=192.168.88.0/24
add action=drop chain=forward comment="drop all from WAN not DSTNATed" \
    connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=accept chain=input comment="Accept to Router" in-interface=bridge
add action=accept chain=input comment="Accept ICMP" protocol=icmp
add action=accept chain=input connection-state=established disabled=yes
add action=accept chain=input comment="accept local loopback (for CAPsMAN)" \
    dst-address=127.0.0.1
add action=drop chain=forward comment="Drop invalid" connection-state=invalid
add action=drop chain=input
add action=drop chain=input comment="Drop Blacklisted Hosts through Router" \
    in-interface-list=WAN src-address-list=Artillery-blacklist
add action=drop chain=forward comment="Drop Blacklisted Hosts through Router" \
    in-interface-list=WAN src-address-list=Artillery-blacklist
add action=jump chain=forward comment="SYN Flood protect FORWARD" \
    connection-state=new jump-target=syn-attack protocol=tcp tcp-flags=syn
add action=jump chain=input comment="SYN Flood protect INPUT" \
    connection-state=new jump-target=syn-attack protocol=tcp tcp-flags=syn
add action=accept chain=syn-attack connection-state=new limit=400,5:packet \
    protocol=tcp tcp-flags=syn
add action=drop chain=syn-attack connection-state=new protocol=tcp tcp-flags=\
    syn
add action=drop chain=input protocol=tcp tcp-flags=syn
/ip firewall mangle
add action=mark-packet chain=forward comment=jellyfin_rx_mark \
    new-packet-mark=jellyfinout passthrough=yes src-address=192.168.88.88
add action=mark-packet chain=forward comment=Minion_rx_mark new-packet-mark=\
    Minionout passthrough=yes src-address=192.168.88.8
/ip firewall nat
add action=masquerade chain=srcnat comment="LAN - NAT (towards modem)" \
    out-interface=ether1
add action=masquerade chain=srcnat comment="LAN - NAT (towards web)" \
    out-interface=pppoe-outFEED
add action=dst-nat chain=dstnat comment=\
    "Pihole - run any udp traffic (except Pihole) through Pihole" \
    dst-address=!192.168.88.98 dst-port=53 in-interface=bridge protocol=udp \
    src-address=!192.168.88.98 to-addresses=!192.168.88.98
add action=dst-nat chain=dstnat comment=\
    "Pihole - run any tcp traffic (except Pihole) through Pihole" \
    dst-address=!192.168.88.98 dst-port=53 in-interface=bridge protocol=tcp \
    src-address=!192.168.88.98 to-addresses=!192.168.88.98
add action=masquerade chain=srcnat comment=Pihole disabled=yes dst-address=\
    192.168.88.98 dst-port=53 protocol=udp src-address=192.168.88.0/24
add action=masquerade chain=srcnat comment=Pihole disabled=yes dst-address=\
    192.168.88.98 dst-port=53 protocol=tcp src-address=192.168.88.0/24
add action=dst-nat chain=dstnat dst-port=443 in-interface=pppoe-outFEED protocol=tcp to-addresses=\
    192.168.88.88 to-ports=1444
add action=dst-nat chain=dstnat dst-port=443 in-interface=pppoe-outFEED protocol=udp to-addresses=\
    192.168.88.88 to-ports=1444
add action=dst-nat chain=dstnat 
/ip firewall raw
add action=drop chain=prerouting in-interface-list=WAN src-address-list=\
    Artillery-blacklist
add action=drop chain=prerouting comment=\
    "Blocks dns request udp/53 traffic from outside" dst-port=53 \
    in-interface-list=WAN protocol=udp
/ip route
add comment="192.168.1.254   ....modem router  ISP" disabled=yes \
    distance=5 dst-address=0.0.0.0/0 gateway=192.168.1.254 pref-src="" \
    routing-table=main scope=30 suppress-hw-offload=no target-scope=10
add disabled=no distance=1 dst-address=0.0.0.0/0 gateway=pppoe-outFEED \
    pref-src="" routing-table=main scope=30 suppress-hw-offload=no \
    target-scope=10
/ip service
set telnet disabled=yes
set ftp disabled=yes port=2121
set www disabled=yes port=8081
set ssh disabled=yes
set www-ssl disabled=no tls-version=only-1.2
set api disabled=yes
set api-ssl disabled=yes
/ip ssh
set forwarding-enabled=remote strong-crypto=yes
/ip upnp interfaces
add interface=ether1 type=external
add interface=bridge type=internal
/system clock
set time-zone-name=Europe/Athens
/system identity
set name="hex PoE"
/system package update
set channel=development

Posted: **Mon Sep 27, 2021 11:23 pm**

It looks like you have changed some rules from the defaults. Some of the default rules are configured to use the interface lists LAN and WAN instead of hardcoding a single interface. You have changed all of your firewall rules to use hardcoded "ether1" instead of interface list WAN and hardcoded "bridge" instead of LAN. This hardcoded setup only works as long as you only have a single LAN port and a single WAN port. In your case, you now have two LAN ports, bridge and wireguard1, so you should rethink this configuration.

Posted: **Tue Sep 28, 2021 12:28 am**

It looks like you have changed some rules from the defaults. Some of the default rules are configured to use the interface lists LAN and WAN instead of hardcoding a single interface. You have changed all of your firewall rules to use hardcoded "ether1" instead of interface list WAN and hardcoded "bridge" instead of LAN. This hardcoded setup only works as long as you only have a single LAN port and a single WAN port. In your case, you now have two LAN ports, bridge and wireguard1, so you should rethink this configuration.

Not sure I'm following here- I swapped any rules with in/out.interface=ether1 to in/out.interface list=WAN and any of those with in/out.interface=bridge to in/out.interface list=LAN. No firewall rule appears to be "hardcoded" at the moment, and I attempted to disable the interface wireguard1 from the LAN list for troubleshooting purposes.. End result was the same as previous post.
Thanks for your patience.

Posted: **Tue Sep 28, 2021 12:55 am**

I strongly suspect the problem is in your firewall rules. Some of your rules don't make any sense. At one point you have a drop all rule on the input chain, then after that you have more input chain rules that will never be matched because everything will hit that drop all rule instead.

Make a terminal window that is big enough and run:

/system default-configuration script print

That will print the default configuration including the default firewall. Take the default ip firewall and ip firewall nat rules and copy and paste them into your router, then disable or delete the rules that you have in filter, NAT, mangle, and raw tabs. Then add an input chain rule to allow udp to 13231 to that. The MikroTik default firewall should just plain work, with the addition of the UDP 13231 rule and adding the wireguard1 interface to the LAN interface list.

Posted: **Fri Oct 01, 2021 2:51 pm**

This should be a thread in either Ros7 beta or beginner or general.
Not troubleshooting your config. Specific questions about the wireguard implementation that may need explaining are fine but otherwise just clogs up a good reference document into a mess.

Posted: **Tue Oct 05, 2021 10:52 pm**

Hello Folks,

Since this is my first post on this forum, prior to ask about things, I'd like to say HI to you.

I am lacking some knownledge and I'd like to ask you for a help and understanding my case. I prepared small schematic (sorry about performance) of structure of my network. That's first.

I am trying to get Wireguard working on my mt, but no luck. I tried all suggestions here and on yt posted but no luck.

Back in the days, when I managed old router (before mt) I just had to port forward, to my server with wireguard and all was fine. I suspect now is probably the same case.

Can you please give me some hints guys?

BR

Posted: **Wed Oct 06, 2021 2:09 pm**

Not here, start a new thread and I will have a look, this thread is for a reference document not individual issues.

Posted: **Sat Dec 04, 2021 10:53 am**

Server Router Key points:

1. The wireguard is a service on the router and thus one has to allow the initial unencrypted traffic to the router via the INPUT CHAIN, which entails the listening port, protocol UDP, interface (coming from) the wan. With a road warrior one cannot narrow it down further by source address. As stated already this needs to be right after the input chain default firewall rules (like after accept ICMP ping) and before any drop rules etc....

So what happens is that the client traffic will hit the internet, hit the server router and then be directed to the wireguard service. If you log this rule, you should get basically a one log entry if successful. The tunnel will be negotiated and established. Once that is done, the client will be able to travel through the tunnel to the wireguard interface. The traffic will be routed out the available main table routing already in place at the server router.

[2. Ensure one puts an IP Route on the MT Server Router that will direct return traffic from the internet back through the wireguard tunnel to the client device. Therefore the destination address is the lan subnet of the client device or the IP of the client device) and the gateway is the wireguard interface

Thank you so much!. I wanted to access my home network clients from outside.

Sticking points for me, were:
1. Stupidly forgetting to assign an ip address to wireguard interface in IP>Addresses
2. Add the route like you said, destination was the subnet of the wireguard ip, gateway was the wireguard interface name, not ip. (ie. put 'wireguard1' or whatever your wireguard interfaces name is in the gateway section
3. Allowing traffic to be forwarded from the wireguard interface to the local lan bridge and allowing traffic to flow from the wireguard interface to my internet connection interface

Posted: **Tue Dec 21, 2021 2:45 pm**

See my simplified double-NAT iOS configuration article, based on mducharme's configuration.

Posted: **Tue Dec 21, 2021 6:03 pm**

I like the clean approach you had in the top of the post, easy to read/understand.

You may have not noticed my post and diagram at #6 that already cover your scenario. Both my wireguard routers ( the server [rb450Gx4] behind the ccr1009, and the client [RB4011] behind the ISPs modem router ). The main difference is that I do not use IP addresses for my wireguard, I only use the interface itself and a mix of rules.
The outcome is that I have to make an additional route etc......... both worth equally well.

Posted: **Tue Dec 21, 2021 9:08 pm**

You may have not noticed my post and diagram at #6 that already cover your scenario.

I saw it, but I couldn't map the diagram to running RouterOS commands. Thus my triumphant post at having worked out the solution from the top post and other relevant examples and docs.

Posted: **Sat Dec 25, 2021 3:47 am**

I've got a strange problem. I'm trying to do a client/server model with wireguard. In the "server" router, I have the peers added like this

/interface wireguard peers
add allowed-address=0.0.0.0/0 interface=awesomeguard public-key=PUBLIC_KEY_OF_CLIENT_1

This works perfectly if there is only one client. As soon as I add another peer, whole thing goes down. Handshake fails for both clients. The thing to note here is my clients don't have static IPs and they are behind NATs in their ISPs. So I can't set endpoint address in peers. I thought the different public-keys of different clients would be enough to connect multiple clients. But it doesn't seem so. All devices are running routeros 7.1.1. Is this a bug in routeros's wireguard implementation? Of am I doing something wrong? All devices has ip firewall rules empty. So its not firewall messing with anything either.

Any idea guys?

Posted: **Sat Dec 25, 2021 4:14 am**

I've got a strange problem. I'm trying to do a client/server model with wireguard. In the "server" router, I have the peers added like this
Code: Select all
/interface wireguard peers
add allowed-address=0.0.0.0/0 interface=awesomeguard public-key=PUBLIC_KEY_OF_CLIENT_1

This is wrong - if you look at the server configuration above in the very top post, you see that the peers under /interface wireguard peers each have an allowed address that is their wireguard IP address /32. Allowed-address=0.0.0.0/0 will not work on the server if it has multiple clients.

Posted: **Sat Dec 25, 2021 4:32 am**

That difference required a number of changes to be suitable for my case.
Code: Select all
/ip route
add dst-address=98.51.100.2 gateway=wg1
add dst-address=98.51.100.3 gateway=wg1

Those two routes are unnecessary as the wireguard server device already has an IP on that /24 subnet and so a connected route will automatically exist for the entire /24 that will cover those two /32's.

Posted: **Sat Dec 25, 2021 5:39 pm**

I've got a strange problem. I'm trying to do a client/server model with wireguard. In the "server" router, I have the peers added like this
Code: Select all
/interface wireguard peers
add allowed-address=0.0.0.0/0 interface=awesomeguard public-key=PUBLIC_KEY_OF_CLIENT_1
This is wrong - if you look at the server configuration above in the very top post, you see that the peers under /interface wireguard peers each have an allowed address that is their wireguard IP address /32. Allowed-address=0.0.0.0/0 will not work on the server if it has multiple clients.

Thank you very much. This was my problem. I changed allowed address to 10.x.x.2/32, 10.x.x.3/32 etc... in adding peers and now all client can connect and its all working nicely

Posted: **Sun Dec 26, 2021 12:22 pm**

Is it just me or is it impossible to also add a "pre-shared" key ? (as an extra layer of post-quantum protection

Whatever I place in that field, I'm always getting "invalid preshared key (6)"
Winbox, CLI , does not matter.
I've tried disabling my peer before adapting the value, no luck.

Does anyone ever tried it ??
Running 7.2rc1

Posted: **Mon Dec 27, 2021 12:12 am**

Whatever I place in that field, I'm always getting "invalid preshared key (6)"

You probably need to go to a Linux box and run: wg genpsk

And use that key. Most likely it does not accept any string as a preshared key.

Posted: **Mon Dec 27, 2021 1:15 am**

it does not accept any string as a preshared key.

It needs to be exactly thirty-two base-64 encoded octets. Another alternative to using the wg command line tool, therefore, is something like this:

$ dd if=/dev/random bs=32 count=1 | base64 | pbcopy

You might not have a "bas64" filter installed, but if not, they're pretty much available on all platforms.

The final part of that command is macOS-specific. Other platforms have tools for taking piped-in data and sending it to the clipboard so that you can paste it into a command like:

$ /interface/wireguard/peers/set 0 preshared-key="aNSNRaM8ASUncjCCNlrpr0SAaqRlqyuO4LnZLZ4fWCk="

BUT as of 7.1.1., this parameter appears to be completely ignored! As long as you either pass nothing or pass a correctly-formatted value, the clients will connect, regardless of the value on the client side. Sigh.

Posted: **Mon Dec 27, 2021 1:48 am**

Those two routes are unnecessary as the wireguard server device already has an IP on that /24 subnet

Well spotted! I've tested that here, and with that success, removed those commands from my post.

Posted: **Mon Dec 27, 2021 9:17 pm**

Tangent I dont understand the source nat angle of your config.
What is being accomplished or in other words I dont understand the use case.

Case 1 - Admin wants to configure router remotely (aka via smartphone)
Case 2 - Admin wants client or client subnet coming in (via smartphone or another router acting as a wireguard client) and to be fully routed out Server Router internet
Case 3 - Admn wants client or client subnet coming in, and accessing other LAN subnets/devices etc on the Server Router LAN.
Case 4 - ?????

Having the WG server behind an ISP provided modem router is not all that different and really entails one extra thing!
ISP Modem Router has to port forward the WG listening port to the Server Router

So that being stated then for
Case 1 - WG interface needs to be added as LAN interface for input chain access (or base or managment interface as LAN users should only have DNS/NTP access to the router) OR
one could make another rule in-interface=wg interface accept specifically for that traffic. DONE!

Case 2 - No changes need be made if the default rule set is in place for the forward chain as the only traffic blocked is WAN to LAN not dst natted. If one has a drop all rule in place at the end then typically has a LAN to WAN rule to allow internet traffic and thus one adds the WG interface as a member to the LAN interface list, or one can make a specific forwarding rule for the wg interface.

Case 3 - The same holds true for LAN to LAN traffic, if the default rule is in place the router will find a route from the wg interface to the desired lan subnet address. If the drop all rule is in place then the admin will have to make a specific wg-interface to LAN rule.

Of note, no IP addresses need to be assigned to the WG interface and no source nat required.

Posted: **Mon Dec 27, 2021 10:50 pm**

Case 1...Case 3

These cases are what I meant by "trapping my VPN clients within the private VPN net" above: without the src-nat rule, a WireGuard client could only access LAN resources. If that's all I wanted, then yes, I could do without the src-nat rule.

Case 2...the default rule set is in place for the forward chain

Of your listed options, this is closest to my use case: anyone outside the home LAN who can provide valid WireGuard credentials gets to use LAN resources and also re-emerge onto the public Internet as if they were on the home LAN.

It's been long enough since I set this CRS328 up that I can no longer remember if it came with a default firewall rule set. If it did, I nuked it in the interest of making it a smart switch, as I think this class of device is best used. (If I'd wanted a router, I'd have bought a router!)

I've configured it to:

be my home WireGuard gateway
provide IGMP and DHCP snooping
provide LAN NTP service advertised by the DHCP server
be the preferred RSTP root, it being the biggest of my switches, the most central, and the one on the best UPS

Internet firewalling and routing I leave to the Internet gateway. There isn't any explicit intra-LAN routing, only the implicit sort pointed out by mducharme. After taking his point on the default WireGuard route above, I no longer have any static routes configured, and I certainly don't have anything clever like inter-VLAN routing, OSPF, BGP... Security of the CRS itself is done by disabling all unencrypted services, use of long random passwords/keys, etc.

After stripping the redundant and privacy-sensitive stuff out of the configuration, it's pretty simple:

/interface bridge
add dhcp-snooping=yes igmp-snooping=yes igmp-version=3 multicast-querier=yes \
    name=bridge1 priority=0x1000    # "smart switch" config
/interface bridge port
add bridge=bridge1 ingress-filtering=no interface=ether1 \
    unknown-multicast-flood=no      # same for all ports
/interface wireguard ...            # as above
/interface wireguard peers ...      # as above
/ip address add interface=wg1 ...   # as above
/ip firewall nat chain=srcnat ...   # as above

So, given that, how do I get rid of the double-NAT? I can see how, if I were using a MikroTik router as the Internet border gateway, but behind it like this?

Posted: **Mon Dec 27, 2021 11:32 pm**

Not sure, as not using mudcharmes methods (by using IP addresses) as he states routes are mostly automatically created.
I prefer not to use Ip addresses thus far for WG interface and thus I have to create the route
dst-address=smartphone IP or wg client subnet interface=WG interface table=main.

Then any return traffic from LAn device or internet on the server router, will get routed appropriately back through the tunnel to the clients.
At least thats how it works for me.
Since the WG interface is not part any LAN and depending upon rules in the input/forward chains I may have to make some firewall rules to permit traffic.

Posted: **Tue Dec 28, 2021 12:01 am**

So, given that, how do I get rid of the double-NAT? I can see how, if I were using a MikroTik router as the Internet border gateway, but behind it like this?

The only way to avoid double NAT in this case is to take your actual gateway to the internet (that the MikroTik is behind) and add a static route to it for the wireguard subnet, with the MikroTik IP as the next hop address.

Posted: **Tue Dec 28, 2021 1:20 am**

add a static route to it for the wireguard subnet, with the MikroTik IP as the next hop address.

That's a good idea. Alas, this gateway doesn't have that feature.

Ultimately, I think I'm going to have to scrape together the courage to swap things around to put a MT box in the gateway role.

Posted: **Tue Dec 28, 2021 1:34 am**

That's a good idea. Alas, this gateway doesn't have that feature.

Yeah, if the gateway doesn't have that feature, you're going to have to use double NAT, unless you put it in bridge mode and then the MikroTik becomes the gateway.

Posted: **Tue Dec 28, 2021 3:47 pm**

How is it double NAT?
With an ISP router before an MT router (in my case), the ISP router port forwards the traffic to MT router so that the traffic arrives at the router, AS IF it was coming from the internet.
Then with an input chain rule the traffic hits the second router on the INPUT CHAIN. No double NAT. (which would occur if then the MT had to port forward that traffic to a server).

What am I missing here (use case not understanding)?

Posted: **Tue Dec 28, 2021 8:16 pm**

How is it double NAT?

Because the devices behind the MikroTik are using double NAT to get online, regardless of whether Wireguard is there or not. One router behind another, both doing NAT, is double NAT.

He may also have some devices behind the ISP router and some behind the MikroTik, and in that case, hosts behind the ISP router would not be able to send packets to hosts behind the MikroTik due to the double NAT.

Posted: **Wed Dec 29, 2021 2:04 am**

What you say makes no sense.
There is no double NAT to get online.
Any user behind the second router goes out the the secondary router and out the primary router.
The return traffic is routed not natted back to the originator. Sure there is some natting involved but its not like two sets of DST NAT to get through to a server.

Posted: **Wed Dec 29, 2021 3:42 am**

Any user behind the second router goes out the the secondary router and out the primary router.

Yes, with two source NAT translations: from TEST-NET-2 in my example to TEST-NET-1, and from there to the public IP my home Internet provider rents to me.

Remember, there is no explicit routing in this configuration. The only way TEST-NET-1 knows how to get traffic back to a client on TEST-NET-2 is to send it to the NATted IP in TEST-NET-1, being my internal CRS328's IP. It sees that it NATted that traffic on behalf of its wg1 interface on TEST-NET-2, stripping the second NAT layer, the first being at my Internet gateway.

Posted: **Wed Dec 29, 2021 3:45 am**

Any user behind the second router goes out the the secondary router and out the primary router.
The return traffic is routed not natted back to the originator. Sure there is some natting involved but its not like two sets of DST NAT to get through to a server.

The primary router isn't a MikroTik and doesn't have the ability to add static routes as he explained.

Imagine this case:

Internet <--> Router 1 internal subnet (192.168.1.0/24> <--> Router 2 internal subnet (192.168.2.0/24)

Router 1 does not have a route in its routing table to get to 192.168.2.0/24, and it cannot be added. So when a device on 192.168.2.0/24 sends a packet out to the internet, if it does not NAT the packet on Router 2, Router 1 will receive the packet from, say, 192.168.2.254 and will NAT it and send it out. When the reply packet comes back from the Internet, Router 1 sees that it is supposed to go to 192.168.2.254 but doesn't have a route for that subnet and will send it out the default gateway, back to the Internet, leaking it out the WAN port. If on the other hand you do NAT on both routers, then the packet from 192.168.2.254 will be NAT'ed through the IP that Router 2 has on Router 1's subnet (say, 192.168.1.254) and then this can go to the internet and the response will come back.

So yes, this is double NAT, and you can turn off the double NAT in this case if you are willing to have zero internet connectivity from behind Router 2. But I think he wants clients behind both routers to be able to get online.

And it is not two sets of DST-NAT, only one set of DST-NAT, but two levels of masquerade (on R1 and R2), so double-NAT on src-nat.

Posted: **Wed Dec 29, 2021 4:37 am**

Hmmm Let me look at my setup........
CLIENT ROUTER.............
I have another router that is ISP controlled before my RB4011 router (it being the client router)
The ISP router has no route capabilities .................... everything works.

SERVER ROUTER
Now before my RB450Gx4 is the CCR1009 router.
I have no special routes for this device..................ahh wait.........
I do have on the CCR1009
A route
dst-address=subnet of client router subnet gateway=LANIP of RBG450B (also its wanip)

Required to ensure returning traffic from the internet makes its way back to the tunnel....
much like the RB450G has
dst-address=subnet of client router subnet gateway=WG interface.

So if the REVERSE was true, and the ISP router was in front of the WG server MT router, how would one ensure
return internet traffic made it back to the tunnel ?????????????
Considering the only thing possible on the ISP router is port forwarding.........
So what your saying is that one would have to --- on the MT router.

add chain=src-nat action=src-nat source-address=subnet of client router to-address=WANIP of MT router out-interface=etherWANport
add chain=src-nat action=src-nat source-address=ipofIPHONE to-address=WANIP of MT router out-interface=etherWANport

Posted: **Wed Dec 29, 2021 4:55 am**

So what your saying is that one would have to --- on the MT router.

add chain=src-nat action=src-nat source-address=subnet of client router to-address=WANIP of MT router out-interface=etherWANport
add chain=src-nat action=src-nat source-address=ipofIPHONE to-address=WANIP of MT router out-interface=etherWANport

Correct, because without the ability to add static routes to the ISP controlled router, the only choice is double NAT in this case. You have to src-nat or masquerade on the internal router too.

Posted: **Wed Dec 29, 2021 3:57 pm**

So what your saying is that one would have to --- on the MT router.

add chain=src-nat action=src-nat source-address=subnet of client router to-address=WANIP of MT router out-interface=etherWANport
add chain=src-nat action=src-nat source-address=ipofIPHONE to-address=WANIP of MT router out-interface=etherWANport
Correct, because without the ability to add static routes to the ISP controlled router, the only choice is double NAT in this case. You have to src-nat or masquerade on the internal router too.

Agree with part blue, still disagree with orange bit.

I described the scenario where all can be accomplished with routes and as discussed source nat. Not sure why you insist on masquerade unless there is something wrong with my source NAT rules, (consider the wanip is fixed, src-nat action is more appropriate). In any case I have not seen the need for double NAT as you speak. Remember I consider the term double NAT as it applies ONLY to reaching a server on a second tier router. DST-NAT to the first router and then DST-NAT again to the server on the internal Router.
So please clarify, because it seems it only may be terminology separating us.

Posted: **Wed Dec 29, 2021 11:40 pm**

Agree with part blue

The ISP modem (not running RouterOS) has some analog of what RouterOS calls a "srcnat" rule. That's one NAT layer, and the RouterOS rule we mutually agree is needed in this condition is a second NAT layer. That's all it takes to constitute double-NAT.

I consider the term double NAT as it applies ONLY to reaching a server on a second tier router.

That is one reason double-NAT is a creator of problems, but it is not the only one. There are several client-side protocols that fail when run through a double-NAT layer as well. My link above offered UPnP as a good example: each NAT router in my setup could support UPnP's Internet Gateway Device port-mapping feature, but the inner one isn't going to contact the outer one to complete the requested action, so it fails. UPnP IGD's more secure replacements NAT-PMP and PCP also have this problem.

There are several tremendously clever NAT traversal methods that can avoid this class of problem. Such methods wouldn't be needed if 1) UPnP's initial security flaws didn't taint the waters, leading many to blanket-ban all tech of that sort; and 2) double-NAT and its hairy big brother CGNAT didn't exist.

Notice how much of the language in that NAT traversal doc is about "clients" rather than "servers."

I should point out that I have no specific reason to worry about double-NAT in my setup. It could be that all of my applications do use these clever NAT traversal techniques now, so it no longer matters for my actual use cases. I just thought it was worth warning people that it could cause some protocols to fail.

Posted: **Wed Dec 29, 2021 11:57 pm**

Understood, I am not trained and very little experience so my frame of reference is limited, and that is why my obstinance was well founded and bounded by lack of knowledge.
That is why I defined double NAT as I understood just to ensure that we were discussing definitions and not config, which is the case.
Much thanks for your patience.

Posted: **Thu Mar 03, 2022 11:40 pm**

I realize this thread is a little old, but I have question. I have successfully configured Wireguard on my Mikrotik router, and can connect from my laptop when outside my network. I can use remote desktop to access machines on my LAN via IP address, but not via name. The static DNS table has entries, and these resolve correctly from the LAN. Is it possible to use name resolution from a Wireguard client to a Mikrotik router? Hope this made sense!

Posted: **Fri Mar 04, 2022 12:05 am**

In config of your laptop, specify same DNS server as at home.
Must likely your router ?

Posted: **Fri Mar 04, 2022 12:12 am**

The static DNS table has entries, and these resolve correctly from the LAN.

That's likely because you have a DHCP server somewhere that's sending out the router's IP as a DNS server. The thing is, there is no DHCP over WireGuard.

If you have access to the client-side configuration file, you can manually add something like "DNS = 192.168.88.1" to it in the "[Interface]" section to override your local DNS server with that of the router when that WG conn comes up. WG GUIs generally don't expose this parameter, and I can't see that it's documented on the wireguard.com site, but it's legal.

Posted: **Fri Mar 04, 2022 12:15 am**

It's standard option in Windows client

Posted: **Fri Mar 04, 2022 12:22 am**

It's standard option in Windows client

That's the configuration file I spoke of. What I'm contrasting that against is the clicky-poky GUI dialog behind it. Is there a DNS field there, or do you have to edit that INI file you show to get this feature?

I mean, it's nice that they present an editable item for you rather than leave it out entirely, so you don't have to rely on your Google-fu to discover it on the Internet, but what I want is to not have to edit the INI file at all. That's what GUIs are for.

Posted: **Fri Mar 04, 2022 11:45 pm**

I saw that when configuring the Windows client, and have tried the router's IP (which works internally), and also the Wireguard interface address. When I execute an nslookup on the Wireguard attached client, it shows whatever DNS server I have specified, but no results. I have ACLs in the firewall to allow traffic to flow between the Wireguard and LAN subnets, which I believe are working, since I can successfully remote desktop via the ip address.

Posted: **Fri Mar 04, 2022 11:51 pm**

Dirty option
Hardcode the names in the host file of your client.

That will always work

Posted: **Fri Mar 04, 2022 11:52 pm**

When I execute an nslookup on the Wireguard attached client…

Did you give "server 1.2.3.4" before executing the query to force nslookup to use your WG server's DNS?

This is why I prefer dig over nslookup: you can't neglect to say which DNS server to use: "dig my-local-name @1.2.3.4".

I have ACLs in the firewall

Now that you say that, I'd want to see Torch results showing that the DNS query packets are getting through to the DNS server, and that the DNS replies are indeed exiting the WAN interface.

Posted: **Sat Mar 05, 2022 2:13 pm**

Good point. I've been mostly concerned with resolving names on the LAN, but just tested and realized I am not resolving addresses on the WAN either. I have used packet capturing software before, but Torch is a little different. I will play around with it and see if I can determine where the packets get lost.

Posted: **Sat Mar 05, 2022 3:30 pm**

Good point. I've been mostly concerned with resolving names on the LAN, but just tested and realized I am not resolving addresses on the WAN either. I have used packet capturing software before, but Torch is a little different. I will play around with it and see if I can determine where the packets get lost.

LAN and WAN have a lot of differences ,,, so how could you think of its nothing worth to change WAN address . To be more specific which software do u used to capturing packets

Posted: **Mon Mar 07, 2022 6:33 pm**

Good point. I've been mostly concerned with resolving names on the LAN, but just tested and realized I am not resolving addresses on the WAN either. I have used packet capturing software before, but Torch is a little different. I will play around with it and see if I can determine where the packets get lost.
LAN and WAN have a lot of differences ,,, so how could you think of its nothing worth to change WAN address . To be more specific which software do u used to capturing packets

I probably didn't state this correctly, Originally, I thought the client was just not resolving names on the LAN . Then I realized that WAN names are not being resolved either, which leads me to believe that DNS requests are disappearing somewhere in the Mikrotik.

Posted: **Sun Mar 27, 2022 9:08 pm**

Hi guys, not sure if i should open a new topic, as i have almost the same issue.

MT1 - CHR on VDS (firewall is almost totally open)
MT2 - 4011 at home directly connected to internet (static/white ip)
Client1 - wireguard on my notebook behind the MT2. (windows firewall is turned off for both public and private networks for testing purposes)

First i was trying to establish connection between MT1 and MT2 - looks like handshake was successful, but i wasn't able to ping both MTs - request timeout.
Next i added Client1 (wireguard client on windows provides a bit more logs for debugging). Again - no luck, handshake, but no ping.

Then i read in this topic, that if there's multiple peers to one wg instances (that's my case - MT1 one wg instance + two peers) it's required to fill in allowed addresses with /32 mask. Tried that as well. No luck. Could be something in CHR broken?

Any help is much appreciated. I've successfully managed to setup working WG on my MT2 (home RB4011) and my friend is able to connect there and get to internet. I just don't get it - smth is wrong with CHR setup, but what exactly

MT1 (CHR)

interface/wireguard print
Flags: X - disabled; R - running 
 0  R name="wg1" mtu=1420 listen-port=13231 private-key="V7AZZUesmrf69lo="  public-key="ooVu2F2H"

interface/wireguard/peers/ print
Flags: X - DISABLED
Columns: INTERFACE, PUBLIC-KEY, ENDPOINT-ADDRESS, ENDPOINT-PORT, ALLOWED-ADDRESS, PERSISTENT-KEEPALIVE
#   INTERFACE           PUBLIC-KEY                                    ENDPOINT-ADDRESS  ENDPOINT-PORT  ALLOWED-ADDRESS  PERSISTENT-KEEPALIVE         
2   wg1                 ZRxKKPZ  <cut>           13231  10.0.0.2/24      25s                 
3   wg1                 q8ivmtH                          13231  10.0.0.3/24      25s                 

/ip/address print 
Flags: X, D - DYNAMIC
Columns: ADDRESS, NETWORK, INTERFACE
#   ADDRESS           NETWORK        INTERFACE         
0   10.0.0.1/32       10.0.0.0       wg1

 ip/firewall/ filter/ print
Flags: X - disabled, I - invalid; D - dynamic 
 0    ;;; block honeypot ssh rdp winbox
      chain=input action=add-src-to-address-list connection-state=new protocol=tcp address-list=Honeypot Hacker address-list-timeout=4w2d 
      in-interface=ether1 dst-port=21,22,23,3389,8291 log=no log-prefix="" 
 1    chain=input action=drop protocol=tcp in-interface=ether1 dst-port=53 
 2    chain=input action=drop protocol=udp in-interface=ether1 dst-port=53

Client1 (Wireguard WIndows):

[Interface]
PrivateKey = CCJwOgnphg
PublicKey = q8ivmtHke1k8WseC3pZLhrXOwPxt5pi3wyEo6znvJ2Q= (copied from GUI)
ListenPort = 13231
Address = 10.0.0.3/32
DNS = 1.1.1.1, 1.0.0.1

[Peer]
PublicKey = ooVu2F2HP
AllowedIPs = 10.0.0.1/32
Endpoint = cut:13231

Posted: **Mon Mar 28, 2022 12:00 am**

Will need to see both MT configs.
/export file=anynameyouwish

viewtopic.php?t=182340 for light reading.

What is missing for much needed clarity is what is the traffic flow you are requiring.
From WWW (laptop) via wireguard tunnel to MT2-home
a. for internet access from Mt2-home remotely?
b. to configure Mt2-home router?
c. to access subnet or server on mt2-home router
d. to access internet but via the CHR device?
e. to configure the CHR device.
f. to access server on VDS

From MT2- HOME
a. access internet from CHR?
b. access servers on VDS?

Step1: Construct your Wireguard Interface subnet.

Lets go with
MT1-chr: /ip address= 10.0.0.1/24 interface=wg-chr
MT2-home: /ip address=10.0.0.2/24 interface=wg-home

Laptop: ADDRESS (from wireguard parameter settings = 10.0.0.3/32
Other: ADDRESS (from wireguard parameter settings = 10.0.0.4/32
Other: ADDRESS (from wireguard parameter settings = 10.0.0.5/32

Step2 Peer Settings.
M2-home
peer1(mt) Allowed IPs= 10.0.0.1/32,
peer2(laptop) Allowed IPs = 10.0.0.3/32,
peer (other etc.) Allowed IPs= 10.0.0.4/32,

MT1-chr
peer - Allowed IPs=10.0.0.0/24, + whatever else needs to be accessed on VDS?

Laptop
peer - allowed IPs=10.0.0.0/24, + whatever else needs to be accessed (MT2-home or VDS) --- >unless 0.0.0.0/0 in which case its the only entry

Other etc,
peer Allowed IPs=10.0.0.0/24 + whatever else needs to be accessed (MT2-home or VDS) --- >unless 0.0.0.0/0 in which case its the only entry

The rest will have to wait for you to fill in the blanks above on Requirements. plus the configs of both MT devices.

Posted: **Mon Mar 28, 2022 8:13 am**

Many thanks for so detailed reply. And i've already read your link - one of the best guides on the net.

I've attached both configs. Now re objectives:

1. I'll have a 3rd MT device in my country house - there's no white IP, and i need to monitor it (it is the only source of network for my old parents, who live there in summer, so it's really vital question). So i'd like to have all three devices to be on one private net.
2. On mt-chr i use l2tp now and it's constantly getting disconnect. It's not critical, though i'd like to have a little bit more smooth user experience.
3. After wireguard connection will be successfully established i will add some routing (lists will be downloaded with help of BGP) to mt-home. So some sites will go through mt-chr and some through mt-home. But this question is out of this topic. All i need now - is just to understand what is wrong, why i cant ping neither of mt's.

Posted: **Sat Apr 23, 2022 5:49 pm**

The "no-internet-access" issue resolves if I configure the android client Allowed Addresses to my LAN subnet instead of 0.0.0.0/0, but I'm still getting the log barrage and I'm not certain that the traffic is properly routed through my pihole.
Your wireguard interface is not in the Interface List called "LAN". Please see the last paragraph of this reply: viewtopic.php?f=23&p=882295#p878732

@mducharme... You write several times, that the WG interface must be in the LAN interface sheet. But this list in itself does nothing, unless it is used in some rules of firewall. To be clear to anyone who doesn't use the default configuration, I think it's fair to say what other than masquerading (i think that masquerading is a MUST) is used by firewall rules to get things with WG done.May be some routing mangle rules and using it in routing table?

Posted: **Sat Apr 23, 2022 6:02 pm**

Your wireguard interface is not in the Interface List called "LAN". Please see the last paragraph of this reply: viewtopic.php?f=23&p=882295#p878732
@mducharme... You write several times, that the WG interface must be in the LAN interface sheet. But this list in itself does nothing, unless it is used in some rules of firewall. To be clear to anyone who doesn't use the default configuration, I think it's fair to say what other than masquerading (i think that masquerading is a MUST) is used by firewall rules to get things with WG done.May be some routing mangle rules and using it in routing table?

The reason to put the wireguard interface on an interface list is too take advantage of existing firewall rules, that is all.
Quite right, that depending upon firewall rules, one may have to add access from remote users exiting the tunnel locally to reach subnets on the local router or use the internet on the local router. Additionally one may need firewall rules to allow local subnets to enter the tunnel to reach remote sites.

This is especially true if you use DROP all rules at the end of the input and forward chains. Hence it may be advantageous to put the WG interface on the interface list............... also for accessing the config remotely etc..........

Concur, the key to having a proper set of IP Routes, is to understand the traffic flows and the relationship with allowed IPs. Remote users coming in need a way to get back through the wireguard tunnel.
dst-address=subnetA(remote) gwy=wireguard table=main.

NOTE that this single IP route suffices for two different streams of traffic.
a. remote users coming to the local router and accessing either the local subnets or local WAN for internet -------- the IP route addresses the return traffic.
b. local users wanting to enter the tunnel and reach subnetA at the remote site --------> the IP route addresses local originated traffic heading outbound.

Where IP routes gets tricky is when you need to direct some users or entire subnets into the tunnel for internet for example .........
Then we need to create a table, another route and route rules etc............

Posted: **Sat Apr 23, 2022 6:09 pm**

To be clear to anyone who doesn't use the default configuration, I think it's fair to say what other than masquerading (i think that masquerading is a MUST) is used by firewall rules to get things with WG done.May be some routing mangle rules and using it in routing table?

No it's not a must.
I don't use masquerading on WG nor mangle rules, nor specific routing tables.

KISS = Keep It Stupid Simple

Posted: **Sat Apr 23, 2022 6:11 pm**

I don't use masquerading on WG

There are good reasons to do so. Not always. Not everyday. But sometimes.

Posted: **Sat Apr 23, 2022 6:13 pm**

I'm not saying there can not be good reasons to do so.
Just indicating it's not a MUST.

Posted: **Sat Apr 23, 2022 6:16 pm**

Many thanks for so detailed reply. And i've already read your link - one of the best guides on the net.

I've attached both configs. Now re objectives:

1. I'll have a 3rd MT device in my country house - there's no white IP, and i need to monitor it (it is the only source of network for my old parents, who live there in summer, so it's really vital question). So i'd like to have all three devices to be on one private net.
2. On mt-chr i use l2tp now and it's constantly getting disconnect. It's not critical, though i'd like to have a little bit more smooth user experience.
3. After wireguard connection will be successfully established i will add some routing (lists will be downloaded with help of BGP) to mt-home. So some sites will go through mt-chr and some through mt-home. But this question is out of this topic. All i need now - is just to understand what is wrong, why i cant ping neither of mt's.

Do you have a schematic or plan......
Assuming the folks home will simply be a client with two different wg tunnels.
WG1 at the old folks home will be the MT CHR
WG2 at the old folks home will be the MT HOME.

Assuming that both CHR and MT home can be SERVERS (reachable public IPs).
The reason to make two different tunnels is that there is no reason to use RELAY if both are reachable!!
If the CHR goes down you can still monitor the old folks home connection from MT HOME
IF MT home goes down assuming you can still access the CHR and monitor the connection to the old folks home.

Assuming CHR is a cloud service or not using your home network/ISP - actually independent.
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Thus you will need the following connectivity
MT folks WG client1 to MT CHR Server WG1
MT folks WG client2 to MT HOME Server WG2

other notes:
- Mobile clients (your laptop, your iphone etc) - each mobile device will ahve two WG clients setup so that you can acccess either one remotely.
- MT HOME to MT CHR - WG3. independent tunnel for whatever you need to do between, them PING etc.........
- At each Server, you can delineate the level of access you have to the MT folks Router and subnets!

Pinging should be simply a matter of setting up the WIREGUARD Addresses and allowed IPs properly.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

In summary, I wouldnt go with the one network philosophy as WG is best suited for site to site work. The key is if both CHR and HOME can be servers.
If so, then dont have one network and dont relay, go direct!!!

Posted: **Sat Apr 23, 2022 6:19 pm**

Yes, masquerading is a case by case basis. In most situations its not required,

There are two cases generally speaking where it is necessary:

(1) For third party VPN services, its is usually mandatory because the OP is given a single IP address by the VPN provider (as if one was going to use an IPHONE). So guess what the allowed IP is on the 3rd party VPN server side................ I can tell you its not all the subnet IPs on the mikrotik.

Hence one has to masquerade the local LANIPs to that given IP............. or the vpn provider wg connection will drop that traffic.

(2) When you have an ISP router or other router in front of your MT Device (and the MT is acting as the SERVER). This unique situation occurs because
a. the MT is acting as the Server - meaning although you dont have a public IP you can at least get the WG port (and protocol) forwarded to your NATTED Router!
b. you are unable to create a static route on the ISP ROUTER or the OTHER ROuter in front of you.

Why is this a problem? Think about it, some remote users come to your MT device to access your local internet.
They come through the tunnel and your firewall rules allow them to access your WAN.
They go out the WAN of your router, and then out the WAN of the ISP of the main router and reach the internet.
THe return traffic hits the FIRST main router and the main router looks at the source address of the traffic, ( the subnet IPs of the remote users that came into the tunnel ).
It says I dont recognize these IPs, they dont belong to any known subnet on my router ( nothing routable ) ---- > traffic dropped.

Solution: SOURCE NAT the incoming remote traffic, exiting the wg tunnel, to the WANIP of the MT device!!
Now the returning traffic from the internet will hit the FIRST MAIN router and the router will look at the source address and say, Oh yeah I recognize that, I have a subnet for that traffic that is routable and sends it to your MT routers WANPORT!! The MT router says oh yeah I have to unsource that Shit, and look here its from subnet A, and there is a route for Subnet A, on the wireguard tunnel and so on.........

Posted: **Fri Jun 24, 2022 10:52 pm**

There is a typo in the first post. The client should use address 192.168.66.2/24, not 192.168.66.3/24, in order to match the peer definition in the RouterOS.

After fixing this, it works perfectly. Unfortunately it seems there are no default logs to give any kind of errors or warnings on RouterOS, which took me a while to spot the typo address.

Posted: **Fri Jul 01, 2022 10:35 pm**

Hi all,

I followed the first post to set up WG in my MT and I can't find the issue on my configuration. I only have 1 Road Warrior, a mobile phone.
Very summarized all seems to be OK when I make a ping from a computer inside the LAN to the phone but fails when I try to make the inverse, though the pings made with the phone to the IP's of the router like the IP of the WG interface or the gateway of the LAN these do work.
Please can you give some light on what could be happen?
Thanks in advance.

Cheers.

Posted: **Sat Jul 02, 2022 12:41 am**

Solved. Discarding I found a rule that was blocking the connection. Sorry.

Regards,

Posted: **Sat Sep 03, 2022 4:34 am**

There is a typo in the first post. The client should use address 192.168.66.2/24, not 192.168.66.3/24, in order to match the peer definition in the RouterOS.

After fixing this, it works perfectly. Unfortunately it seems there are no default logs to give any kind of errors or warnings on RouterOS, which took me a while to spot the typo address.

No typo - I think you missed something, although it might be a bit confusing:

"Example iOS wireguard client config (acts as "second client" above):"

i.e. on the RouterOS end, I configured two clients, and gave the config for the second one as an example, and not the first.

Posted: **Mon Feb 13, 2023 3:57 pm**

Hi,

I've tried following everything from the basic setup https://help.mikrotik.com/docs/display/ROS/WireGuard to the advanced viewtopic.php?t=182340 and I can't figure out how to pass packets through my hEX wireguard interface. Ideally, I'd like my remote peers to be able to connect to the hEX to access the local subnet (10.0.0.0/16), as well as route to the internet (i.e., 0.0.0.0/0). I think I'm getting lost with how the wireguard interface creates a route between its network (172.17.2.0/24) and the LAN (10.0.0.0/16) and whether I need to masquerade the wireguard subnet.

I even disabled all "drop" firewall rules briefly while trying. The firewall rule that accepts packets on the wireguard port (13231) shows packets being received. The best I've been able to accomplish is a handshake, but no pings.

Model RB750Gr2
Current Firmware 7.6
See below for output of /export hide-sensitive file=asdf.txt

Any help would be appreciated!

20230212config.txt

Posted: **Mon Feb 13, 2023 11:40 pm**

I think the main problem is you are a very confused admin.

YOu dont know whether you are coming or going reference to LAN looking subnets.
10.0.2.1/24 network with an IP Pool and a dhcp-server-network, but no IP address and no dhcp server???
On top of that your pool for the bridge dyn was meant for the 10.0.2.x network and not the bridge network of 10.1

Your firewall rules are not in order and are not coordinate/organized of all input chain rules together and all forward chain rules together.
Wiill fix those separately but the other stuff its up to you.

Recommend to get wireguard working you remove anything 10.0.2 related.........

# serial number = "redacted for security"
/ip pool
add name=dhcp-dyn ranges=10.0.2.2-10.0.2.254
add name=dhcp-static ranges=10.0.1.2-10.0.1.199
/ip dhcp-server
add address-pool=dhcp-dyn interface=bridge1 name=defconf
/ip address
add address=10.0.1.1/17 comment=defconf interface=bridge1 network=10.0.0.0
( why do you need 32,000 IP addresses?? your pool is only from .2 to .199)
add address=172.17.2.1/24 interface=wireguard1 network=172.17.2.0
/ip dhcp-server network
add address=10.0.1.0/24 comment=defconf dns-server=\
10.0.1.1,1.1.1.1,4.2.2.1,8.8.4.4 gateway=10.0.1.1 netmask=16
add address=10.0.2.0/24 dns-server=10.0.1.1,1.1.1.1,4.2.2.1,8.8.8.8 gateway=\
10.0.1.1 netmask=16 ntp-server=10.0.1.1

As for firewall rules, here is a cleaner view with whats needed and got rid of the junk you had that is not needed and makes a config bloated and unreadable.
One should understand all the rules used and in this case there are some that you copied and do not understand.

/ip firewall filter
(default rules)
add action=accept chain=input comment="defconf: accept established,related,untracked" \
connection-state=established,related,untracked
add action=drop chain=input comment="Drop invalid connections" \
connection-state=invalid
add action=accept chain=input protocol=icmp
(Admin rules)
add action=accept chain=input comment="allow wireguard" dst-port=13231 protocol=udp
add action=accept chain=forward in-interface=wireguard1 out-interface-list=\
LAN
add action=accept chain=forward in-interface-list=LAN out-interface=\
wireguard1
add action=accept chain=input in-interface=wireguard1
add action=accept chain=forward in-interface=wireguard1 out-interface-list=\
WAN
add action=accept chain=input comment="allow https/sstp" dst-port=443 \
protocol=tcp
add action=accept chain=input comment="From our private LAN" \
in-interface-list=LAN src-address=10.0.0.0/16
add action=drop chain=input comment="defconf: drop all from WAN" \
in-interface-list=WAN
(default rules)
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" \
connection-state=established,related
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
(admin rules)
add action=accept chain=forward in-interface-list=LAN out-interface-list=WAN src-address-list=!offline_devices { Internet for LAN except intranet devices }
add action=accept chain=forward comment="port forwarding" connection-nat-state=dstnat
add action=accept chain=forward in-interface=wireguard1 out-interface-list=LAN { allow remote user to access LAN }
add action=drop chain=forward comment="Drop all else"
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface-list=WAN
add action=masquerade chain=srcnat comment="masq. vpn traffic" \ { REMOVE NOT REQUIRED }
out-interface-list=WAN src-address=172.17.2.0/24

Posted: **Mon Feb 13, 2023 11:42 pm**

You dont need an IP routes as the router makes one from the iP address and that addresses all clients so far
<dac> dst-address=172.17.2.0/24 gwy=wireguard1 routing-table=main

MikroTik

MikroTik Wireguard server with Road Warrior clients

MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients

Re: MikroTik Wireguard server with Road Warrior clients