Force Users to Use Specific DNS Server

gyropilot · Sun Apr 28, 2019 6:41 am

Greetings,

I'd like to force all users on my single home LAN to use my own Pi-Hole DNS server just in case they've manually configured another DNS server.

I found this entry in the MikroTik WiKi which seems like a simple solution: https://wiki.mikrotik.com/wiki/Force_us ... DNS_server

It states...

This is just simple firewall rule which will force all Your users behind RB to use DNS server which You will define.

In /ip firewall nat
Code: Select all
add chain=dstnat action=dst-nat to-addresses=192.168.88.1 to-ports=53 protocol=tcp dst-port=53 
add chain=dstnat action=dst-nat to-addresses=192.168.88.1 to-ports=53 protocol=udp dst-port=53
This rule will force all users with custom defined DNS server to use 192.168.88.1 as their DNS server, this rule will simply redirect all request sent to ANY-IP:53 to 192.168.88.1:53

Unfortunately it doesn't work! When I add and enable these two rules on my router's NAT exactly as shown (except I specify the Pi-Hole's IP as the "to-address") DNS stops working. As soon as I disable the rules, DNS works fine.

The Pi-Hole DNS server is also on my LAN.

Can anyone please tell me what I'm missing?

Thank you,

John

HzMeister · Sun Apr 28, 2019 7:55 am

You've got to setup hairpin nat for the pihole. Change 192.168.1.2 to your pihole ip.

/ip firewall nat  

add chain=dstnat action=dst-nat to-addresses=192.168.1.2 protocol=udp src-address=!192.168.1.2 dst-address=!192.168.1.2 dst-port=53 in-interface=!ether1
add chain=dstnat action=dst-nat to-addresses=192.168.1.2 protocol=tcp src-address=!192.168.1.2 dst-address=!192.168.1.2 dst-port=53 in-interface=!ether1 

add chain=srcnat action=masquerade protocol=udp src-address=192.168.1.0/24 dst-address=192.168.1.2 dst-port=53 
add chain=srcnat action=masquerade protocol=tcp src-address=192.168.1.0/24 dst-address=192.168.1.2 dst-port=53

td32 · Sun Apr 28, 2019 8:15 am

were does your pihole get its dns?
you must allow requests from pihole ip to reach the dns resolver the pihole uses

gyropilot · Sun Apr 28, 2019 8:25 am

were does your pihole get its dns?
you must allow requests from pihole ip to reach the dns resolver the pihole uses

Good point! I knew I must be overlooking something obvious.

Pi-Hole's DNS resolver is OpenDNS at 208.67.222.222 and 208.67.220.220.

So without additional NAT rules to clear Pi-Hole's DNS resolver queries, I take it they would also get routed right back to itself?

Thank you,

John

gyropilot · Sun Apr 28, 2019 8:28 am

You've got to setup hairpin nat for the pihole.

Thank you HzMeister. I'll give this a try.

Regards,

John

chilliflakes · Fri Oct 18, 2019 3:49 pm

Greeting!
I also just want to provide "opendns" DNS Server to block porno!

i used this code

/ip firewall nat

add chain=dstnat action=dst-nat to-addresses=208.67.222.123 protocol=udp src-address=!208.67.222.123 dst-address=!208.67.222.123 dst-port=53 in-interface=!bridge-GF
add chain=dstnat action=dst-nat to-addresses=208.67.222.123 protocol=tcp src-address=!208.67.222.123 dst-address=!208.67.222.123 dst-port=53 in-interface=!bridge-GF

add chain=srcnat action=masquerade protocol=udp src-address=192.168.50.0/24 dst-address=192.168.50.2 dst-port=53
add chain=srcnat action=masquerade protocol=tcp src-address=192.168.50.0/24 dst-address=192.168.50.2 dst-port=53

Buy its not working for me (:
In one of the user PC i can change DNS server to 8.8.8.8 and can load all porno content.
I would be glad if some one can point me where i am making a mistake.

kaherdin · Sun Dec 05, 2021 10:25 pm

were does your pihole get its dns?
you must allow requests from pihole ip to reach the dns resolver the pihole uses

Good point! I knew I must be overlooking something obvious.

Pi-Hole's DNS resolver is OpenDNS at 208.67.222.222 and 208.67.220.220.

So without additional NAT rules to clear Pi-Hole's DNS resolver queries, I take it they would also get routed right back to itself?

Thank you,

John

I have the exact same issues.
World you mind sharing all the steps necessary to achieve this?
Peace

gyropilot · Mon Dec 06, 2021 12:46 am

I have the exact same issues.
World you mind sharing all the steps necessary to achieve this?
Peace

kaherdin,

Are you looking for the exact steps needed to have RouterOS use Pi-Hole for DNS?

Or are you looking for the steps required to FORCE users behind RouterOS to use Pi-Hole for DNS?

If the former, I can post the steps. Just let me know.

If the later, I can’t help because I decided it wasn’t necessary on my LAN so I never implemented it.

John L.

anav · Mon Dec 06, 2021 1:57 am

If you are using OPEN DNS, why bother with pi-hole???
Just set up open dns as the static DNS setting
Then use redirect function on the dstnat rules and the dns queries will be forced to one of the router interfaces and since the router has been told to use open dns it should work.

/ip dns static
add address=208.67.222.222 name=OpenDNS1
add address=208.67.220.220 name=OPENDNS2

remove any other servers.................

Then add to nat rules....
/ip firewall nat
........
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=tcp
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=udp

kaherdin · Mon Dec 06, 2021 7:39 am

I have the exact same issues.
World you mind sharing all the steps necessary to achieve this?
Peace
kaherdin,

Are you looking for the exact steps needed to have RouterOS use Pi-Hole for DNS?

Or are you looking for the steps required to FORCE users behind RouterOS to use Pi-Hole for DNS?

If the former, I can post the steps. Just let me know.

If the later, I can’t help because I decided it wasn’t necessary on my LAN so I never implemented it.

John L.

I'm using a pihole, and i want to try to force as many DNS requests to it, despite devices trying to circumvent it using hard coded DNS settings...

Sob · Mon Dec 06, 2021 3:08 pm

Either do what @anav posted and force clients to use router as resolver (which is configured to use pihole as its upstream resolver). Or if you want to send queries to pihole directly, then:

/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.0/24 action=masquerade

kaherdin · Mon Dec 06, 2021 4:19 pm

Either do what @anav posted and force clients to use router as resolver (which is configured to use pihole as its upstream resolver). Or if you want to send queries to pihole directly, then:
Code: Select all
/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.0/24 action=masquerade

Is this, shown below, done on a client per client basis?

/ip dns static
add address=208.67.222.222 name=OpenDNS1
add address=208.67.220.220 name=OPENDNS2

Is this code going to block the answers from getting back to my Pi-Hole?

/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.0/24 action=masquerade

anav · Mon Dec 06, 2021 5:00 pm

For starters dont mix and match ideas........

My point and I wish Sob would clarify was to NOT use pi-hole at all if not needed.
If you can direct users via MT config to use open dns as a service then pi-hole is not needed.

Q1 OP: So is pi-hole the requirement or is open dns the requirement????
(in other words is there something else pi-hole is doing that you want included or not)/

Q2 SOB: Please confirm/deny what I proposed will work to send all users directly to open dns bypassing Pi hole.

Q3. Sob: using your method to get folks to pi-hole....... why the sourcenat rule??? (this is not a port forwarding scenario?)

Sob · Mon Dec 06, 2021 5:32 pm

For start, people should not reply to years old posts with "I have the same problem", because they usually don't have exactly the same problem, and someone always gets misled by old posts. Anyway...

There are two ways:

a) Use @anav's rules with action=redirect to redirect all queries to router itself, and it will use whatever resolvers it has in "/ip dns servers" (not "/ip dns static", that was error).
b) Use my rules with action=dst-nat to redirect queries to external resolver. If it's in same LAN, it needs also hairpin NAT rule (the one in srcnat chain).

