Pihole Blocking Wired but not wireless network

I am running latest Raspian and Pihole versions and Web Admin. My problem is this:

Pihole is blocking ads on wired network but not wireless.

Here's my configuration:

Watchguard Firebox Firewall Router, running two networks in mixed mode
Wired network is 192.168.111.2 - 254 , Pihole on this net at static 192.168.111.6
Wireless network is on 192.168.0.100-199, with a Titan Wireless AP being used to distribute Wireless signals
DHCP is handled by the Router on both networks, with DNS servers being the Pihole at 192.168.111.6 for BOTH networks, and Google 8.8.8.8 on both as secondary

I am running pihole -t to see DNS queries in real time. On the wired network, no issues at all. On wireless, I am seeing no requests being made at all, even though on wireless Clients all report the DNS being the Pihole at 192.168.111.6.

I did just update and upgrade the Raspian OS after many months of not doing it. In my latest test, all wireless Clients are still accepting ads and not running queries through the Pihole, although they clearly report the Pihole as being the DNS Server.

Any ideas?

Try remove the google dns

I did that. Same result. The network reports the DNS as 192.168.111.6, but no query through the TAIL is observed and I am getting ads on the wireless.

Reading your post, this is no surprise at all, I'd say. The reason is that you separate your networks and I'd bet there is no routing information that would allow the wireless devices to find any wired devices.

Let me summarize your network and then tell me if I'm right with my assumption:

  • Wired network: 192.168.111.*/24 (/24 translates into subnet mask 255.255.255.0)
  • Wireless network: 192.168.0.*/24 (same subnet mask)

If this is the case and there is no advanced routing configured, the devices on the one network will not be able to see the devices on the other network. If the necessary routing information is there, it should work fine in terms of routing but there might still be a firewall in the wireless AP that prevents what you want from happening.

So let's investigate this together. The first think I'd like you to test if you can:

  1. Ping the Pi-hole (192.168.111.6) from any wireless client
  2. Ping the wireless client you used above from the Pi-hole

Both ways are necessary for the devices to be able to talk to the Pi-hole.

Don't be fooled by the terms "primary" and "secondary"! This will only make your life harder, because you don't know why certain things are happening. I suggest you read an earlier post of mine about this topic:

Thank you for everything. Yes, I can indeed reach the pihole from any wireless client in PING and also ping a wireless client from the Pihole as well. Worked perfectly.

192.168.111.6 being the wired network and the pihole's address, and 192.168.0.103 being the wireless client. Worked both ways. As to "Secondary" DNS, should I just delete the Google 8.8.8.8 from my router settings for DNS?

Okay, thanks also for posting the image. There is anyhow something wrong with your network - you need around 200 milliseconds to reach the device within your network. I get even faster readings when I ping to the other side of the globe (within my home network everything is < 1 milliseconds, regardless if wired or wireless or in between). There seems to be something strange going on. Please test if you can reach Google faster (ping 8.8.8.8).

I see only about 10 milliseconds:

pi@raspberrypi:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=44 time=8.94 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=44 time=8.95 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=44 time=8.99 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=44 time=8.98 ms
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3001ms
rtt min/avg/max/mdev = 8.949/8.969/8.990/0.069 ms

Yes. It might just be that the answer from Google's DNS servers comes in much faster (because of your strange slow inter-link to the wired network) and therefore the Pi-hole DNS server is simply skiped because the wireless clients think it is broken or something like that.

Do you have Linux clients on the wireless network or which OS do you have (so we can figure which test commands to use)?

I have Android clients on the wireless mainly with my wireless video clients. I can test with windows, however. I did the ping from Putty to Google DNS and the result is below. My Pi is plugged into a switch plugged into my router, along with other devices.

Okay, I tried how you can do it with Android and found a working path for our debugging.

Install the App IPv6 and More on one of your devices, select Tools and configure it to use 192.168.111.6 as DNS server:

