Securing Wireguard setup

RouterOS General
1

Today I managed to set up a Wireguard interface on my hAP ax3 device and 2 Wireguard clients are able to connect to it; these clients are then able to connect to 2 devices on my LAN.

The situation is as follows:
network.png
I have created a port forward on my ISP router to forward any traffic on 1.1.1.1:49152 to 2.2.2.2:49152.

My configuration is as follows (just the Wireguard parts and redacted a bit for clarity (hopefully)):

######################### Wireguard interfaces #########################
##### Interfaces
/interface wireguard add name=wireguard1 listen-port=49152
/ip address add interface=wireguard1 address=3.3.3.1/24 network=3.3.3.0

##### Peers
/interface wireguard peers add interface=wireguard1 allowed-address=3.3.3.2/32 public-key="key1"
/interface wireguard peers add interface=wireguard1 allowed-address=3.3.3.3/32 public-key="key2"

######################### Firewall #########################
##### Input chain
/ip firewall filter add chain=input action=accept in-interface=wan dst-address=3.3.3.1 dst-port=49152 protocol=udp comment="accept Wireguard traffic"

/ip firewall filter add chain=forward action=accept in-interface=wireguard1 out-interface=wan comment="accept traffic from Wireguard to WAN"
/ip firewall filter add chain=forward action=accept dst-address=4.4.4.1 dst-port=53 protocol=udp in-interface=wireguard1 out-interface=vlan1 comment="accept DNS queries from Wireguard to PC1"
/ip firewall filter add chain=forward action=accept dst-address=4.4.4.1 dst-port=53 protocol=tcp in-interface=wireguard1 out-interface=vlan1 comment="accept DNS queries from Wireguard to PC1"
/ip firewall filter add chain=forward action=accept in-interface=wireguard1 out-interface=vlan2 dst-address 5.5.5.1 comment="accept traffic from Wireguard Home to PC2"

##### NAT configuration
/ip firewall nat add chain=dstnat action=dst-nat in-interface=wan dst-address=2.2.2.2 dst-port=49152 to-address=3.3.3.1 to-port=49152 protocol=udp

The rest of my firewall has been set up using the guide that was previously available here on the forum.

My question now is, is there an opportunity to further secure the Wireguard setup? Or maybe a better question: does it make sense to want to secure the Wireguard setup further?

For example: I now allow the Wireguard interface as a whole to communicate with device 5.5.5.1 on vlan2; would it be more secure to create a list of IP addresses containing specific clients that I want to allow to communicate with device 5.5.5.1 on vlan2?

Thank you in advance.

2

Good questions..

(1) The input chain rule can be simplified to just:
/ip firewall filter add chain=input action=accept dst-port=49152 protocol=udp comment=“accept Wireguard traffic”

(2) What most do when the router is the server for handshake is make the wireguard part of the LAN interface list which simplifies DNS and internet access.
/interface list members
add interface=wireguard1 list=LAN

Then this generic rule works for both wireguard and local traffic
add action=accept chain=forward comment=“internet traffic” in-interface-list=LAN out-interface-list=WAN

(3) Its is not clear to me why you are sending only wireguard DNS queries to a PC.
Tis what happens when you do not show the entire config, thus your post lacks context.
Will assume you are running some sort of DNS server on the PC??

If that is the case you probably should have
add chain=dstnat action=dst-nat in-interface-list=LAN dst-port=53 protocol=udp/tcp to-address=4.4.4.1 src-address=**!**4.4.41

This forces all on interface-list=LAN to go to PC1 for DNS.

(4) In the forward chain, keeping with the theme of a single PC handling your DNS, you need better firewall rules
/ip firewall filter add chain=forward action=accept comment=“allow LAN DNS queries to PC1” dst-address=4.4.4.1 dst-port=53 protocol=udp/tcp in-interface-list=LAN

(5) Agree 100% that on the receiving end for wireguard, is where you should reduce access to local subnets if required. If its the admin then not so much and if its a worker that just needs access to a specific subnet or PC then make it so.
add chain=forward action=accept in-interface=wireguard1 src-address (or src-address-list)=RoadWarrior(s) dst-address AS Required (subnet or PC or dst-address list).

