Redirecting Client DNS Requests doesn't work with WireGuard-Interface

[Bob.Dig]

I have an Interface Group where I do Redirecting Client DNS Requests to AdGuard Home. This works fine for all local interfaces except my WG-VPN-interface for my phone.
I then excluded that interface from the group and gave it its own redirect, still it doesn't work.

Is this to be expected?

The firewall rule get hits where it shouldn't:

I don't use the WireGuard interface group at all.

[giuliafw70]

If the phone is using the pfSense WireGuard address itself as DNS, a redirect/NAT rule will not catch that the same way as normal forwarded traffic. In that case I would either push/use the AdGuard IP directly in the peer config, or make sure the port forward is on the assigned WG interface with source = WG tunnel subnet, destination = not the AdGuard host, dst port 53 TCP/UDP, redirect target = AdGuard.

After changing it, clear states for the phone and test with a simple nslookup example.com <dns-ip> from the phone/client side. The rule hit counter alone can be a little misleading if old states are still active.

[Bob.Dig]

@giuliafw70 said in Redirecting Client DNS Requests doesn't work with WireGuard-Interface:

If the phone is using the pfSense WireGuard address itself as DNS, a redirect/NAT rule will not catch that the same way

Why is that.
Also I am already using the AdGuard host directly because I had to.

[giuliafw70]

Because that packet is not really being routed through pfSense to another host. If the phone asks the WG interface address for DNS, pfSense treats it as traffic to the firewall itself, so the usual redirect/port-forward rule for client traffic is the wrong place to catch it. With AdGuard used directly, I would keep it simple: allow WG net -> AdGuard on 53/UDP+TCP, block WG net -> other DNS if you want enforcement, and check that the peer AllowedIPs/routes actually include the AdGuard address.

[Bob.Dig]

@giuliafw70 said in Redirecting Client DNS Requests doesn't work with WireGuard-Interface:

pfSense treats it as traffic to the firewall itself, so the usual redirect/port-forward rule for client traffic is the wrong place to catch it.

NAT comes before everything else, please read the docs.