Need a second set of eyes on a DNS drop rule

Sadly, tcpdump is telling me no bueno:

17:51:23.370149 IP 10.41.32.33.33991 > 8.8.8.8.53: 63725+ A? captive.roku.com. (34)
17:51:23.370306 IP 10.41.32.33.45656 > 8.8.4.4.53: 19954+ A? captive.roku.com. (34)
17:51:23.395031 IP 8.8.4.4.53 > 10.41.32.33.45656: 19954 5/0/0 CNAME d1k85ogl73rd7b.cloudfront.net., A 54.192.7.25, A 54.192.7.11, A 54.192.7.209, A 54.192.7.45 (141)
17:51:23.406605 IP 8.8.8.8.53 > 10.41.32.33.33991: 63725 5/0/0 CNAME d1k85ogl73rd7b.cloudfront.net., A 54.192.7.25, A 54.192.7.11, A 54.192.7.45, A 54.192.7.209 (141)

This is all DNS traffic to Google's DNS servers.   I do not know why you would want to block it, nor that you can block it with firewall rules.   

The firewall rules are only activated if traffic bypasses all of the proxies.   (Read the articles in the Wiki section.)   In this case, I think the DNS subsystem acts like a proxy so the firewall rules are not evaluated.

The firewall live log has less data than the full log.   If logging is enabled for a rule, a log entry is created for each packet, and the rule number is in the log entry.   Judicious use of Allow Rule logging can help hunt down unexpected firewall behavior, as long as the packet is actually handled by the firewall rules.

DouglasFoster said:

This is all DNS traffic to Google's DNS servers.   I do not know why you would want to block it, nor that you can block it with firewall rules.

For continuity of discussion I need to force all DNS traffic out through a different egress for filtering.  All stateful firewalls should be able to block this type of traffic.  That is firewall 101.

The firewall rules are only activated if traffic bypasses all of the proxies.   (Read the articles in the Wiki section.)   In this case, I think the DNS subsystem acts like a proxy so the firewall rules are not evaluated.

That is a good tidbit of information that proxied traffic is not evaluated by firewall rules.  Interesting.  However, in this particular case I don't think that the UTM's DNS proxy is in play because the logfile is empty:

(I also don't know where to enable it at)

The firewall live log has less data than the full log.   If logging is enabled for a rule, a log entry is created for each packet, and the rule number is in the log entry.   Judicious use of Allow Rule logging can help hunt down unexpected firewall behavior, as long as the packet is actually handled by the firewall rules.

So this section was really helpful because I was working off of a last match wins and that is incorrect.  First match wins.  Once I moved the DNS drop rule above the any/any rule:

I then started getting matches and more importantly drops:

Thanks for the help!

John

Glad it is fixed.  To correct something that I said:

DNS service is always active, because UTM uses its internal DNS for its own lookup requirements.

However, you can prevent it from servicing other clients by leaving the Allowed Networks list for DNS server empty, which is apparently what you have done.   

This will force the traffic to the Firewall Rules, where it is evaluated from low to high, as you confirmed.

Glad it is fixed.  To correct something that I said:

DNS service is always active, because UTM uses its internal DNS for its own lookup requirements.

However, you can prevent it from servicing other clients by leaving the Allowed Networks list for DNS server empty, which is apparently what you have done.   

This will force the traffic to the Firewall Rules, where it is evaluated from low to high, as you confirmed.