DNS from CRS310 -> RB5009 over SPF fails. RB5009 doesn't;t answer requests

RouterOS General
1

I have a RB5009 connected to a CRS310 via SFP using fiber. The system has been working great for over a year. However there is one issue that I (and AI) haven’t been able to to solve.

I’m using VLAN’s and all LAN connection are via the CRS310. RB5009 has only the CRS310 connected.

I can ping and query DNS from any node in the LAN. However, DNS from the CRS to WAN/LAN fails. Using sniffer, it seems the RB5009 receives the request, but never replies.

This prevents me from checking for updates on the CRS310 because it can’t resolve the server name.

I can dump config info, just tell me what you need, so I can keep the content concise :slight_smile:

Thanks for any help/popinters on how to track this down.

lion (192.168.10.1) == RB5009, lionden == CRS310(192.168.10.3)

[admin@lion] > system resource print
uptime: 47m27s
version: 7.21.2 (stable)
build-time: 2026-01-29 09:54:48
factory-software: 7.8
free-memory: 792.4MiB
total-memory: 1024.0MiB
cpu: ARM64
cpu-count: 4
cpu-frequency: 350MHz
cpu-load: 1%
free-hdd-space: 873.6MiB
total-hdd-space: 1024.0MiB
write-sect-since-reboot: 5520
write-sect-total: 1506404
bad-blocks: 0%
architecture-name: arm64
board-name: RB5009UG+S+
platform: MikroTik

[admin@lionden] > system resource print
uptime: 46m51s
version: 7.20.4 (stable)
build-time: 2025-11-05 12:07:41
factory-software: 7.11
free-memory: 195.0MiB
total-memory: 256.0MiB
cpu: ARM
cpu-count: 2
cpu-frequency: 800MHz
cpu-load: 4%
free-hdd-space: 18.8MiB
total-hdd-space: 32.0MiB
write-sect-since-reboot: 94
write-sect-total: 13442
architecture-name: arm
board-name: CRS310-8G+2S+
platform: MikroTik

Simple test:

[admin@lionden] > put [resolve coyote.isa38.com]
[admin@lionden] > put [resolve google.com]
failure: dns server failure
[admin@lionden] > ping 192.168.10.1
SEQ HOST SIZE TTL TIME STATUS
0 192.168.10.1 56 64 466us
1 192.168.10.1 56 64 429us
sent=2 received=2 packet-loss=0% min-rtt=429us avg-rtt=447us max-rtt=466us

Here is sniffer from the CRS310 (aka lionden)

[admin@lionden] > /tool sniffer quick interface=MGMT-10 port=53
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE TIME NUM DIR SRC-MAC DST-MAC SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU
MGMT-10 192.103 220 -> D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 192.168.10.3:36516 192.168.10.1:53 (dns) ip:udp 77 0
MGMT-10 192.104 221 -> D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 192.168.10.3:52208 192.168.10.1:53 (dns) ip:udp 77 0
MGMT-10 192.114 222 -> D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 192.168.10.3:40728 192.168.10.1:53 (dns) ip:udp 77 0
MGMT-10 192.114 223 -> D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 192.168.10.3:47876 192.168.10.1:53 (dns) ip:udp 77 0
MGMT-10 194.087 224 -> D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 192.168.10.3:58606 192.168.10.1:53 (dns) ip:udp 77 0
MGMT-10 194.087 225 -> D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 192.168.10.3:42503 192.168.10.1:53 (dns) ip:udp 77 0
MGMT-10 194.108 226 -> D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 192.168.10.3:51359 192.168.10.1:53 (dns) ip:udp 77 0

Here is sniffer from the RB5009 (aka lion):

[admin@lion] > /tool sniffer quick interface=bridge-HomeLAN port=53 src-ip-address=192.168.10.0/24 dst-ip-address=192.168.10.0/24
Columns: INTERFACE, TIME, NUM, DIR, SRC-MAC, DST-MAC, VLAN, SRC-ADDRESS, DST-ADDRESS, PROTOCOL, SIZE, CPU
INTERFACE TIME NUM DIR SRC-MAC DST-MAC VLAN SRC-ADDRESS DST-ADDRESS PROTOCOL SIZE CPU
bridge-HomeLAN 2.967 1 <- D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 10 192.168.10.3:60835 192.168.10.1:53 (dns) ip:udp 74 3
bridge-HomeLAN 4.96 2 <- D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 10 192.168.10.3:55473 192.168.10.1:53 (dns) ip:udp 74 2
bridge-HomeLAN 6.962 3 <- D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 10 192.168.10.3:34227 192.168.10.1:53 (dns) ip:udp 74 0
bridge-HomeLAN 8.965 4 <- D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 10 192.168.10.3:52224 192.168.10.1:53 (dns) ip:udp 74 0
bridge-HomeLAN 10.968 5 <- D4:01:C3:C1:95:E4 04:F4:1C:1E:67:4A 10 192.168.10.3:34917 192.168.10.1:53 (dns) ip:udp 74 1

2

Hi
AI does not solve anything ... it just filters and presents you data it gathers from Internet.

What changed? Do you have any idea? DNS? ROS version? It had been working and just stopped or after any your action?

3

I set up the VLAN over a year ago. I don’t generally change much since the system has been very stable. I just recently set up a hacker block list on RB5009 because spammers found my mail server.

I just today noticed I could not update the CRS310 and that led to realization that DNS wasn’t working.

4

So are you sure that there is no coincidence and CRS did not fall into blocked group?

