RB5009 -> RB5009 DNS FWD doesn't work

ungo · Wed Apr 30, 2025 12:29 am

Been at this all day, can't figure it out.

I have a site-to-site wireguard VPN tunnel set up for a few years, running great.

I have recently been redoing my DNS for my two sites. I have two sites:

Site 1: shire - 172.16.0.0/16
Site 2: mordor - 192.168.0.0/24

I have the dns server running on each of the RB5009 that is the gateway for each network. Shire DNS server successfully resolves all *.shire lookups. Mordor likewise handles all *.mordor lookups. No worries there.

I put in a rule in shire DNS to forward any *.mordor requests:

add forward-to=192.168.0.1 match-subdomain=yes name=mordor type=FWD

From shire LAN,

nslookup gw.mordor

times out. I can see in the shire router logs that it's being forwarded to 192.168.0.1, but I don't see any corresponding logs in mordor that it received the DNS request.

From shire LAN,

nslookup gw.mordor 192.168.0.1

(directly querying the mordor dns server) succeeds, and I see the dns query and response in mordor logs.

I thought it might be a firewall issue, but on each of the routers I have a rule:

add action=accept chain=input comment="allowed IPs -> router" src-address-list=allowed_to_router

where the address list allowed_to_router includes the remote subnet.

As I understand it, this will let anything from the remote subnet into the router, including to the DNS server, regardless of port, etc.

What might I be missing?

TIA for advice. I ran Claude.ai ragged with this, it wasn't much help.

Wed Apr 30, 2025 1:28 am

Read this
viewtopic.php?p=1136393#p1136393
and follow up here:
viewtopic.php?t=216006

ungo · Wed Apr 30, 2025 12:32 pm

Read this
viewtopic.php?p=1136393#p1136393
and follow up here:
viewtopic.php?t=216006

Thanks for the reply BartoszP. I read through both threads. I'm hoping to accomplish the same thing. However, FWD requests do get sent from shire to mordor (as seen in shire logs), however they never make it to mordor.

When I query mordor dns directly from the shire subnet (from a DHCP client) which is certainly routed over the wireguard tunnel through the shire router to the mordor router, it works! I see the query in the mordor logs, I get the static A entry in mordor as expected.

My pain point and what I can't figure out is why does the dns request work when coming from a shire subnet DHCP client, but NOT when coming from the shire dns server itself as a FWD request?

Wed Apr 30, 2025 12:36 pm

No configs, no answer ... it's hard to predict what happens if do not know if DNS trafic reaches DNSes and the answer goes back and reaches the target?
Do you have proper routing set?

ungo · Wed Apr 30, 2025 1:02 pm

I set up the routing as outlined in this guide: https://help.mikrotik.com/docs/spaces/R ... uardtunnel

I did have the remote site go through a 10.255.255.0/30, I think due to an old guide, but changed the remote route to go directly to the wireguard1 interface during my troubleshooting yesterday. Both work for normal routing site-to-site.

Here's all the relevant configs I can think of. The key point I want to make is that I can query the mordor dns server from my shire LAN, but FWD requests from shire router don't make it to the mordor dns server.

shire subnet: 172.16.0.0/16
shire gateway/dns server: 172.16.0.1

mordor subnet: 192.168.0.0/24
mordor gateway/dns server: 192.168.0.1

shire routing table:

/ip/route> print
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC, v - VPN
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#     DST-ADDRESS       GATEWAY       DISTANCE
0  Xs 192.168.0.0/24    10.255.255.2         1
  DAv 0.0.0.0/0         pppoe-out1           1
  DAc 172.16.0.0/16     bridge               0
  DAc 172.17.0.0/24     containers           0
1  As 192.168.0.0/24    wireguard1           1
  DAc 192.168.100.0/24  wireguard1           0
  DAc 192.168.200.0/24  vlan-dmz             0
  DAc 10.255.255.0/30   wireguard1           0
  DAc 172.16.16.250/32  pppoe-out1           0

mordor routing table:

/ip route print
Flags: D - DYNAMIC; X - DISABLED, I - INACTIVE, A - ACTIVE; c - CONNECT, s - STATIC;>
Columns: DST-ADDRESS, GATEWAY, DISTANCE
#      DST-ADDRESS        GATEWAY         DISTANCE
0  Xs  172.16.0.0/16      10.255.255.1           1
1  As  0.0.0.0/0          <redacted public IP>         1
2  As  172.16.0.0/16      wireguard1             1
  DAc  172.17.0.0/24      containers             0
  DAc  192.168.0.0/24     bridge                 0
  DAc  192.168.66.0/24    wireguard1             0
  DAc+ <redacted public IPs>  ether1                 0
  ...
  DAc+ <redacted public IPs> ether1                 0
  DAc  10.255.255.0/30    wireguard1             0

