I don't think anyone else has requested the feature before. You can open a feature request on https://redmine.pfsense.org/ with that config example and it shouldn't be too hard to add. Probably not going to make it in the next version, but at some point in the future.

@alexis-girardi said in No DNS resolution on LAN:

if I don’t state a server dig doesn’t send a request

What version of dig are you using? I have seen this on 9.12 versions if dns not in the resolv.conf file, etc.. On windows I have not tried 9.12 on other OSes So you have to place default NS in this file

0_1530008410400_digresolv.png

If you want to validate client dns resolve - you should use its built in client.. Something as simple as a ping for example to validate it can resolve.

@pfkomrad said in Can you implement DNS Round Robin for local IP's?:

Ideally though, this should be hidden from the client

For what possible reason? If you have 2 piholes that resolve the same stuff, then hand them both out to your clients. Any client is going to be smart enough to move to the other listed ns if the first one does not answer.

If you want your piholes to resolve your dhcp clients names - then forward them to pfsense that is acting as your dhcp server.

So clients ask pihole, if asking for www.domain.com and not blacklisted, it forwards to pfsense that resolves it or forwards (however you like it to work - resolving is default pfsense setup). If its a local domain, then pfsense would respond and pi-hole would hand it back to client.

Seems like your overthinking something that is quite simple. I also don't get the need for registration of dhcp in a home setup to be honest. If there is something you want to be able to resolve - why not just make sure its always on the same IP either with static and host override or dhcp reservation and let pfsense register the registration.

Clients can list as many ns as you want.. The only thing you need to be sure of is any and all of the listed ns for the client need to resolve the same stuff. You can point client to say pihole and google and then wonder why sometimes fqdn is blocked and sometimes its resolved. You can never be sure what ns a client will query when you list more than 1, doesn't matter what order you hand them to the client. ALL ns listed on a client need to be able to resolve the same stuff, or block the same stuff, etc. Pointing a client to 1 ns that can resolve local, and another that can not is asking for failure.

@virgiliomi The hostname is in the URL, and it works to update the DDNS. It is just that I see an error message when there is no error.

I am also using the same service for the Custom in IPv4 but it doesn't throw an error message.

@actionhenk
Thank you - and I did as you suggested and got 2.4.4 devel installed now. Also, thanks for your thoughts on using lan. I am going to research that and I did learn something ( very enlightening )- I truly appreciate you

God Bless,

ubernupe

@simpleone said in Unbound DNS Resolver, Domain Overrides to IP across OpenVPN tunnel interface.:

it was simultaneously appending the pfsense’s local domain suffix to those same queries,

That would be your client using suffix search that has nothing to do with unbound. Unbound would never nor could it add a suffix to a query. it is only going to resolve or forward what is asked of it.

And yeah since there is no override for it, yes it would try and resolve it the normal way. You can stop those from happening by changing your zone type to static. I personal think this should really be the default zone type vs transparent.

@thenarc said in DNS setting and redirection:

@mikekoke Well if a device is set to use 8.8.8.8 as a DNS server, you're going to see that in the states. But just seeing it in the states doesn't mean that pfSense is allowing it to use 8.8.8.8. It's saying "This client asked to do a DNS query to 8.8.8.8, but I'm redirecting that query to 127.0.0.1 since you told me to." And from there, unbound (the DNS resolver) takes over and forwards it to 8.8.4.4 since you configured it for forwarding mode.

Thanks again for the clarification is just that I use Pfsense still recently and with some things I still have problems.

@nerkalis see if this helps
https://community.ubnt.com/t5/UniFi-Wireless/UniFi-AP-Pro-DHCP-Server-and-Cisco-HelperAddress/td-p/1162821

So this occurred again this morning, looks like after some further troubleshooting this is related to my OpenVPN setup. I have one vlan funneling all traffic out PIA VPN (Guest network) while the rest is processed normally. I don't know why yet, but it appears when this tunnel bounces DNS traffic from PFSense is gobbled up. Local DNS works fine so just external revolvers are broken.

(NOTE: I went back an UNCHECKED the "Do Not Pull Routes" option)
I would say this issue is now resolved, thanks for throwing ideas out there with me...sometimes I'm not the brightest crayon in the box and am about as bright as a burnt out light bulb 😂 but with a little help my brain starts to rattle a bit and eventually bounces onto a good idea or two haha

Thanks again for the help!

Well, I am still a tiny bit confused about its behaviour in a couple of ways.
I am sure if my knowledge was better, I could do it through pfSense.

I appreciate all of your help and advice up to this point, and I take your points around "not do whatever this stuff is on your local network" 😉

In any case, I found that server 2016 does have some filtering capability, but only through powershell. Asked the question over on serverfault here and was able to come up with a solution.
I now have my DC setup to ignore any DNS queries from this client that are not for my internal domain name. This allows the client to then use the secondary DNS server specified for external resolution, which I already know goes over my VPN.

So scrapping unbound on pfSense, I am able to do what I need. It just isn't as clean as I would have liked, but as long as I don't make any infrastructure changes, it will continue to work! Happy days!

Eds

@beremonavabi said in pfsense self routing (unable to update/route):

@jrgx19
I could be wrong, but it sounds like an issue I brought up a while ago:

https://forum.netgate.com/topic/115760/firewall-traffic-needs-redirect-gateway-def1-to-route-thru-vpn

Hopefully, that link will be of some help.

Thank you @beremonavabi. This did the trick for me. the firewall is now able to route all its traffic via the VPN. The only thing I noticed is that the Gateway for that specific VPN client shows as being Offline. However, the client instance status shows it up/connected/ w/IP. I am also able to route traffic through it. Seems a bit odd

I know this topic is very old but I ran into this issue today for an LTS security system. A solution that worked for me was to run the host command on checkip.dyndns.org from the CLI to get the list of IPs associated with it. In this case they were: 216.146.43.71, 162.88.100.200, 216.146.38.70, 162.88.96.194, 131.186.113.135, 131.186.113.136. I then created an alias to contain those IPs and placed that alias in the Bypass lines for Squid. I also placed the NVR IP in the bypass. That allowed the correct IP to be pulled.

To be honest I don't really know the ramifications of disabling the x-forward and this is similar to the solution I use to get the Intuit downloaders to work for Quickbooks so I thought it would be a good shot. Hope this helps someone along the way.

@kpa

That is not the only way.. That will not work in the case of a proxy for example. I my home box all the time from work using it, and behind a proxy.. So it tunnels over tcp in that case.

It uses multiple methods none of which require the user to configure inbound port forwarding.