I have a NAT rule on my main LAN and WireGuard networks, with a corresponding outbound NAT for redirecting DNS requests to the Internet back into my Pi-Hole. This works really well and have no issues - well except one. I want to block this for a couple of devices on then LAN network as they are basically spamming the DNS servers.
So I added a floating rule for just the LAN network, that blocks just those devices - I used a floating rule as I thought looking at the GUI, that these take precedence over the rule generated for the NAT. This doesn't seem to be the case as these devices do not get blocked, and if I enable logging nothing appears.
However, if disable the NAT rule that redirects the requests which is lower in the list of rules, the new block rule takes effect and I see the devices being blocked - at least I hope that's what it is doing.
This is what is shown in the Diags, Statisics Rules for the above two sets of rules, I couldn't think of an easier way to capture the rules without using screenshots:
filter rules
@43 block drop in log quick on vtnet0 inet proto tcp from <External_Blocked_DNS:2> to ! <Local_Networks:3> port = domain label "aed73360b88f4da3639fdefc10265301"
@44 block drop in log quick on vtnet0 inet proto udp from <External_Blocked_DNS:2> to ! <Local_Networks:3> port = domain label "aed73360b88f4da3639fdefc10265301"
nat rules
@25 no rdr on vtnet0 inet proto tcp from <Internal_DNS:9> to any port = domain
@26 no rdr on vtnet0 inet proto tcp from <Internal_DNS:9> to any port = domain-s
@27 no rdr on vtnet0 inet proto udp from <Internal_DNS:9> to any port = domain
@28 no rdr on vtnet0 inet proto udp from <Internal_DNS:9> to any port = domain-s
@29 no rdr on wg0 inet proto tcp from <Internal_DNS:9> to any port = domain
@30 no rdr on wg0 inet proto tcp from <Internal_DNS:9> to any port = domain-s
@31 no rdr on wg0 inet proto udp from <Internal_DNS:9> to any port = domain
@32 no rdr on wg0 inet proto udp from <Internal_DNS:9> to any port = domain-s
@33 rdr on vtnet0 inet proto tcp from (vtnet0:network:2) to ! <Internal_DNS:9> port = domain -> <RALPH> port 53 round-robin
@34 rdr on vtnet0 inet proto tcp from (vtnet0:network:2) to ! <Internal_DNS:9> port = domain-s -> <RALPH> port 53 round-robin
@35 rdr on vtnet0 inet proto udp from (vtnet0:network:2) to ! <Internal_DNS:9> port = domain -> <RALPH> port 53 round-robin
@36 rdr on vtnet0 inet proto udp from (vtnet0:network:2) to ! <Internal_DNS:9> port = domain-s -> <RALPH> port 53 round-robin
@37 rdr on wg0 inet proto tcp from (vtnet0:network:2) to ! <Internal_DNS:9> port = domain -> <RALPH> port 53 round-robin
@38 rdr on wg0 inet proto tcp from (vtnet0:network:2) to ! <Internal_DNS:9> port = domain-s -> <RALPH> port 53 round-robin
@39 rdr on wg0 inet proto udp from (vtnet0:network:2) to ! <Internal_DNS:9> port = domain -> <RALPH> port 53 round-robin
@40 rdr on wg0 inet proto udp from (vtnet0:network:2) to ! <Internal_DNS:9> port = domain-s -> <RALPH> port 53 round-robin
External_Blocked_DNS is the two host aliases of the devices, I've tried adding them directly as well
Local_Networks are all my local subnets e.g. 192.168.1.0/24
Internal_DNS are the IPs of my DNS servers
Implicit NAT "pass" rules are always evaluated even before floating rules. You need to associate a firewall rule to the NAT rule and then prioritize it if you want it otherwise.
Ok, I see, but what do you mean by "associate a firewall rule to the NAT rule and then prioritize it"?
See "Filter rule association" here: https://docs.opnsense.org/manual/nat.html, then go to firewall rules and move the created rule where you want it to be. But that only applies to inbound NAT (port forwarding).
For your application, you would need to create a firewall alias containing your exceptions and then create a outbound NAT rule using this alias as the source preceeding your normal NAT rule with the option "Do not NAT" (see the help text: "Enabling this option will disable NAT for traffic matching this rule and stop processing Outbound NAT rules. Hint: in most cases, you won't use this option.").
But my NAT rule already has an associated rule assigned, it's not set to "pass".
Screenshot 2025-05-06 134649.pngScreenshot 2025-05-06 134545.png