@anav: Q2: yes; Q3: of course it is

anav · Mon Dec 06, 2021 6:38 pm

Okay some progress,
Why not put the open dns servers as static entries.
Does that not mean they take precedence over any other DNS server noted??
Stated otherwise, why put them under Servers?
and if you put them under Servers do you need then to check off the box, allow remote requests??

Sob · Mon Dec 06, 2021 7:00 pm

"/ip dns static" is locally defined static records, they do have precedence, but this:

/ip dns static
add address=208.67.222.222 name=OpenDNS1
add address=208.67.220.220 name=OPENDNS2

means that if someones asks router to resolve hostname "OpenDNS1", it will return address 208.67.222.222, and same for the other one. Problem is, no one will ever ask router to resolve hostname "OpenDNS1". If you want router to use OpenDNS resolvers, it's:

/ip dns
set allow-remote-requests=yes servers=208.67.222.222,208.67.220.220

And allow-remote-requests=yes is required when router should serve as resolver for anyone else. If it's allow-remote-requests=no, then it's only for router's internal use, e.g. if it needs to resolve server hostname used by VPN client, some MikroTik's url for upgrades, etc.

anav · Mon Dec 06, 2021 9:24 pm

Crystal clear!!

Then the solutions become.
A. Force Redirect to OPENDNS (without PI hole)
/ip dns
set allow-remote-requests=yes servers=208.67.222.222,208.67.220.220

