Hi,
I had to install pi-hole again on another linux machine. Since I want every DNS query requests coming from my LAN be redirected to my pihole, I had set these rules:
My LAN = 192.168.3.0/24
Pi-hole Ip= 192.168.3.97
Linux machine IP with pihole = 192.168.3.99
To test it I set a dns server ip in my pc’s network card properties, but I can’t browse the internet anymore nor run a simple nslookup from my device.
I followed this tutorial at the time: https://itimagination.com/mikrotik-pihole-block-all-ads/
I haven’t understood what is wrong now.
Could you please help me?
Thanks
Yes and no. You’re using dstnat to forward traffic from LAN back to same LAN, so you need hairpin NAT (https://wiki.mikrotik.com/wiki/Hairpin_NAT) and that’s what those rules are doing. But you can also replace them by universal one:
None of the rules above really affects traffic in some way. They don’t catch and redirect DNS query requests,
even when I change dns server ip directly in one of my devices. It is as if I hadn’t set them at all.
Thank you
Maybe it’s something else in your config influencing it, there are many ways how to misconfigure something. Also make sure that Pi-hole works correctly. Either use some tools to query it directly, or set it as only dns server on some client device. Disable all redirection for start and see if that works.
For port 53, udp, tcp.
redirect - replaces destination port of an IP packet to one specified by to-ports parameter and destination address to one of the router’s local addresses
I set my NAT rules again (those in my first post above) and do some test:
The NATdst rule seems to redirect the dns query requests coming from my pc:
in the log I see this:
192.168.3.99 is my netbook IP (you can glimpse its mac address too) with ubuntu installed on it. I installed pi-hole in ubuntu which has a different IP (192.168.3.97) I can’t see in the log
There must be something wrong here already.
Meanwhile I disabled Masquerade rule.
Do I understand correctly that you don’t actually have separate server, but both addresses (.97 and .99) are on your netbook and you are also testing this from same netbook? It that’s the case, are you sure that Pi-hole not only listens on 192.168.3.97, but also uses it as source for own outgoing queries? Because if it doesn’t, it can’t work neither with your dstnat rules nor the other ones.
.97 and .99 are on my netbook. I had the same setup when I used Openmediawault as OS and pi-hole as one of its containers..and it worked flawlessly. I tried to replicate it on a different device (my netbook) and I have been struggling to make it work properly since then. I am testing it from a different machine (my pc - IP 192.168.3.100) on the same LAN.
Thanks
Poor guy, ISP is via wifi.
Do you get a public IP or just a private IP??
Dont think this is a problem but tis left over from default config and can be removed.
/ip dns static add address=192.168.88.1 comment=defconf name=router.lan
Not sure what purpose this serves…
add name=dhcp_pool2 ranges=192.168.10.2-192.168.10.254
order of firewall rules is important and thus important for clarity not mix up input and forward chain, so your rules actually look like this, respecting order presented.
I have numbered them to reflect what should be order (at least from what I have seen).
The one in red you should get rid as you already drop external traffic in a later rule.
The one in green is not required as you drop all traffic later. If you still want to do port forwarding modify the existing rule to the clearer:
add action=accept chain=forward comment=
“Allow Port Forwarding” connection-nat-state=dstnat
connection-state=new in-interface-list=WAN
/ip firewall filter
(2) add action=drop chain=input comment=“defconf: drop invalid” connection-state=invalid
(1) add action=accept chain=input comment=“defconf: accept established,related” connection-state=established,related add action=drop chain=input dst-port=80 in-interface-list=WAN protocol=tcp Note: covered by rule drop all not coming from LAN*******.
add action=drop chain=input icmp-options=8:0-255 in-interface-list=WAN protocol=icmp
add action=accept chain=input comment=“defconf: accept ICMP” limit=1,5:packet protocol=icmp
add action=accept chain=input comment=“From pfsense LAN” log=yes src-address=192.168.5.0/24
add action=accept chain=input comment=“defconf: accept to local loopback (for CAPsMAN)” dst-address=127.0.0.1
add action=accept chain=input comment=“allow OpenVPN” dst-port=1194 protocol=tcp
add action=accept chain=input comment=“allow OpenVPN” dst-port=1195 protocol=tcp
add action=accept chain=input comment=“From OpenVPN interface” in-interface=*F00000 log=yes
add action=drop chain=input comment=“defconf: drop all not coming from LAN” in-interface-list=!LAN log=yes *******
(5) add action=drop chain=forward comment=“defconf: drop all from WAN not DSTNATed” connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
(6) add action=drop chain=forward comment=“Drop all else” disabled=yes
As for DNS,
Why all these sourcnat confusionary approaches argggg.
if you want all your DNS to go to a specific IP could one not do the following with dstnat??
add action=redirect chain=dstnat comment=
“Force Users to Router for DNS - TCP” disabled=yes dst-port=53 protocol=
tcp [ (your choice) src-address-list= OR in-interface-list= ]
add action=redirect chain=dstnat comment=
“Force Users to Router for DNS - UDP” disabled=yes dst-port=53 protocol=
udp [ (your choice) src-address-list= OR in-interface-list= ]
This forces users to use router DNS settings.
In Router DNS settings put in the PI-hole DNS server as the fixed address to use…
Just have to allow DNS server IP to the internet I suppose on port 53??? so its not blocked by redirect rule??
It gets real fuzzy for me real fast… can you tell.
The one in green is not required IF you drop all traffic later, but that currently doesn’t happen because (6) is disabled.
If you change it as suggested, you want to accept everything with connection-nat-state=dstnat, without any in-interface filter. That’s because you want it to allow also dstnatted connections to Pi-hole that would otherwise be blocked. But that’s with the new config, they are not blocked now, as long as last drop all rule is disabled.
My suggestion, before you start changing anything, go step by step and verify that you have basic stuff working:
Make sure that Pi-hole works at all. From same machine do e.g. “dig mikrotik.com@192.168.3.97” and see if you get something.
While doing so, check what source address Pi-hole uses. You can use tcpdump on same machine with filter “port 53” to see it.
Make sure that Pi-hole is accessible from another machine, so same as first step, only from elsewhere.
I’m not familiar with dnsmasq, I know what it does, but that’s all. If you have it listening only on .99 and Pi-hole has .97 for itself, they should coexist without problems.
I did a few tests.
I reloaded an OpenMediaVault VM machine on my VMware workstation. It has an old version of pi-hole installed on it as a container.
I set the SAME RULES in my first post above in my Mikrotik device (just different IPs of course)…and it works now!!
That is strange.
As I said, there must be something wrong with either ubuntu server or dnsmasq installed on it..or both.
Any thought?
Thanks