Afterwards, chose a valid domain and click on Dig. If everything works out you should see something like the following (note the QUERY status: NOERROR and that there is a result under ;; ANSWERS:).

Awesome! What I am not understanding - is - why my router is not having the wireless clients use the Pi as a DNS when I specifically enter that into the settings. I will have to do what you specified above for each device - therefore - it will not be network - wide, right? I will get the program later today for our debugging.

I think the app will only configure the server it will use for its own testing, not for the whole system. If it is your router that is preventing you from setting the DNS server network-wide, you might want to consider using the Pi-hole DHCP server.

I gotcha. However, if we do that, my port-forwarding and such I have set up on my router will then no longer function, right? I downloaded the program, and it looks slightly different from yours - it has no option to put in DNS server. I checked, and my default is still the Pi. I put in Google.de and the response was "Timed out waiting for response. Retry the query" I tried Ping from this program and it worked fine from my wireless to my Pi on the Wired net. Also, if I do use the Pi DHCP server, will that al;so work for the wireless if I go in and disable DHCP (and I would have to do that for both nets, right?)

I do get results with Ping on command but not API.

This is so odd.

Oh yeah, I forgot that you have even two different DHCP servers there (one for wired, one for wireless). If you disable both and enable the Pi-hole's DHCP server, all devices will be in the same network.

No, that will be unaffected. It will just be another guy in your network taking care of who is getting which address. The forwarding has to do with your Internet facing firewall, which will still be your router.

Anyhow, reading

I feel that my assumption has proved to be true that there has to be a firewall jumping in. It permits pings to reach their target, but block DNS requests (port 53 UDP). You should carefully (re-)check your AP's settings first.