(6) Your NAT rule is nonsense…
The Mikrotik gets Ip address 2.2.2.1 on the ISP local LAN subnet.

Its not clear what you are trying to do. The only port forwarding needed was done on your ISP router, forwarding the Wireguard Port to the mikrotik.
Thus on the mikrotik the only thing needed was the input chain rule accepting that connection.

The only thing required on the MT is a the default source nat rule
add chain=srcnat action=src-nat out-interface=WAN

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

What needs to be stated is the entire config is connected and to request assistance without showing the complete config is a job incomplete.

3

I consider “Wireguard” or “ZeroTier” as different “zones”. So these interfaces are not part of the LAN interface-list or something. So I have a set of firewall rules allowing WG-peer(s) to access what they need to action (eg. Plex, HomeAssistant, my home Splunk etc)
So yes, best practice would be to only allow comminications from a certain WG-peer to the servers/services they actually need.

Off course for a home environment this sounds a bit over the top, but during business hours one should always have this mindset :smiley:

4

In a business environment one would use different wg interface altogether to separate business and non-business needs. One could use the same interface and separate subnet addressing as well, which may be appropriate enough to separate some groups of users.
Your input is way overkill here and I disagree with it on top LOL. Interface usage is common and efficient, especially if users are going to go out the local WAN ( lan to wan and dns rules) and the use of firewall rules provides the requirement amount of security for individual user access.

Typically the road warrior is the admin and not a concern.
If its a friend/family member using firewall rules is easy and enough to ensure access to only the r equired subnets or devices etc..
If its a business entity as noted above, different interfaces or diff subnets ( both make firewall rules clearer for separation purposes)

5

Let’s agree to disagree :wink:
It is a good thing RouterOS has dozens of ways to reach the same goals ultimately and he who opened this topic wanted to get different viewing angles I guess.

“des goûts et des couleurs, on ne discute pas”

6

I see red and white my friend, colours of our flag by the way :slight_smile:

the Canadians with Red Maple leafs, drove the Germans from Breskens Pocket. Meanwhile, 2nd Canadian Division, working closely with Belgian resistance fighters, known as the White Brigade, cleared Antwerp’s port, and subsequently advanced north into Holland.

Send chocolate~~~
( looks like I have to come back and liberate you from such silly notions jajajaja )

7

Thank you for your answers. I indeed didn’t include the whole configuration, because I wanted to prevent this to be a sort of review of the configuration. I’m more interested in the thinking behind some of the choices that you and others make. When I understand that, I can then use that in other scenarios as well and create firewall rules (for example) based on it.


I chose to include the destination IP address as well to make the rule more specific and make other requests for port 49152 be rejected, thinking that would make it more secure. Is this a false sense of security in your opinion?


I understand, simpler indeed. My thinking was similar to the above, I would like to keep the local VLANs separate from the Wireguard interface as far as firewall rules go, thinking this would make it a bit more secure, because I am opening up my network to outside access and would like to be more intentional with the access to resources. But, maybe it’s just a false sense of security yet again. :slight_smile: I’ll give this some thought.


You are right, I’m running PiHole on a device on the LAN. One of the reasons to create the Wireguard interface was to be able to provide the PiHole service to road warriors.


I understand, when the Wireguard interface is part of the LAN then this rule would simplify things.


Great, thank you. This was my thinking.


I need that NAT rule because my ISP router can’t connect to the Wireguard interface on 3.3.3.1. How would I make that IP address available on the WAN interface with IP address 2.2.2.2?


I understand. But, your response has already cleared up a few things for me and has given me food for thought. Thank you.

8

This was indeed my general way of thinking. It’s for home use only and so might be a bit overkill, but it’s also a learning experience for me.

9

I understand what you are saying for the home use case. Firewall rules could indeed provide enough security in case of a home use case.

10

(1) Yes, where I say to simplify, indeed its a false sense of security.