/ip nat
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=tcp
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=udp

B. Force OPEN DNS (via PI hole)
/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.0/24 action=masquerade

Jotne · Mon Dec 06, 2021 9:55 pm

I have seen problem with devices like Chromecast when redirecting port 53. These devices has hard coded DNS to for example 8.8.8.8

Sob · Mon Dec 06, 2021 10:10 pm

If they send query to 8.8.8.8, they will get response from 8.8.8.8 (not really, but it will seem to them to be from there). One possible problem I'm aware of is that RouterOS v6 doesn't keep the case of letters, so if you ask for "MikroTik.com", the answer will contain "mikrotik.com" and some devices may not like that. It's fixed in v7.

anav · Mon Dec 06, 2021 11:07 pm

If they send query to 8.8.8.8, they will get response from 8.8.8.8 (not really, but it will seem to them to be from there). One possible problem I'm aware of is that RouterOS v6 doesn't keep the case of letters, so if you ask for "MikroTik.com", the answer will contain "mikrotik.com" and some devices may not like that. It's fixed in v7.

TO be pedantic was it a case of not keeping letter or was it correcting non-standard confirming domain names coming from smart devices??? (in either case client device rejects return traffic)

Sob · Mon Dec 06, 2021 11:41 pm

Dns is not case sensitive, so whether client asks for MikroTik.com, mikrotik.com, MiKrOtIk.CoM, or any other combination, it's the same thing. But if I remember correctly, all other servers kept the same case in answer, so there was RFC draft that this could be used to make queries more unique, to prevent blind cache poisoning, where attacker sends huge number of spoofed answers and hopes to guess the right id and port of answer expected by resolver. If you could add different letter case to this, it would make it even more unlikely for attacker to succeed. I think it never made it to standard, but someone took it as good idea anyway. So I'd say that the behaviour of ROSv6 is somewhere between right and wrong. Not really wrong, but different from what everyone else was doing.

Amm0 · Mon Dec 06, 2021 11:44 pm

If they send query to 8.8.8.8, they will get response from 8.8.8.8 (not really, but it will seem to them to be from there). One possible problem I'm aware of is that RouterOS v6 doesn't keep the case of letters, so if you ask for "MikroTik.com", the answer will contain "mikrotik.com" and some devices may not like that. It's fixed in v7.
TO be pedantic was it a case of not keeping letter or was it correcting non-standard confirming domain names coming from smart devices??? (in either case client device rejects return traffic)

If extra-pedantic is a word... see RFC 4343 in Section 4. Apparently V6 DNS's approach is called "Name Compression" and allowed.

anav · Tue Dec 07, 2021 1:08 am

That is awesome....... Nice link!

MTNick · Tue Jan 02, 2024 9:26 pm

Crystal clear!!

Then the solutions become.
A. Force Redirect to OPENDNS (without PI hole)
/ip dns
set allow-remote-requests=yes servers=208.67.222.222,208.67.220.220

/ip nat
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=tcp
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=udp