so even if I change to the Pi's DHCP, I will still have the same issue because of my AP? Would you suggest I disable DCP on bothe networks and just allow the Pi to handle it? If so, I won't have to change the staic IP of the Pi, will I? Or my main computer? (Both have static ip's of 192.168.111.6 and 192.168.111.4, respectively.)

It depends. You should first have a look at the firewall settings of your AP. If it does not let port 53 go though, nothing will work anyhow.

Ok, remember, I have the two nets through the same router. I use the Titan AP AC1900 as an wirless Access Point, and am repeating this signal with another extender or two. Upon opening the config page , I see the address of the AP as 192.168.80.240, defult gateway of 0.0.0.0. I remembner when setting this up and talking to the tech support of Titan they had me set it up so the AP and extenders work sas intended, and they do. However, I noticed when opening the config page that DHCP is set to "Auto" with a client rand of 192.168.80.1 -200. It seems to me that I need to disable the DHCP on the Titan AP and let the router do it.....for now I have an AP handing out adresses and the router enabled for DHCP. Under "DHCP" on the Titan AP my iptions are Disables/Static AP, Client, Server and Auto.This may be why the Pi is not handling DNS requests on the Wireless netork, (even though it show under DNS in Wireless settings that indeed the DNS IS the Pi at 192.168.111.6). I can find nowhere on the config page to allow the UDP 53 on the Titan -anywhere. It does indeed, under system statis of the Titan AP state the AP Ip's address is 192.168.0.100, the default gateway is 192.168.0.1, and the DNS being 192.168.111.6 - all of these exactly mirror what is in the Watchguard Firewall router settings exactly. No place can I find any firewall settings on the Titan AP to allow the UDP port 53. What do you think is the next thing to try?

I didn't forget your configuration. I was looking at the manual of your AP in the meantime and indeed, there is no mentioning about any firewall settings. However, clearly, it prevents your devices from reaching the Pi-hole's DNS server. Interestingly, I see that there is a specific socket on the AP where you have to plugin your router in order to have it running. This looks too much like a WAN socket on a ordinary router (where the main reason of having this socket is that everything that goes through this port will have to pass the firewall).

The bad thing now is that I tend to believe that your AP is unsuitable for the planed undertaking, because it does something to the DNS requests which prevents you from doing what you want but you cannot change this behavior. Oddly enough, there is not even a single occurrence of the term "DNS" in the manual.

You mentioned that you have gotten support from the company that build your AP in the past and it seems that this is what you have to do again. Tell them that you want to access a DNS server that is located in the network that is behind the Network socket of your AP.

There is one slight possibility to have it running nevertheless, but you would have to test this (I think it should work, but the manual is no help here, either): Disable DHCP on the AP by selecting select "Client" and leave it enabled on your router. Then, disconnect the cable between your router and the AP from its blue socket and plug it into the green socket. This could/should integrate everything into one big network and bypass any possible firewall on your AP.

Cool. I am going to try just that, as when I had a spare wireless router I configured it in just the very way you said and it worked before I bought this high-power AP for better coverage. If it doesn't I can just always reset the settings to what they were. Lastly, I will call their tech support but I doubt if they will have a solution. One last thing: would you suggest I just use the pi's DHCP server? My Watchguard firewall is extremely powerful but given the fact the pi is based on Linux and has very little overhead what would be faster and more streamlined? If I do this - and disable the DHCP server on both nets on the Router - all static IP's will remain in place just fine and communicable, right? Just when it comes to handing out new addresses it would all be handled by the pi, right? If so, I just need to disable on router and enable on Pi, and that's it?

I use it, but mainly because my router does not let me specify which DNS server it should hand out to the connecting clients (it always handed out itself). If the solution with your router is working fine, there seems to be no pressing need to change that. However, using the Pi-hole DHCP server will trivially make all host names of the devices available in your network available via DNS. Not sure if that is the case with your current configuration.

The Pi-hole is not concerend about any security - it just handles DNS, so I wouldn't recommend to remove the firewall. Also, I'd not suggest to use a firewall that is installed on the Raspberry Pi for your entire network, because the Pi is still at the lower end of performance and you will experience a significant slow-down if you go for a Raspberry Pi based firewall setup.

That's correct. If you want to change the DHCP server you want to use, make sure that you disable everything else and enable it on the Pi. Your devices with static IPs will not even notice and can be used without any difference. As you said, only new clients that are actively asking for an address will then get one from your Pi-hole, instead getting it from the router (as was happening before).

Well, I am finally seeing the wireless clients querying the Pihole. Here's what I did.

  1. Looked in the config page of the Wireless AP. Called their support. They insisted that their Titan APA 1900 access point contains absolutely NO firewall or port blocking in it. They leave that up to the Router they are wired into. On looking at the configuration page of the Access Point I see that it has an address 192.168.80.240 (which is outside of my Router network range) and had DHCP enabled with an address range.

  2. I disabled DHCP on the Access Point (which the support staff said it had absolutely nothing to do with my situation as they said it turns itself off after configuration) and gave the AP a static address of 192.168.0.240 (which was outside of the DHCP addresses of my Router but in the 0 net). I shut off all DHCP Auto and left it Static on the AP, although Titan Support Staff insists that this is NOT active.

  3. I create a rule in my Firewall Policies to allow TCP and UDP (just to be sure) port 53 communication across my two networks, although it worked with my wired net with no issues.

  4. THE PIHOLE NOW IS REDIRECTING ALL REQUESTS MADE WIRELESS. In other words, I got it working.

I am not for sure which step solved the problem, but when I performed a DIG analysis wirelessly across to the wired net DNS (from 192.160.0.105 to 192.168.111.6) I cam back with the report I expected , and the TAIL is reporting the wireless Clients are querying the Pihole.

Glad to hear it worked now. There has to be something special with this one blue Ethernet socket, otherwise it would not be there and/or would also try to distribute DHCP out there.

Conclusion: The support does not really know what is happening, esp. that they said that the DHCP would turn itself automatically off after configuration, because we know it was active.