I have a working routeros hex s (new to me) erased and updated to 7.9
I ran through the default config and got basic things working, lan dhcp, wan masquerade, ntp client/server, dns caching, and queing with cake..
I then setup wireguard following the docs with a peer, everything works except I cannot use the routeros dnscache via the wireguard peer..
when I use a different upstream recursor everything resolves and full tunnel wireguard does work..
I do have allow-remote-requests=yes on the dns
eth1 is wan
eth[2-5] is bridge and lan
wireguard is 192.0.2.254/28 and the peer is 192.0.2.241 (I did not see any type of bogon/rfc filtering that would cause the test-net-1 range not to work)
clients from the lan can ping 192.0.2.254 and seemingly resolve from it..
Network diagram, ( since you never stated what you are connected to for ISP or wireguard )
/export file=anynameyouwish (minus router serial number and any public WANIP info)
The incoming wireguard user (assuming thats you the ADMIN) to access DNS must have access on the input chain which the above rule provides. Its really designed to allow ADMIN to configure router remotely.
For other wireguard users that are not ADMIN but may be coming into the router but should not have OPEN access to the router would not be on the above rule but would be covered by adding the wireguard1 interface to the LAN list and thus your rule below would permit DNS. /ip firewall filter add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN
(2) Set this to none, at least while troubleshooting.
/interface detect-internet set detect-interface-list=all
(3) Ensure your ip dhcp-server network setting is complete.
shows:
/ip dhcp-server network add address=192.168.88.0/24 comment=defconf gateway=192.168.88.1
SHOULD BE
/ip dhcp-server network add address=192.168.88.0/24 comment=defconf dns-server=192.168.88.1 gateway=192.168.88.1
(4) You dont have any other servers assigned ( and have no idea what you have on the IP DHCP client settings, that I can see so
from /ip dns set allow-remote-requests=yes max-concurrent-queries=512 servers=???working,addresses,here???
TO
/ip dns set allow-remote-requests=yes max-concurrent-queries=512 servers=1.1.1.1
///////////// Dont see anything else after a quick viewing.
If you have DOH setup, then your approach for DNS is wrong.
Point the client wireguard to 192.168.88.1, setup DOH properly, ensure the wireguard user has a path to DNS services ( as I have noted in input chain (for admin, and for other wg users).
Hint here is mine to adguard DNS DOH /ip dns
set allow-remote-requests=yes cache-max-ttl=1h servers=94.140.14.14,94.140.15.15
use-doh-server=https://dns.adguard-dns.com/dns-query verify-doh-cert=yes
You need at least one public DNS server so that the router can find and connect to the DOH server and further DNS traffic is then encryped.
the 94.x servers are their public non DOH servers…
I am not sure if the attachments help illustrate the problem better..
Specifically Data Sent and Data Received entries.. (no dns no data moving..)
From Wireguard I cannot use my dns cache hosted on the router endpoint, using any of the directly connected/configured interfaces..
The dns cache works, there are cache hits within the process.
Lan clients do not have this problem, or any other problem.. just Wireguard clients using the router dns cache.. that seems to be the exclusive problem.
I’m using Wireguard on iOS and I don’t have such issue. Can you access router with Mikrotik iOS app when you are connected over Wireguard?
Edit: Sry for confusion, I see now you have DNS cache issue, not connection… I’m using DNS server (Pi-Hole) running in container which is also set for Wireguard, probably that’s why I don’t have such issue, before I was on ROS DNS but I didn’t noticed cache issue (if was even persisted).
Yup its very strange…
There is something non-standard the oP is doing with DNS setup is the only assumption that I can make.
It works for everyone else, ( and I use IOS quite successfully )
That configuration tool seems to be for generic linux and does not apply to RoS, nor IOS for that matter. nothing burger.
More important to understand the use/significance of each parameter.
As I said those tools are not all that helpful. Much more important to know how to config the Mikrotik RoS and wireguard is not all that difficult to understand. https://forum.mikrotik.com/viewtopic.php?t=182340
Adding my wireguard interface to the LAN list resolved the DNS access issue for me, however it doesn’t work with just the input chain firewall rule for my wireguard subnet. My wireguard server subnet is 192.168.222.0/24, the client has 192.168.222.1 (router wireguard interface IP) for DNS and my firewall filter rule is as below:
/ip firewall filter add action=accept chain=input comment=“vpn server” src-address-list=192.168.222.0/24
Shouldn’t this still work without adding the wireguard interface to the LAN list because the firewall rule is accepting traffic from the source subnet without any restriction on ports or destination address?
In addition, which is preferrable for security implications? I only have the defconf drop all not coming from LAN rule using the LAN list at the moment.
You would have to post your config for me to comment accurately.
/export file=anynameyouwish ( minus router serial number and any public WANIP information, keys etc. )
As to the questions… I would do things differently. I would give the MT Wireguard Server the IP address
192.168.222**.1/24** and the IP road warrior 192.168.222.2/32 and the next RW 192.168.222.3/32 etc…
Then try it with your rule and it should work.
Many variations are possible but if you want to keep the wg interface out of the LAN list ( dont know why its so convenient!! )
then
add chain=input action=accept in-interface=wg { allows all wireguard users ability to config router or get DNS }
OR
add chain=input action=accept in-interface=wg src-address=XXXXX ( if you want to narrow down who coming in over wireguard needs access to router for config ).
add chain=input action=accept in-interface=wg dst-port=53 protocol=udp ( allow rest only dns )
add chain=input action=accept in-interface=wg dst-port=53 protocol=tcp ( allow rest only dns )
Allowing DNS from the wireguard interface worked well. I still wasn’t able to access Winbox over the tunnel with the src-address rule, but I can look into that later. I’m not against adding the wireguard interface to the LAN list. I was more just curious why it wasn’t working the other way and which method was preferred. Thank you for your help!