B. Force OPEN DNS (via PI hole)
/ip firewall nat
add chain=dstnat in-interface-list=LAN protocol=tcp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=dstnat in-interface-list=LAN protocol=udp dst-port=53 action=dst-nat to-addresses=10.0.0.31 to-ports=53
add chain=srcnat src-address=10.0.0.0/24 dst-address=10.0.0.0/24 action=masquerade

Greetings Anav,

These two rules below, in the "A." option above, do they also require the "to-ports=53" as well?
/ip nat
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=tcp
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=udp

anav · Tue Jan 02, 2024 9:30 pm

Negative, to ports is implied to be the same as dstports if not entered. To-Ports is this really used when doing port translation.
What is important is such sweeping rules in-interface-list=LAN is to ensure you exclude the pI LAN address or any other subnets not being subjegated to PI.

/ip nat
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=tcp src-address-list=!Excluded
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=udp src-address-list=!Excluded

/ip firewall address list
add address=IP-Pi-device list=Excluded
add address=lanSUBNET list=Excluded.

These devices require access to normal DNS services. Dont want PI device to be in a loop LOL.

anav · Tue Jan 02, 2024 9:35 pm

Caution that I have seen RECENTLY folks using these rules and not putting a SOURCE part of the rule. (in interface lan)
IF you dont then anyone on the internet will start using your pi server!!

I note the original link at the top of the thread showed this dangerous config and its from an old no longer available site.

MTNick · Tue Jan 02, 2024 10:25 pm

Negative, to ports is implied to be the same as dstports if not entered. To-Ports is this really used when doing port translation.
What is important is such sweeping rules in-interface-list=LAN is to ensure you exclude the pI LAN address or any other subnets not being subjegated to PI.

/ip nat
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=tcp src-address-list=!Excluded
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=udp src-address-list=!Excluded

/ip firewall address list
add address=IP-Pi-device list=Excluded
add address=lanSUBNET list=Excluded.

These devices require access to normal DNS services. Dont want PI device to be in a loop LOL.

Greetings Anav,

Thanks for the quick reply. I have a Pi-Hole server as well, not using it though. Found it caused more issues than what it's worth (things not working due to ad-blocker detected) over the last few years, so decided to remove it. I've been following you quite a bit on this forum. Take what you, SOB & rextended post as gold lol. I enabled logging on the force DNS rules. Logging reveals 8.8.8.8:53 is being used but that's not what's allowed in my lists or in DNS servers. I'm not sure if it's working properly. Can you take a quick look? Below is my config (apologies if you want me to create a new post).

From the log: dstnat: in:Lan Bridge out:(unknown 0), connection-state:new src-mac d8:0f:99:42:bd:73, proto UDP, 192.168.201.77:57703->8.8.8.8:53, len 62

ROS 7.13 using the Apprentice FW located here: viewtopic.php?t=180838

