I have a working wireguard instance and a pihole that drops a lot of advertising traffic running on the same router. All of the traffic is forced through the pihole via NAT rules. If I connect to my network with no VPN and run an adblock test (d3ward.github.io) about 64% of ads are blocked. If I connect to wireguard on my router and run the same test only 21% is blocked.
I cannot see how the Wireguard connection can avoid the pihole since all DNS traffic is forced (via a NAT port 53 rule) to go through there. I advertise my router as the DNS server and use the NAT rule to send it to the pihole (which is on a different IP range) so that I can switch it on and off easily.
Is there something in the wireguard protocol, as implemented in routeros, that would avoid that NAT rule? That’s the only reason I can think of that it doesn’t work.
Could be that. The firewall rules allow the wireguard IP address range to interact with my LAN range, and the DNS address is on the LAN range. Wireguard is configured to use the LAN’s DNS server address (the router address), which is redirected via NAT to the pihole. Works for everything else on the LAN so not sure why it doesn’t for the Wireguard.
I dont think its possible when using a third party wireguard VPN server to avoid using the third party provided DNS server.
However with the sparse details provided who knows.
Should really provide config.
Description is incomplete.
What wireguard is this
a. going to third party Wireguard Server ??
b. Hosting wireguard on your router so having admin or others come in on wireguard?
c. other?
If, a, is the whole subnet supposed to use WG for internet for example??
Im confused doesnt PPPOE ISP give you a dynamic PUBLIC IP address ??
The reason I ask is you have back to home in your comment for the wireguard interface and thats for the case when you dont have a public IP.
Maybe just used the wording not realizing its confusing, if not true???
Also note your using layer7 which is basically not valid anymore.
The back to home “feature” (I say that because ahem Mikrotik back to home doesn’t work, at least for me) I tried but it is redundant. It uses Wireguard, which is why there is an additional entry for it, but it doesn’t work, so I don’t use it. Perhaps it doesn’t work because of that public/static IP question. I have a static IP address.
Layer 7 is a redundant thing I tried to play around with, but it’s just redundant kruft in my config.
WireGuard works, it’s just the DNS question I’m trying to solve.
I get this in the log, which doesn’t look suspicious to me, but nothing about DNS traffic - perhaps I need to enable something in the logging to trace this?
masq srcnat: in:wireguard1 out: Vodafone, connection-state:new proto TCP (SYN), 192.168.10.2:60173->104.16.160.168:443, len 64
add action=dst-nat chain=dstnat comment=
“Force any UDP DNS queries that aren’t to pihole to go to pihole”
dst-address=!172.17.0.2 dst-port=53 in-interface=“Local Bridge” protocol=
udp src-address=!172.17.0.2 to-addresses=172.17.0.2
add action=dst-nat chain=dstnat comment=
“Force any TCP DNS queries that aren’t to pihole to go to pihole”
dst-address=!172.17.0.2 dst-port=53 in-interface=“Local Bridge” protocol=
tcp src-address=!172.17.0.2 to-addresses=172.17.0.2
Well … your intercepting/NAT rules expect the UDP/TCP/53 packets to be arriving from the “Local Bridge” ???
That is probably not your wireguard-interface … hence this rules does not hit for WG-traffic ?
I will have a look.
Goal is to ensure road warriors or any user for that matter coming in via Wireguard and going out LOCAL 5009 internet gets stuffed through the pi hole DNS.
(1) Add wireguard to LAN interface /interface list member
add interface=“Local Bridge” list=listBridge
add interface=Vodafone list=WAN
add interface=“Port 8 - WAN” list=WAN
add interface=dockers list=listBridge add interface=wireguard1 list=LAN
(2) The firewall rules are messy but think you have everything covered…
I am a bit confused in that dockers is a bridge and you have a veth assigned to it with a different IP address than the LAN and
so far its not clear what IP address your PIhole has on the router ??? Okay I see it later!
The one thing that may be missing is in the FORWARD CHAIN, allowing wireguard to dockers!!! Just change this rule..
FROM: add action=accept chain=forward comment=“Docker forward rule” in-interface=
“Local Bridge” out-interface=dockers
TO: (since we added the wireguard interface to the LAN above) add action=accept chain=forward comment=“Docker forward rule” in-interface**-list=LAN** out-interface=dockers
(3) Okay forcing traffic to pihole seems also messy. Lets see if we can simplify.
What I dont understand is what is the purpose of the FIRST RULE ??? add action=dst-nat chain=dstnat comment=PiHole dst-address=10.160.100.1
dst-port=888 in-interface=“Local Bridge” in-interface-list=all protocol=
tcp to-addresses=172.17.0.2 to-ports=80
(4) The next two rules are common. One forces all dns traffic to the desired IP address except any IP addresses that the admin does not want to force there PLUS of course the pi hole address itself to avoid a loop to self LOL. add action=dst-nat chain=dstnat comment=“force all users to DNS pihole”
in-interface**-list=LAN** dst-port=53 protocol=udp src-address-list=!Excluded to-addresses=172.17.0.2
add action=dst-nat chain=dstnat comment=“force all users to DNS pihole”
in-interface**-list=LAN** dst-port=53 protocol=tcp src-address-list=!Excluded to-addresses=172.17.0.2
WHERE /ip firewall address-list
add address=172.17.0.2 list=Excluded
add address —> list=Excluded any other single IPs or subnets etc… FLEXIBLE APPROACH
Thank you for your reply. I was travelling last week, hence my noticing the traffic problem and also hence my slow reply.
In reply:
Is adding wireguard to the LAN a good/bad/neutral idea? There is normally a separation (in my case by IP range, amongst other things), but I don’t know enough about VPNs to understand the consequences or potential issues.
Any reason why you think they are messy? I’m a beginner at this so every day is a learning opportunity
The port 888 rule opens up the web config interface to the pi-hole instance.
So is the point here to a) change the in to an interface list rather than an interface and b) to remove the !destination address of the pihole?
Well, you have two options..
a. send wireguard traffic without using your PI functionality and the PI works for the rest of the LAN.
b. send PI traffic instead of to 1.1.1.1 or 8.8.8.8 to DNS server of provider and then all wireguard users will be ipso facto using your PI server HOWEVER, so will the rest of the lan traffic.
You could split it so wireguard uses PI and local traffic uses some DOH service through the mikrotik…
Is there no way to enable a route to the PiHole container/VETH and redirect DNS traffic there independently of the LAN access? I don’t see why the container can’t be made available to WireGuard in this kind of way…
There is no such option I am aware of.
All the wireguard traffic needs to go out the tunnel including DNS.
Just run two PI dns servers, one for wireguard and one for LAN.
The only difference is the WI_PI uses the third party DNS address to get DNS (vice 1.1.1.1 or something else on the LAN side).
Thank you. I can see the logic in that suggestion, but I wonder why my setup needs two piholes.
The way my setup works is I advertise DNS through DHCP as the router address, which is on my LAN range - 10.160.100.1 - and force it to the PiHole - 172.17.0.2, which isn’t on the LAN range. The pihole uses the router (10.160.100.1) as the upstream DNS server, which in turn uses 1.1.1.1.
I think what you’re suggesting is to allow the wireguard to connect to a different pihole server on a different IP range than Wireguard. However, since that’s what I do for the LAN why can’t I redirect the Wireguard traffic to 172.17.0.2 as well?
Both ways I am taking an IP address range and forcing it to use a DNS server on another. I don’t see why I need two piholes to do that - or am I missing something?
Can’t I just add another NAT rule, similar to the ones I have, that use the Wireguard as the in interface (as opposed to local bridge) to redirect the NAT traffic? Or, as per a previous suggestion, use an in interface list?