I looked closely at the firewall. I include my config here up to the rule that I believe SHOULD ensure that comms from shire router to mordor router.

shire firewall rules:

/ip/firewall> export
# 2025-04-30 10:42:10 by RouterOS 7.18.2
#
# model = RB5009UG+S+
/ip firewall address-list
add address=172.16.0.0/16 comment="shire (LAN) subnet" list=allowed_to_router
add address=192.168.0.0/24 comment="mordor subnet" list=allowed_to_router
add address=172.17.0.0/24 comment="containers subnet" list=allowed_to_router
/ip firewall filter
add action=accept chain=forward comment=TESTTEST dst-address=192.168.0.0/24 src-address=172.16.0.0/16
add action=accept chain=forward comment=TESTTEST dst-address=172.16.0.0/16 src-address=192.168.0.0/24
add action=accept chain=input comment="defconf: established/related connections" connection-state=established,related,untracked
add action=accept chain=forward 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=drop chain=forward comment="defconf: drop invalid" connection-state=invalid log-prefix=invalid
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
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="wireguard server" dst-port=443 in-interface-list=WAN protocol=udp
add action=accept chain=forward dst-address=192.168.0.1 dst-port=53 log=yes log-prefix=DNS-TEST protocol=udp
add action=accept chain=input comment="allowed IPs -> router" src-address-list=allowed_to_router
...
I think all rules enabling dns-to-dns traffic are included above

mordor firewall rules:

/ip firewall export
# 2025-04-30 03:47:40 by RouterOS 7.18.2
#
# model = RB5009UG+S+
/ip firewall address-list
add address=192.168.0.0/24 comment="mordor (LAN) subnet" list=allowed_to_router
add address=172.16.0.0/16 comment="shire subnet" list=allowed_to_router
add address=172.17.0.0/24 comment=containers list=allowed_to_router
/ip firewall connection tracking
set udp-timeout=10s
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=forward comment=TESTTEST dst-address=172.16.0.0/16 src-address=192.168.0.0/24
add action=accept chain=forward comment=TESTTEST dst-address=192.168.0.0/24 src-address=172.16.0.0/16
add action=accept chain=forward 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=drop chain=forward comment="defconf: drop invalid" connection-state=invalid
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="WG shire DNS -> mordor DNS" dst-address=192.168.0.1 in-interface=wireguard1 out-interface-list=LAN \
    src-address=172.16.0.1
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="wireguard server" dst-port=443 in-interface-list=WAN protocol=udp
add action=accept chain=input comment="allowed IPs -> router" src-address-list=allowed_to_router
...
I think all rules enabling dns-to-dns traffic are included above

shire dns settings:

I have no concern here, as it's behaving here exactly as I expect. Logs show it is forwarding queries for gw.mordor to 192.168.0.1.

/ip dns export
# 2025-04-30 10:50:45 by RouterOS 7.18.2
#
# model = RB5009UG+S+
/ip dns forwarders
add dns-servers=172.16.1.100 name=pi-hole
add dns-servers=192.168.0.1 name=mordor verify-doh-cert=no
/ip dns
set allow-remote-requests=yes servers=172.16.1.100,1.1.1.1
/ip dns static
add forward-to=192.168.0.1 match-subdomain=yes name=mordor type=FWD
add address=172.16.0.1 comment=defconf name=router.lan type=A
add address=172.16.0.1 name=gw.shire type=A

mordor dns settings:

I have no concern here, as it's also behaving exactly as I expect. Logs show it receiving queries sent directly to it from shire subnet, but logs don't show any queries received when they're forwarded by shire dns server.

/ip dns export
# 2025-04-30 03:53:44 by RouterOS 7.18.2
#
# model = RB5009UG+S+
/ip dns
set allow-remote-requests=yes servers=208.97.48.10,208.97.49.10
/ip dns static
add address=192.168.0.1 comment=defconf name=router.lan type=A
add address=192.168.0.1 comment="Mikrotik Gateway WebUI" name=gw.mordor type=A

Finally, here's the relevant wireguard configs. The wireguard tunnel has no concerns from my perspective.

shire wireguard export:

/interface wireguard export
# 2025-04-30 10:55:09 by RouterOS 7.18.2
#
# model = RB5009UG+S+
/interface wireguard
add listen-port=443 mtu=1420 name=wireguard1
/interface wireguard peers
...
add allowed-address=192.168.0.1/24,10.255.255.0/24 comment="mordor subnet" endpoint-address=<redacted> endpoint-port=443 interface=\
    wireguard1 name=peer4 public-key="<redacted>"
...

mordor wireguard export:

/interface/wireguard/export
# 2025-04-30 03:57:05 by RouterOS 7.18.2
#
# model = RB5009UG+S+
/interface wireguard
add listen-port=443 mtu=1420 name=wireguard1
/interface wireguard peers
...
add allowed-address=172.16.0.0/16,10.255.255.0/24 comment="shire -> mordor" endpoint-address=<redacted> endpoint-port=443 \
    interface=wireguard1 name=peer4 public-key="<redacted>"

jaclaz · Wed Apr 30, 2025 3:42 pm

Here's all the relevant configs I can think of.

Yep, but the issue may lie in the irrelevant (according to you) parts of the configurations, this is why generally the whole configurations should be posted.

Only as a side-side note, it is good practice to keep chains in firewall rules separated, i.e. first all input rules and later all forward rule, this is easier to read for someone checking the configuration but also for the future you that might need to review them in six months or one year time.

ungo · Wed Apr 30, 2025 5:38 pm

Yep, but the issue may lie in the irrelevant (according to you) parts of the configurations, this is why generally the whole configurations should be posted.

I've avoided doing that out of respect of your time and my own. I included the first firewall rules up until add action=accept chain=input comment="allowed IPs -> router" src-address-list=allowed_to_router because that rule allows any relevant subnets access to the router.

If you think an export of the config would help you I'm happy to do it.

At a higher, abstract level, WHERE should I look closer? I don't think it's the firewall, as the rule I quoted above should handle any traffic to and from the dns servers. Routing seems fine, but I've provided the tables. Is it a bug?

jaclaz · Wed Apr 30, 2025 6:38 pm

If you think an export of the config would help you I'm happy to do it.

Yep, likely it is the only way to check holistically everything.

The way RoS settings are organized is extremely (to my eyes) scattered all over the config, and it takes a lot of time to create mental models on how to parse the output of a config, and if an element of this mental model is missing it becomes a guessing game.

Some members here have - besides the knowledge to understand the settings - also the capability of quickly parsing a complete configuration, mentally discarding whatever is actually irrelevant, and it is actually easier for them to check a whole, lengthy (within limits), complete configuration then re-assemble the snippets.

At a higher, abstract level, WHERE should I look closer? I don't think it's the firewall, as the rule I quoted above should handle any traffic to and from the dns servers. Routing seems fine, but I've provided the tables. Is it a bug?

That is a good question, but I have no straight answer to that, actually my bet is more around firewall than anything else, as I see that you have a few non-defconf rules, but really cannot say.

lurker888 · Wed Apr 30, 2025 8:01 pm

@op: You didn't really do anyone a favor by not giving a full config. I don't necessarily agree with @jaclaz that the settings are "all jumbled", but when one doesn't understand a problem, then quite often they don't understand it because they don't know where to look - and only including where you would look is a bit circular. In the future, even if you highlight parts of the config, it would be nice to include the complete one as well, even if only as an attachment.

In your case - most probably - your problem actually lies in what you don't show.

Most probably your DNS query is dropped in the mordor firewall. This is how you can debug it: include a rule for the side making the request (shire) and the receiving side (mordor) and log the relevant packets. This goes something like this:

On shire side:

/ip/firewall/filter/add chain=output protocol=udp dst-port=53 action=passthrough log=yes log-prefix="DNS_OUT"

On mordor side:

/ip/firewall/filter/add chain=input protocol=udp dst-port=53 action=passthrough log=yes log-prefix="DNS_IN"

Put both rules to the very top of your firewall rulesets.

You will - I think - find that the forwarded query comes with a source address you wouldn't expect (most probably from 192.168.100.1) and that's why your fw is dropping it. If I'm not right, then we're one step closer

jaclaz · Wed Apr 30, 2025 9:15 pm

Only for the record, I never said "all jumbled", I said "scattered" which (at least in my perverted mind) is slightly different, it was intended with the meaning of dispersed or spread.

lurker888 · Thu May 01, 2025 12:13 am

If that's your only disagreement with what I said, I'll happily give you that

RB5009 -> RB5009 DNS FWD doesn't work

RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work

Re: RB5009 -> RB5009 DNS FWD doesn't work