/ip dns
set allow-remote-requests=yes servers=1.1.1.2,1.0.0.2,185.228.168.9
/ip firewall address-list
add address=my.LAN.block comment="Admin - Devices" list=\
admin
add address=my.LAN.block comment="Admin - Wireguard" list=admin
add address=my.LAN.block comment=SyncServer list=SyncServer
add address=my.LAN.block comment="Current Network" list=\
expected-address-from-LAN
add address=224.0.0.0/4 comment=Multicast list=expected-address-from-LAN
add address=255.255.255.255 comment=Local list=expected-address-from-LAN
add address=my.LAN.block comment="Wireguard Network" list=\
expected-address-from-LAN
add address=1.1.1.1 comment="Allowed DNS Servers - Cloudflare" list=\
allowed_DNS
add address=1.0.0.1 list=allowed_DNS
add address=1.1.1.2 list=allowed_DNS
add address=1.0.0.2 list=allowed_DNS
add address=1.1.1.3 list=allowed_DNS
add address=1.0.0.3 list=allowed_DNS
add address=185.228.168.9 comment="Allowed DNS Servers - Cleanbrowsing" list=\
allowed_DNS
add address=10.0.0.0/8 comment="Denied Addresses" list=\
unexpected-src-address-hitting-ISP
add address=127.0.0.0/8 list=unexpected-src-address-hitting-ISP
add address=169.254.0.0/16 list=unexpected-src-address-hitting-ISP
add address=172.16.0.0/12 list=unexpected-src-address-hitting-ISP
add address=192.0.0.0/24 list=unexpected-src-address-hitting-ISP
add address=192.0.2.0/24 list=unexpected-src-address-hitting-ISP
add address=192.88.99.0/24 list=unexpected-src-address-hitting-ISP
add address=192.168.0.0/16 list=unexpected-src-address-hitting-ISP
add address=198.18.0.0/15 list=unexpected-src-address-hitting-ISP
add address=198.51.100.0/24 list=unexpected-src-address-hitting-ISP
add address=203.0.113.0/24 list=unexpected-src-address-hitting-ISP
add address=233.252.0.0/24 list=unexpected-src-address-hitting-ISP
add address=240.0.0.0/5 list=unexpected-src-address-hitting-ISP
add address=248.0.0.0/6 list=unexpected-src-address-hitting-ISP
add address=252.0.0.0/7 list=unexpected-src-address-hitting-ISP
add address=254.0.0.0/8 list=unexpected-src-address-hitting-ISP
add address=MY-WAN-IP list=unexpected-src-address-hitting-ISP
add address=MY-WAN-IP list=expected-dst-address-to-my-ISP
/ip firewall filter
add action=accept chain=input comment=\
"defconf: accept established,related,untracked" connection-state=\
established,related,untracked
add action=drop chain=input comment="defconf: drop invalid" connection-state=\
invalid
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp
add action=accept chain=input comment="defconf: accept to local loopback" \
dst-address=127.0.0.1
add action=accept chain=input comment="admin access" in-interface-list=LAN \
src-address-list=admin
add action=accept chain=input comment="allow LAN DNS queries-TCP" dst-port=53 \
in-interface-list=LAN protocol=tcp
add action=accept chain=input comment="allow LAN DNS/NTP queries-UDP" \
dst-port=53,123 in-interface-list=LAN protocol=udp
add action=accept chain=input comment="allow WireGuard" dst-port=23231 log=\
yes protocol=udp
add action=drop chain=input comment="drop all else"
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,untracked" connection-state=\
established,related,untracked
add action=drop chain=forward comment="defconf: drop invalid" \
connection-state=invalid
add action=accept chain=forward comment="internet access" in-interface-list=\
LAN out-interface-list=WAN
add action=accept chain=forward comment="port forwarding" \
connection-nat-state=dstnat log=yes
add action=drop chain=forward comment="drop all else"
/ip firewall nat
add action=dst-nat chain=dstnat comment=\
"SyncServer - LetsEncrypt Cert Renew (enable during renewal only)" \
disabled=yes dst-address-list=expected-dst-address-to-my-ISP \
dst-address-type=local dst-port=80 log=yes protocol=tcp to-addresses=\
server.IP to-ports=80
add action=src-nat chain=srcnat comment=\
"LAN masquerade & also hide LAN addresses" out-interface-list=WAN \
src-address-list=expected-address-from-LAN to-addresses=MY-WAN-IP
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address-list=\
expected-address-from-LAN out-interface-list=LAN protocol=tcp \
src-address-list=expected-address-from-LAN
add action=redirect chain=dstnat comment=\
"Redirect DNS to Mikrotik DNS Server - TCP" dst-port=53 \
in-interface-list=LAN protocol=tcp
add action=redirect chain=dstnat comment=\
"Redirect DNS to Mikrotik DNS Server - UDP" dst-port=53 \
in-interface-list=LAN log=yes protocol=udp
add action=dst-nat chain=dstnat comment="SyncServer - HTTPS" \
dst-address-list=expected-dst-address-to-my-ISP dst-port=port log=yes \
protocol=tcp to-addresses=Server.IP to-ports=port
add action=dst-nat chain=dstnat comment="SyncServer - OpenVPN" \
dst-address-list=expected-dst-address-to-my-ISP dst-address-type=local \
dst-port=port log=yes protocol=tcp to-addresses=Server.IP \
to-ports=port
/ip firewall raw
add action=drop chain=prerouting comment="ISP - AT&T Fiber - ether1 - drop all\
\_internet traffic (enable for testing only)" disabled=yes in-interface=\
ether1
add action=drop chain=prerouting comment=\
"drop non-legit src-addresses hitting WAN side" in-interface-list=WAN \
src-address-list=unexpected-src-address-hitting-ISP
add action=drop chain=prerouting comment=\
"drop non-legit dst-addresses hitting WAN side" dst-address-list=\
!expected-dst-address-to-my-ISP in-interface-list=WAN
add action=drop chain=prerouting comment=\
"drop non-legit traffic coming from LAN" in-interface-list=LAN \
src-address-list=!expected-address-from-LAN
add action=accept chain=prerouting comment="allowed DNS" src-address-list=\
allowed_DNS
add action=accept chain=output dst-address-list=allowed_DNS
add action=add-src-to-address-list address-list=\
expected-dst-address-to-my-ISP address-list-timeout=none-static chain=\
output comment="get ISP dhcp-client IP address & add to expected-dst-addre\
ss-to-my-ISP list" out-interface-list=WAN src-address-type=local
add action=add-src-to-address-list address-list=\
unexpected-src-address-hitting-ISP address-list-timeout=none-static \
chain=output comment="get ISP dhcp-client IP address & add to unexpected-s\
rc-address-hitting-ISP list" out-interface-list=WAN src-address-type=\
local