1 Like
5

I tried disabling the firewall rule that blocks hackers - didn't help. But your question made me consider if I have some other firewall rule that was causing problems. And voila!

I had updated the defcon rule (#8 below) to use an address list of VLANs - and critically, forgot to att my MGMT VLAN to the ALL_VLAN list!

I disabled that rule briefly and CRS310 → RB5009 DNS works now!

And it literally took less than 3 minutes before someone started trying to hack into my system - WOW!

login failure for user admin from 87.120.191.13 via api

Apparently 87.120.191.13 is not in the hacker list.

Here is my firewall config. I’d eager to learn what I have done foolishly… Some of this was me trying to learn early on.

Thank you @BartoszP !!

[admin@lion] /ip/firewall/filter> print 
Flags: X - disabled, I - invalid; D - dynamic 
 0  D ;;; special dummy rule to show fasttrack counters
      chain=forward action=passthrough 

 1    ;;; defconf: accept established,related,untracked
      chain=input action=accept connection-state=established,related,untracked log=no log-prefix="" 

 2    ;;; BLOCKED HACKERS
      chain=forward action=drop src-address-list=prod_blocklist in-interface=ether1-WAN log=yes log-prefix="BLOCKED HACKERS" 

 3    ;;; defconf: accept ICMP
      chain=input action=accept protocol=icmp 

 4    ;;; defconf: accept to local loopback (for CAPsMAN)
      chain=input action=accept dst-address=127.0.0.1 

 5    ;;; defconf: drop invalid
      chain=input action=drop connection-state=invalid log=no log-prefix="INVALID-DROPPED" 

 6    ;;; Allow  VLAN access to Router
      chain=input action=accept connection-state=new connection-nat-state="" in-interface-list=ALL_VLAN log=no log-prefix="VLAN-input" 

 7    ;;; WINBOX
      chain=input action=accept connection-state=new protocol=tcp in-interface-list=TRUSTED_VLAN dst-port=8291 log=no log-prefix="WINBOX-INPUT" 

 8    ;;; defconf: drop all not coming from LAN
      chain=input action=drop in-interface-list=!ALL_VLAN log=no log-prefix="WAN-DROPPED" 

 9    ;;; defconf: accept established,related, untracked
      chain=forward action=accept connection-state=established,related,untracked in-interface-list=ALL_VLAN log=no log-prefix="" 

10    ;;; accept new to WAN
      chain=forward action=accept connection-state=new out-interface-list=WAN log=no log-prefix="" 

11    ;;; defconf: accept in ipsec policy
      chain=forward action=accept ipsec-policy=in,ipsec 

12    ;;; defconf: accept out ipsec policy
      chain=forward action=accept ipsec-policy=out,ipsec 

13    ;;; defconf: drop invalid
      chain=forward action=drop connection-state=invalid log=no log-prefix="INVALID-FWD-DROP" 

14    ;;; WINBOX-Forward
      chain=forward action=accept connection-state=new protocol=tcp in-interface-list=TRUSTED_VLAN dst-port=8291 log=no log-prefix="WINBOX-FORWARD" 

15    ;;; Coyote SMTP
      chain=forward action=accept protocol=tcp dst-address=192.168.20.71 dst-port=587 log=no log-prefix="SMTP-FORWARD" 

16    ;;; Coyote IMAPs
      chain=forward action=accept protocol=tcp dst-address=192.168.20.71 dst-port=993 log=no log-prefix="IMAPS-FORWARD" 

17    ;;; Owl HASS
      chain=forward action=accept protocol=tcp dst-address=192.168.20.37 dst-port=443 log=no log-prefix="HASS-443-FORWARD" 

18    ;;; Owl KUMA
      chain=forward action=accept protocol=tcp dst-address=192.168.20.37 dst-port=3001 log=no log-prefix="" 

19    ;;; defconf: fasttrack
      chain=forward action=fasttrack-connection connection-state=established,related 

20    ;;; defconf: drop all from WAN not DSTNATed
      chain=forward action=drop connection-state=new connection-nat-state=!dstnat in-interface-list=WAN log=yes log-prefix="NOT LAN NOT DSTNAT - DROP"
6

If you read this forum long enough, you'll learn that people here normally point out how useless having a "hacker list" and having rules like that one of yours with the comment "BLOCKED HACKERS" is.

The recommendation is that you should stop trying to collect list of external evil hosts to block, and instead, default to blocking access from the outside, only allow remote access via VPN.

And in case of your firewall, if the interface list ALL_VLAN is correct, then your rule with the "BLOCKED HACKERS" is completely useless (unless the hackers are in the LAN and your prod_blocklist also collects LAN addresses).

1 Like
7

I use a DDNS service to provide a domain name and email forwarding so I need to at least allow that in. I think I would do better to lock those ports down by restricting access to only my DDNS provider, who sadly, only does un-authenticated SMTP delivery to me :person_shrugging:

I totally agree on the ridiculous hacker list. They still sneak in between updates. I think I would just need to add the DDNS mail IPs to the firewall rules associated with inbound SMTP?

8

So you should only allow connections from unsafe networks (WAN is definitely one, some VLANs might be as well) only to those services, not everything. API is apparently not one of such services.

Other than that, if you're running public services, the it would be a very good practice to run dedicated servers connected to (heavily firewalled) DMZs. While I can understand the push to run everything on single device (router/firewall) it's hard to make that safe enough ... and often dedicated servers will run services with full features (unlike services on ROS which are most often limited when it comes to functionality).

1 Like