Static DNS server replies not handled as "related" by firewall

RouterOS Beginner Basics
1

Hi everyone,
can anyone give me a hint as to why replies from static DNS servers (ISP or Google 8.8.8.:sunglasses: are not handled as “related” by rule 1 but instead I have to make a special rule (5) for them? (The RB serves as DNS server for the local LAN.)


0 chain=forward action=passthrough
1 chain=input action=accept connection-state=established,related,untracked log=no log-prefix=“”
2 chain=input action=drop connection-state=invalid log=yes log-prefix=“”
3 chain=input action=accept connection-state=new in-interface=!ether1 log=no log-prefix=“”
4 chain=input action=accept src-address-list=allowed-list in-interface=ether1 log=no log-prefix=“”

5 chain=input action=accept protocol=udp src-port=53 log=yes log-prefix=“”

6 chain=input action=drop log=yes log-prefix=“”
7 chain=forward action=fasttrack-connection connection-state=established,related log=no log-prefix=“”
8 chain=forward action=drop connection-state=invalid log=yes log-prefix=“”

2

They are marked as “established” in the connection tracking table…right?

3

May sound stupid but recreate your established and related rule as a totally new rule, drag it to the top and then see if it works. Had this very recently and the only reason I could think was #mikrotik.

4

I think only TCP connections can be “established”.
“Related” is a virtual state used for tracking UDP (stateless) connections.

5

alas, it didn’t work - anyway, thanks for a promising hint.
I thought this might be timed-out answers but a DNS server time-out increase did not help either.
It seems to be very regular to be some artifact…

6

Can you please share your full /export hide-sensitive ? How are these dns requests made? By clients with router set as DNS-Server or directly from client to google-dns (or others)?

7

proto UDP, <1st ISP DNS server>:53->:5678, len 323
proto UDP, <2nd ISP DNS server>:53->:5678, len 80
proto UDP, <3rd ISP DNS server>:53->:5678, len 80
proto UDP, 8.8.8.8:53->:5678, len 80
proto UDP, 8.8.8.8:53->:5678, len 80

I should mentions that is a private one and my ISP is port-forwarding all traffic to it from my public IP

8

Yes… i forgot we were talking about DNS requests

9

Udp can have connection-state=established too. The protocol doesn’t have any connection as tcp does, but connection tracking sees it that way when there are packets with matching source and destination addresses and ports.

10

Sob i don’t think inside connections we will see any UDP connection marked as established…

11

With these rules:

/ip firewall filter
add action=log chain=output dst-address=8.8.8.8 log-prefix=request
add action=log chain=input connection-state=established log-prefix="response established" src-address=8.8.8.8
add action=log chain=input connection-state=invalid log-prefix="response invalid" src-address=8.8.8.8
add action=log chain=input connection-state=new log-prefix="response new" src-address=8.8.8.8
add action=log chain=input connection-state=related log-prefix="response related" src-address=8.8.8.8

This command (which needs to send DNS request):

/ping forum.mikrotik.com

Produces this log:

21:10:18 firewall,info request output: in:(unknown 0) out:internal, proto UDP, 192.168.80.183:33734->8.8.8.8:53, len 64 
21:10:18 firewall,info response established input: in:internal out:(unknown 0), src-mac fe:00:c0:a8:50:04, proto UDP, 8.8.8.8:53->192.168.80.183:33734, len 80

So accepting established should be enough.

12

Btw, for OP, this :5678 everywhere looks very suspicious, DNS queries should have random source port.

13

OK guys, I found out that these strange/bogus “DNS replies” to port 5678 (neighbor discovery) stopped as soon as I turned off “internet detection”. I assume it probed Google 8.8.8.8 and/or DHCP-acquired DNS servers.
Thanks