anav · Tue Jan 02, 2024 11:04 pm

Well will focus on DNS related rules........
In general the Device acting as DNS server has to have access to the internet to get DNS itself.
EVEn a DOH servers needs some unencrypted DNS access to make the initial connection to an encrypted DOH server.

So in general, one has to look at
DNS servers in DHCP Network Server
IP DNS rules
and DSTNAT RULES
and even forward chain rules to ensure users are allowed to go to the DNS server etc..

So looking at it quickly
you use redirect so that any DST NAT attempts by users will go through the router. Okay
You allow access to DNS router services in input chain.... Okay
You allow access to external servers and 1.1.1.1 and 1.0.0.2 are okay and not the problem Okay
You allow access to external server 185.228.168.9 is also okay as it looks to be another DNS service.......

So quickly I see nothing untoward........... What happens when a user uses google in a browser search or google mail or something like that, perhaps eventually a google resolver down the line gets involved ????

MTNick · Tue Jan 02, 2024 11:31 pm

You allow access to external server 185.228.168.9 is also okay as it looks to be another DNS service....... Yes just in case Cloudflare is down.

So quickly I see nothing untoward........... What happens when a user uses google in a browser search or google mail or something like that, perhaps eventually a google resolver down the line gets involved ????

Thanks for looking over it. Appreciate the assistance! When I change my DNS on my laptop to 8.8.8.8, go to https://1.1.1.1/help, it verifies that I am using Cloudflare resolvers. So it does work as intended. I didn't think to try that before posting.

Connected to 1.1.1.1 Yes
Using DNS over HTTPS (DoH) No
Using DNS over TLS (DoT) No
Using DNS over WARP No
AS Name Cloudflare
AS Number 13335
Cloudflare Data Center ORD

Turning the firewall rule off, it is no longer using Cloudflare but Google instead. The rule definitely works:

Debug Information
Connected to 1.1.1.1 No
Using DNS over HTTPS (DoH) No
Using DNS over TLS (DoT) No
Using DNS over WARP No
AS Name Google
AS Number 15169
Cloudflare Data Center ORD

anav · Wed Jan 03, 2024 2:14 am

It is not clear what firewall rule you are talking about??

MTNick · Wed Jan 03, 2024 3:52 am

It is not clear what firewall rule you are talking about??

Greetings Anav,

This one, specifically the udp:
/ip nat
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=tcp
add action=redirect chain=dstnat dst-port=53 in-interface-list=LAN protocol=udp

anav · Wed Jan 03, 2024 4:37 am

Ah okay, I think of that as NAT RULE, as opposed to a MANGLE rule as opposed to filter rules (forward and input chain).
All other IP firewall. LOL.

Force Users to Use Specific DNS Server

Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Re: Force Users to Use Specific DNS Server

Who is online