AD domain controller as local DNS, forwarding to PfSense

VPfarr

Hello guys!

My current setup is an AD network with a DC as local DNS. This DC currently forwards DNS queries to external DNS servers (like 1.1.1.1 or 8.8.8.8). The desired configuration is the DC forwarding DNS queries to pfSense which in turn will filter/block the queries using pfBlockerNG or forward them further to an external DNS server, just like the DC currently does.

However when I enter the address of the LAN interface of pfSense in the forwarding settings of the DC, pfSense does get the queries but answers with "refused". The following is an excerpt of a packet capture:

    <IP of DC>.58048 > <IP of pfSense>.53: [udp sum ok] 22754+ A? <DNS name to look up>. (40)
    <IP of pfSense>.53 > <IP of DC>.58048: [udp sum ok] 22754 Refused- [0q] 0/0/0 (12)

As a result, DNS queries take longer than usual or don't work at all because the DC seems to fall back another DNS.
The DNS Forwarder on pfSense is enabled and as far as I can tell correctly configured.

How can I further troubleshoot this, which knobs should be turned? :-)
Any help is apprecated.

KOM

dnsmasq will return to you what it gets from upstream. If it's getting a REFUSED from the DNS it's trying to forward to, it will pass that back to you. You can also get a refused error if there is no route to host, which could mean one of several connectivity issues such as no default gateway or asymmetric routing.

VPfarr

@KOM Thank you for the answer. Alright so that could mean pfSense can't connect to the external DNS, perhaps I need a rule to allow outgoing traffic on port 53? Is this needed and common practice? Because I have 1.1.1.1 set as DNS Server in the general firewall settings, so this isn't returning REFUSED, the default gateway is also set correctly.

Also, is DNS Forwarder really needed in my scenario? I just want to be able to intercept DNS queries with pfBlockerNG. When DNS Forwarder is enabled, 127.0.0.1 shows up as DNS server, which sounds wrong to me.

KOM

You're doing everything correctly. I do the same thing but I use Resolver in forwarding mode. I've read that IPv6 issues can also cause refused errors. I normally disable IPv6 on pfSense as we aren't using it at all.

VPfarr

@KOM said in AD domain controller as local DNS, forwarding to PfSense:

You're doing everything correctly.

You shouldn't be too sure about that

@KOM said in AD domain controller as local DNS, forwarding to PfSense:

I do the same thing but I use Resolver in forwarding mode.

So that would probably be the better thing to do, as I don't really need my pfSense to resolve anything, merely forwarding is required?

IPv6 isn't used here as well.

KOM

@VPfarr There is no basic functional difference between a forwarder and a resolver in forwarding mode. They both accept queries and simply pass them along upstream and then pass the reply back downstream. A resolver operating normally (not in forwarding mode) talks to the DNS root servers to find out who is the authoritative server for that domain, and then the authoritative server for that domain to get the FQDN translated to an IP address.

VPfarr

@KOM okay... but what could the problem be then? The firewall is clearly getting the queries, but when doing a packet capture on the WAN port listening for packets with destination port 53, there are none being sent out. Do I need a rule then?

KOM

No, normally pfSense can do its own DNS without needing any special rules. I've given you everything I know about this issue. Maybe if you back up to the beginning and start with your pfSense version and perhaps screenshots of your LAN/WAN rules, something might become obvious.

You could also try some fixes sch as disabling forwarder and then enabling resolver in forwarding mode. Or just use resolver as is without needing to forward anywhere.

VPfarr

@KOM sorry for the delay. So let's back up to the beginning :-)

pfSense version is 2.4.4-RELEASE-p3.

WAN Rules:

LAN Rules:

You can probably ignore most of the LAN rules like DMZ...

KOM

I don't see anything out of the ordinary. Are you using SSL/TLS with Resolver? Perhaps disable that if enabled, and try different DNS servers to see if the problem persists.