Thanks, though I didn't understand where you were going with the suggestion. I do know that when I was using our Wi-Fi router for DNS and DHCP services, this was super-simple: if a device can connect to the Wi-Fi router, then it could get an IP address and DNS would just work. Didn't matter if the computer was from our home, my work, my wife's work, or a guest. And nobody wants to have to configure different setups for every eventuality.
As far as DHCP, Windows is picking up and using the IP address (and gateway and mask) that it is being given, and only the DNS part is the bother. Use Pi-hole for DNS, and it fails (or is locked out?)... use any other DNS (1.1.1.1), and voila... connectivity. But no Pi-hole goodness.
Also, your reply seems to fade out at the end, in the middle of saying something about "CONSULTING-AG.loc..." ... don't know what that is about.
Thanks
Pat Furrie
It's a link, and only a preview of the content is shown. Click the blue link to load the original post.
I posted a similar problem the other day, and the response was to direct me to this thread.
First let's start with some of the text of what I posted:
Expected Behaviour:
That Pi-hole would provide DNS services to my computer from work.
This is on a Windows 11 computer which is from my work and is configured for Active Directory at that location.Actual Behaviour:
The computer is receiving an IP address, gateway address, netmask, and DNS address (the Pi-hole server). However, the computer can't reach Internet services as name resolution is not happening. I can verify all the addresses are present, but at the command line I try a simple ping of "www.google.com" and I get the "Ping request could not find host www.google.com." Then I go to the network settings and change the DNS type to manual and enter 1.1.1.1, go back to the command line window, and repeat the ping attempt. This time it resolves Google instantly and pings happen as expected. Obviously Pi-hole doesn't like to play with my work computer.
While there's talk in this thread of this being a Microsoft problem, I dispute that. Prior to using Pi-hole (about a week ago), all DNS here was handled by our home router. Windows never had a problem with my work computer (which is configured for an Active Directory domain).
With so many people who are working from home now, we'd have to expect them to bring home their work computers. In my office alone, we had hundreds of people going home with their work computers. They all worked fine on their networks... expect now for me (because I'm the only one using Pi-hole).
Was this actually not a problem prior to some update to Pi-hole in December? Is the only way for Pi-hole users to "fix" this to do some manual config file hacking for every computer that they might use that has its own configured domain? How is lack of DNS services to a validated DHCP client not being caused by Pi-hole?
Does your router have Rebind Protection enabled?
@DanSchaper - Interesting... never heard of "rebind protection" before. Did a cursory search (on that topic and on whether or not a Netgear Nighthawk 7000 router has that option). Not seeing the option... and also don't understand how that would impact this situation.
Anything? How is rebind protection on my router going to be applicable to the issue I'm seeing?
On another note...
Looking through this thread, I see mention of editing:
/etc/dnsmasq.d/99-domains.conf
Is this do-able from within the Pi-hole web GUI? In my case, Pi-hole is running in a Docker container (from Pi-hole), and as best I can tell I don't have access to edit any files within its locked container. The only apparent access is through the application UI.
I've moved your cross posts from Ignoring domain CONFIG_DOMAIN for DHCP host name HOSTNAME back to your original issue, as that other topic has been marked as solved.
If your issue still persists and the accepted solution would not work for you, then you are likely observing a different issue.
In that case, please provide a new debug token.
You edit it from the terminal/CLI of the Linux operating system you're using.
Apologies. Missed the Docker part. You could try:
docker exec -it bash
to access the shell, but I'm no Docker expert. #justenoughtobedangerous
Still would apply to Docker, and indeed could be edited directly from the Docker host OS, but exact file locations would depend on the volume mount configuration of the Pi-hole container (see also our sample Docker configuration).
Okay, I'm circling back around on this. Going back over all the other suggestions, but not seeing any answers. To review:
Prior to setting up Pi-hole, my Netgear Nighthawk 7000 Wi-Fi router allowed any computer that had valid Wi-Fi access (had the appropriate code) to connect to DHCP and get an IP address. It worked.
Since setting up Pi-hole, none of our work computers can get a DHCP IP address.
For my work computer, I deal with it by assigning a static IP address, though this is not ideal. Recently went back to work and then took a while to remember my computer had a static, wasting more time. Needs to be dynamic on both sides.
For my wife and my daughter, both of their work computers are locked down from their respective companies, so manually entering IPs is not even an option.
The only difference here is the addition of Pi-hole to the network. We know that is the sore spot.
I'm suspecting this is by-design, either of Pi-hole or of dnsmasq. But there has to be a reasonable work-around. This isn't an unique situation -- lots of people are now bringing their work computers home. Nearly all of them will be attached to some other domain. And all of them need connectivity, even the ones in homes running Pi-hole.
If I edit the /etc/dnsmasq.d/99-domains.conf file, what does that edit involve?
So much of Pi-hole is well-done and work great from the web GUI, so it is a bummer to get to the point where the last little important bit is relegated to being done with some arcane editing in a hard-to-reach file and doing it all with command line, and any reference to what should actually be entered is a second-hand reference to some other post that may (or may not be) relevant to the current situation. Here's the part from that other conversation thread that might apply, written by DL6ER:
The idea could be to add a new file
/etc/dnsmasq.d/99-domains.confand adddomain=CONSULTING-AG.local,192.168.2.123where the
CONSULTING-AG.localis the domain that Pi-hole complains about and192.168.2.123the address of the machine that is allowed to take it (please change this address!). @kzi has to use a different domain (cora-management.lcl). Thenpihole restartdnsand fingers crossed!
Okay, if that is the proper part to do, I still have a question: where it says "... and 192.168.2.123 the address of the machine that is allowed to take it," what does that mean? It looks like I'm associating some "foreign" (non-local) domain to some static IP address. In our situation, is that the work computer we have at home? And the IP address is the address we're going to give it? Or is it the address the machine already has? The latter doesn't make sense (if the machine already has an IP address, why would I need to go through this), but the former isn't what we want to do either, since the whole idea is to have the computer be handed an address automatically from the available DHCP scope. So what is the point of the address? (and yes, I understand that the 192.168.2.123 address was an example, and I would have used a different IP address on my own subnet).
And.... does this have to be done every time a friend shows up with a different computer from some different domain, and there is no connectivity until we go through a bunch of steps to make the network work for that one computer? If so, this doesn't seem like a solution.
The parts of Pi-hole that work are great. I love being able to provide detailed static DHCP leases to non-mobile devices in our home, and to setup hostname aliases for those devices, and have everything reachable on the network by hostname because everything resolves very nicely. I'm a sucker for the great graphs provided by the program, and the logging and diagnostics are on-point. This is my favorite containerized application.
Still, I'm considering rolling back to our generic Netgear wireless router to handle DHCP duties. That would kill all the nice DHCP-to-DNS integration Pi-hole allows us to do. We have to have dynamic IP assignments, even with our work computers from other domains.
Have you considered putting your work computer(s) on a guest network, separate from Pi-hole?
In the topic that has been linked, the OP was just annoyed about seeing a warning (if the same warning that you've reported):
Yours differs in that you seem to observe a loss of functionality, though we didn't have a chance to establish a reason for that, or how it would be related to Pi-hole.
That is what prompted me to bring your posts back to your original issue 8 days ago:
EDIT:
As there seems to be an issue with Discourse trying to alter the debug token link to its intended target upon inserting it into a post, please share just the token code (e.g. for https://tricorder.pi-hole.net/aCeG0248/ , this would be aCeG0248).
Our guest network runs off the same Wi-Fi router, and there is no capability to run separate DHCP for that network. Sure, I suppose I could buy another Wi-Fi router and set it up a guest network that way. But here are my thoughts about that:
- Our work computers will be on a guest network that then won't have access to anything other than the Internet. Can't access, well, anything. That's part of the point of guest network.
- Can't manage all wireless networks with a single pane (like Pi-hole).
- Have to buy, setup, and wire-in another router. Since the guest network would need to be isolated from the rest of the network, would have to put that router downstream from the regular router. And that adds one more point for problems to occur.
..... and other problems....
No, I haven't considered it.
Here is a new debug token: (I love this function... wish more software would have an option like this)
EsLcJQ19
I just fired up my work laptop (Windows 11). It connects to Wi-Fi, no problem. It gets a DHCP address from Pi-hole fine. When a command prompt is opened, IPCONFIG shows an IP in the normal DHCP scope range. Good. Also shows the DNS server is set to the Pi-hole server address.
Then try to run a ping of www.google.com. Nope. Can't resolve it. Try opening Chrome and going to websites. Well, part of Google shows, but it is my homepage and due to the frequency of the parts being used, everything there is cached. Trying to go to any non-cached pages ends up with bupkis. YouTube shows some navigation elements (cached) but the main section says "Connect to the internet. You're offline. Check your connection."
Open Windows control panel, network and sharing center, change adapter settings, open properties of my network adapter, open properties of the IPv4 item, change DNS from auto to "use the following DNS" and enter the IP address of the Wi-Fi router (which still has DNS running, but Pi-hole isn't setup to use that address when handing out DHCP leases). Check IPCONFIG, and yep, the computer has the new DNS configured... annnnnnd...
Bingo. Now I can get to all the sites that I couldn't before. Name resolution works.
It isn't that Pi-hole can't resolve names. It can. The computer I'm writing this on right now is a home laptop and it fully configured with Pi-hole to use Pi-hole for DNS. Works fine.
So this is a matter of Pi-hole refusing to resolve for certain computers. It is discriminating against certain devices. Which devices? Apparently anything that is configured as part of some outside domain. My work computer is a proud member of Active Directory at my work. This foreign-ness is apparently contradictory to something in how Pi-hole works, and I'm thinking it is from dnsmasq.
Whew.
Pat
Perhaps some part of your configuration is blocking encrypted DNS traffic? Let me put it this way, some people at work like to see where you're going...
Your debug log shows the warnings you mentioned, but looks inconspicuous otherwise, apart from a few irregularities that seem related to Docker:
*** [ DIAGNOSING ]: Ports in use
*** [ DIAGNOSING ]: Pi-hole-FTL full status
[i] systemctl: command not found
Above may indicate your container would be missing some Linux capabilities.
-rw-r--r-- 1 pihole pihole 147 Feb 12 08:47 /etc/pihole/pihole-FTL.conf
PRIVACYLEVEL=0
REPLY_ADDR4=0.0.0.0
You should consider to set your container's FTLCONF_REPLY_ADDR4 to your Pi-hole's IP.
Please refer to Pi-hole's Docker documentation for details, or share your docker-compose or docker run script for us to take a look at.
Pi-hole would only block specific clients if you'd configured it to do so.
While your group management is configured to treat one client individually, it looks to be correctly set up to lift Pi-hole's filtering for that specific client.
This would suggest a client-side issue instead, so let's take a look at your offending/offended client.
As a side note, ping isn't adequate to analyse DNS issues, as it uses other means in addition to DNS to resolve hostnames. It may give you a reasonable indication for public hostnames like www.google.com you used, but you should prefer nslookup or dig to analyse DNS.
From the machine that you observe resolution failures on while using Pi-hole for DNS, what's the result of the following commands (when Pi-hole is your DNS):
nslookup pi.hole
nslookup flurry.com
Also, watch your Pi-hole's Query Log for DNS requests associated with those lookups (there could be 2 to 4 of them for each command):
Do they register at all when you issue an nslookup?
Okay, I haven't tried any of those steps because I think I've solved the issue. Here's what's going on...
First... my Pi-hole server last octet is .3
Next... the Wi-Fi router last octet is .1
Next... the "guest" network is set to NOT "allow guests to see each other and access my local network.
All of the work computers are configured to connect to the guest network because why would they need to connect to any of our local computing resources?
Why indeed. And therein lies the problem.
The wireless router is doing was it was told: don't let those dirty malware-ridden guest computer access any computers on the network (and the guest Wi-Fi password is WAY easier to enter than the regular Wi-Fi password). Aaaaaaand that would included .3, the Pi-hole DNS/DHCP server.
So, computer connects to the Wi-Fi router (easy), but when it sends out a DHCP request, it is met with silence. No DHCP assignment and no DNS.
This really is a case of me shooting myself in the foot, networkingly-speaking. Now I'm going to need to figure out if there is a clever way around this (at the moment, I'm doubtful). For the near-term, I'll enable guest hosts to have access to the rest of the network, though I don't want to do that for too long. Maybe one of the third-party router firmware packages would allow some fine-tuning of the guest network access so the Pi-hole server could be reached.
Thanks for sticking with me to this point.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.