Hey all, I’ve patched to 7.19v2, everything appears fine except now my destination nat to self rule doesn’t appear to re-direct DNS traffic..
It’s the strangest behavior.. the firewall NAT rule appears to get hit, I can see the traffic bytes increment for the DNAT rule, however, when I manually change my Host Machines DNS Server to use a Public DNS Server example: (8.8.8.8) ; the NAT rule is not properly re-directing the traffic.. the traffic is allowed to flow directly out the web as at the normal destination (8.8.8.8 port 53 UDP). I can see the traffic session in the firewall as well! even stranger yet… when I put a hard block for UDP/TCP 53 in the forward chain at the top of the Firewall rules, the traffic is still allowed somehow… when I remove the two NAT Rules, the traffic is then hard-dropped by the firewall… I can’t make heads or tails of what is going on here. This worked perfectly prior to 7.18, I’m not sure what to make of it given that the traffic leaves out to 8.8.8.8 when the NAT rule is hit… but when I remove the NAT rule it gets dropped by the Forward chain, I am anticipating the Firewall to perform the NAT to the loopback interface and the DoH Configuration sending the DNS lookup on behalf of the host (That is how this worked prior to whatever code change mucked it up).
If anyone else has ran into this, please advise, I’ve tried the two NAT rules below, again… The NAT Rules are getting HIT! but the firewall is not sending the traffic from itself… it’s just sending the traffic like as if the Client Machines original destination is perfectly fine… which… doesn’t make sense.. When I hard code my Clients DNS Servers to be the loopback interface directly, it works perfectly!
I edited your post and used < / > code tag for code. It makes reading easier. Please use it as it really helps.
According your question:
The first rule captures pure vanilla DNS traffic from VLAN interfaces to 10.50.255.254. Why do you expect that they capture DOH traffic? That traffic is encrypted by HTTPS so it goes over HTTPS to “somewhere”.
The Mikrotik should know to send the DNS Requests towards the DOH Servers, it’s the same thing as me manually pointing my Windows PC TCP/IPv4 Stack at my Loopback interface at 10.50.255.254; it should accomplish the same thing, but, it’s not anymore, that DNAT rule did work perfectly as expected prior to patching, I tested it, worked, infact, it’s still being captured… I can see the rule being hit, but, the mikrotik is no longer sending the traffic on behalf of the host (DoH).
Here’s that configuration:
set allow-remote-requests=yes cache-max-ttl=30m servers=
9.9.9.9,149.112.112.112 use-doh-server=https://dns.quad9.net/dns-query
verify-doh-cert=yes
The certificate for DoH at Quad9 is loaded, it all works.. clients are currently using the router as the DNS Forwarder, the DNS Forwarder is sending to Quad9 via port 443.
so… why does the Destination nat towards the loopback no longer work? what changed? why is the Mikrotik not applying the same logic anymore?
The fact that you saw connections with destination 8.8.8.8:53 listed does not mean that your rules have failed. You should take a closer look at those entries with destination 8.8.8.8:53 that you see in the IP → Firewall → Connections table! Try to double-click on those to open the connection’s details, as well as look at the flags.
If the connections have the “d” flag (or have dstnat listed on the status bar) then your redirection worked. You can check the Reply Src. Address field, the correct IP address 10.50.255.254 of your router should be listed:
The fact that forward rules don’t catch the traffic seems to indicate that the dstnat rules are working correctly.
On different systems and in different scenarios “loopback address” means slightly different things. You shouldn’t assign additional addresses directly to the loopback interface.
There were some problems with certificates becoming invalid/untrusted when upgrading to 7.19 - I would look very closely at that.
OK! I see the problem! Please close this support / help session! This helped! so.. the problem was a lot more straight forward! Looks like Google Chrome, by default, is performing Client Based DOH, which perfectly explains why I am seeing DNS Leaks!
When I look into my PCs Sessions, I do see the NAT working, but, I also see the sessions to TCP port 443 opening from Chrome to 8.8.8.8:443 meaning that the browser is infact encrypting the packets with QUIC!
I am DUMB, this is infact working as intended, it’s interesting that the browser honors my DNS Server and will not use QUIC, this is obviously a Client side issue that is easy to resolve.
