DNS queries from VMware subnet refused.

[alfredo]

Dear Forum,

We run pfsense with DNS resolver for local DNS for all LAN subnets. All previous LAN subnets were OK.
Now, we just added a new LAN subnet with a VMware server on it.

Problem: local pfsense DNS server 10.20.40.1 refuses:

[root@bikery:~] nslookup -debug apple.com
Server:		10.20.40.1
Address:	10.20.40.1:53

Query #0 completed in 1ms:
** server can't find apple.com: REFUSED

Query #1 completed in 1ms:
** server can't find apple.com: REFUSED

Tests done:

ping 8.8.8.8 [and] ping 10.20.40.1 [work]
wget -qO- --no-check-certificate 10.20.40.1 [works]
nc -z 10.20.40.1 53 [works]
nslookup -debug apple.com 8.8.8.8 [works]
nslookup -debug apple.com [refused]

What am I missing here?
Thanks,
Alfredo

[bmeeks]

Check that your new subnet actually has an entry in the ACL (Access Control List) for the DNS Resolver on pfSense. That should be automatically added if you created the new network on pfSense. But if you are simply routing that new subnet through pfSense, then the automatic unbound permission would not be there and thus DNS queries from the subnet would be rejected.

[alfredo]

Services / DNS Resolver / Access Lists has always been empty - not used.

[SteveITS]

@alfredo Is it set to listen on All interfaces?

https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-acls.html
"The automatic ACLs may be disabled using the Disable Auto-added Access Control option on the Advanced Settings tab."

That page also says "networks residing on internal interfaces of this firewall are permitted"...does your new subnet have a gateway configured? If so maybe it thinks it's not internal?

That access list file is /var/unbound/access_lists.conf.

[bmeeks]

@alfredo said in DNS queries from VMware subnet refused.:

Services / DNS Resolver / Access Lists has always been empty - not used.

@SteveITS beat me to the reply. The "default" values that pfSense itself creates when you create interfaces on pfSense won't be shown on that tab. That tab comes into play when you create other subnets not defined on a firewall interface.

We are just wondering how (and where) you created that new subnet. If not on pfSense itself as a new physical interface or VLAN, then you will need to add that subnet to the ACL for DNS Resolver manually. Usually the error you are seeing happens when the requesting IP is not on a "permitted" ACL.

[alfredo]

Thanks so kindly for your replies.

Indeed, cat cat /var/unbound/access_lists.conf , shows a whole bunch of subnets:

access-control: 127.0.0.1/32 allow_snoop
access-control: ::1 allow_snoop
access-control: 10.20.2.0/24 allow 
access-control: 10.20.10.0/24 allow 
access-control: 10.20.20.0/24 allow 
access-control: 10.20.30.0/24 allow 
access-control: 10.20.110.0/24 allow 
access-control: 127.0.0.0/8 allow 
access-control: ::1/128 allow

but not 10.20.40.0/24 which we need...

The subnet is internal on an interface. It does have a gateway set.
So what to do? Just edit that file?

[bmeeks]

@alfredo said in DNS queries from VMware subnet refused.:

Thanks so kindly for your replies.

Indeed, cat cat /var/unbound/access_lists.conf , shows a whole bunch of subnets:

access-control: 127.0.0.1/32 allow_snoop
access-control: ::1 allow_snoop
access-control: 10.20.2.0/24 allow 
access-control: 10.20.10.0/24 allow 
access-control: 10.20.20.0/24 allow 
access-control: 10.20.30.0/24 allow 
access-control: 10.20.110.0/24 allow 
access-control: 127.0.0.0/8 allow 
access-control: ::1/128 allow

but not 10.20.40.0/24 which we need...

The subnet is internal on an interface. It does have a gateway set.
So what to do? Just edit that file?

No, don't edit the file. It is recreated by the pfSense code each time the Resolver service is stopped/started. So any change you make would get overwritten.

Put the needed subnet on the ACCESS LISTS tab in the DNS Resolver settings. That should do it. You may need to restart the Resolver after making the change unless the GUI does it for you. I suspect the GUI will restart it when saving the list update.

[alfredo]

Thanks! That worked. Awesome!