(2) By virtue of being on different vlans subnets are ALREADY separated at layer 2.
The firewall rules ensure separation at layer 3.

(3) (4) Good, then my rules apply.

(5) As you require, flexibility of a clean simplified approach.

(6) Not sure what you are thinking here. You are not reaching the mikrotik Router with the client endpoint or endpoint port.
You are reaching the ISP router! On the ISP router is where you need to port forward, NOT the mikrotik.

Typically port forwarding on most consumer routers looks something like
incoming port - 41952 out -going port - 41952 to address - 2.2.2.2

-------- what will happen.
Trafffic from external originating public IP, w.x.y.x will hit ISP router with destination port 41952, the ISP router will pass on the traffic to the LANIP of the MIKROTIK on the ISP LAN, assuming the LAN subnet is 2.2.2.0/24 and the Mikrotik having an IP address of 2.2.2.2
/ip address
add address=2.2.2.2/30 interface=ether1 network=2.2.2.0 or something like that..

The traffic arrives at the WANIP of the Mikrotik (from the MT router perspective) heading for port 41952 with the original external source IP of w.x.y.z
The router will see that the port exists for the wireguard interface and will begin to proceed with processing the handshake.
Once connected, traffic can flow on the tunnel as required.

11

I have a port forward defined on the ISP router that forwards traffic for 1.1.1.1:41952 to 2.2.2.2:41952.

I remember that I added the NAT rule because at that moment my Wireguard clients couldn’t connect. I turned on logging in the firewall and saw that the request came in on the Mikrotik router for IP 2.2.2.2:41952, while the IP for the Wireguard interface is 3.3.3.1. I thought that this meant that the Wireguard interface could not be reached directly on my WAN interface and so I added the NAT rule.

Now, I changed quite a few things since then, so I will remove the NAT rule and see what happens.

Thank you again for your input.

12

Its not a matter of seeing what happens, its KNOWING what will happen. Use the force! This is the way!

13

I changed the input rule as you suggested to:

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

And I removed the NAT rule.

The result was that my client devices couldn’t connect anymore.

There is something else in my configuration that is stopping that from working, I’ll dive into that later this week.

Thank you for your suggestions, it’s been very helpful.

14

Post your latest config and will have a look.

15

Thank you. I’ll have a look first and see if I can find something.

16

Sounds good… let us know either way.

17

<removed nonsense post, mixing L2 and L3 interfaces with each other, will update soon>

18

Today I was able to have a look at this again:

I disabled the NAT rule and also changed the firewall rule in the “input” chain:

from:
/ip firewall filter add chain=input action=accept in-interface=wan dst-address=3.3.3.1 dst-port=49152 protocol=udp comment="accept Wireguard traffic"

to:
/ip firewall filter add chain=input action=accept in-interface=wan dst-port=49152 protocol=udp comment="accept Wireguard traffic"

And this works (the Wireguard clients can connect), although the “handshake” behavior is a little bit inconsistent. There are times when the handshake doesn’t complete and I have to give it a few tries.

In a previous post, you said:


(3) Its is not clear to me why you are sending only wireguard DNS queries to a PC.
Tis what happens when you do not show the entire config, thus your post lacks context.
Will assume you are running some sort of DNS server on the PC??

If that is the case you probably should have
add chain=dstnat action=dst-nat in-interface-list=LAN dst-port=53 protocol=udp/tcp to-address=4.4.4.1 src-address=!4.4.41

This forces all on interface-list=LAN to go to PC1 for DNS.

I notice that you use the “dstnat” chain and the word “force”. In other words, is this an alternative to providing a DNS server in the DHCP configuration? Or: is this “more secure” because no matter what DNS server configuration is in the DHCP settings, any device on the network will use the DNS server specified in the NAT rule? If so, very interesting.

Thank you for your help!

19

The latter yes but only works if the user is not savvy enough to bypass your dns settings… so DNS redirection is only for those somewhat compliant

20

Great, I might give this a try on the guest part of the network. Not really needed, but a nice improvement to lock things down a bit more.


Thank you for your help!