Cannot reach all URL's using Pihole DCHP, Android, ARCH, OS X

Help
1

Please follow the below template, it will help us to help you!

If you are Experiencing issues with a Pi-hole install that has non-standard elements (e.g you are using nginx instead of lighttpd, or there is some other aspect of your install that is customised) - please use the Community Help category.

Expected Behaviour:

_[
With Pi-hole blocking enabled and clients using Pi-hole's DHCP all clients are expected to have appropriate Ads blocked and be able to reach ANY address/URL which is not blocked.

Pi-hole Hardware = Raspberry Pi Zero WH

Running the Lite version of:

PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian

ISP= AT&T
ISP Router/Modem = ARRIS model BGW210-700 w/ DHCP v4 and DHCP v6 DISABLED

Test Clients= various versions of Android Tablets and Phones, Mac OS X, lasted Manjaro/Arch, latest/updated full version of Raspberry Pi OS running on Raspberry Pi 4

]_

Actual Behavior:

_[

Clients are having Ads blocked however clients are to reach all URLs that have not been blocked.

Sample URL which had Ads blocked: http://cnczone.com
Sample URLs which clients are unable to reach are:
http://discourse.pi-hole.net
http://ebay.com
http://duckduckgo.com
(others upon request)

]_

Debug Token:

[ fkeakqm4sn ]

2

Seems I made a typo of sort as the Actual behavior should read "clients are to reach all URLs" = "clients are UNABLE to reach all URLs"

My apologies for the error. Thank You

3

DNS doesn't deal with URLs, only with domains.

Let's see how Pi-hole and DNS is involved in this

Run from a client PC or laptop exhibiting access problems, what's the output of the following commands:

nslookup pi.hole

nslookup flurry.com

nslookup discourse.pi-hole.net

Replace the domain in that last nslookup with a domain that's unreachable for the client as required.

Please provide the full output for all three commands.

4

Thank you Sir for the assistance.

The requested information is below, not however that I may not have interpreted your instructions correctly. I was unsure of precisely what you wanted so I have provided all three nslookup commands you listed, just as listed. The instructions said to replace the "domain" in "that last nslookup" with a domain that's unreachable. Oh man I hate proving I'm an idiot.......... Ok so what I did was to give you the three you provided plus a 4th using the domain "ebay.com". My confusion was not being sure you had noted that "discourse.pi-hole.net" was a location which was also unreachable. Maybe I got hung up on your 1st statement about DNS not dealing with URLs but only with domains........ Then your 1st statement about DNS and Domains/URLs..... At any rate I hope I played it safe by simply doing your three examples plus another which also fails. Perhaps we'll have a chance some day to discuss Domain Names and hostnames etc.... over beers, for which I'll likely owe you so many I'll go broke :slight_smile:

I did note in the output that the two which fail are non-authoritative returns....... so I went over to a machine that is not going through the pi-hole DNS and they also come back as non-authoritative.

Note also I had to switch the network back over to the AT&T device performing DHCP and obviously turned DHCP off in Pi-hole. The client which the output below was performed on had not been rebooted/reconfigured/etc... and is still using the Pi-hole DNS etc.... I don't think it should make a difference but hey now you know..........

See output Below:

root@pi4-1:~# nslookup pi.hole
Server: 192.168.1.184
Address: 192.168.1.184#53

Name: pi.hole
Address: 192.168.1.184
Name: pi.hole
Address: 2600:1700:3651:940:b44:3ae5:4151:8162

root@pi4-1:~# nslookup flurry.com
Server: 2600:1700:3651:940:b44:3ae5:4151:8162
Address: 2600:1700:3651:940:b44:3ae5:4151:8162#53

Name: flurry.com
Address: 0.0.0.0
Name: flurry.com
Address: ::

root@pi4-1:~# nslookup discourse.pi-hole.net
Server: 192.168.1.184
Address: 192.168.1.184#53

Non-authoritative answer:
Name: discourse.pi-hole.net
Address: 159.203.95.226

root@pi4-1:~# nslookup ebay.com
Server: 192.168.1.184
Address: 192.168.1.184#53

Non-authoritative answer:
Name: ebay.com
Address: 66.135.196.249
Name: ebay.com
Address: 66.135.195.175

root@pi4-1:~#

Thank You very much

5

These answers are all expected and correct. The client is able to resolve the domain names for all.

If a client is unable to connect to these websites, it appears the problem lies outside of Pi-hole.

6

Thank you JFB,

Well I guess I shouldn't feel so bad for not having been able to see what is wrong..... and I would if it wasn't for the gorilla in the room.,, It doesn't seem to work for a semi wide range of very common systems.

So of the many systems I have here I have not found one which once they begin using the DHCP from the Pi-hole server will function properly so... that range covers:

A Raspberry Pi 4 running the latest full version of Raspberry Pi OS, which I'm counting as an exhibit of Debian.
An X86 machine with the latest version of Manjaro, which I'll count towards an Arch based system
A Macbook Pro running OS X, which probably isn't a good example of BSD but in and of itself OS X counts for something :slight_smile:
A very wide variety of Android based devices which covers an even wider range of Android versions. From an old Nexus tablet running Android v4.4.? A Samsung Galaxy Tablet running a few years old, another Galaxy tablet new in December, A Samsung phone from about a year and a half back, an other Samsung phone from about two and half years back, and an off brand noname tablet from.... lord I have no idea :slight_smile:
I do have but have not tried an iPad which is a few years old, an old 1st generation Kindle Fire, I almost forgot there is a Windows 10 desktop as well.

So moving forward I can try those platforms I have not tested but I would be surprised if they do not function similarly. And I do agree that from a DNS perspective the Pi-hole seems to be working fine. I haven't figured out how to check the settings received from the Pi-hole DHCP on the Android devices but it looked fine on the Debian, Arch, and OS X devices which makes it unlikely to be DHCP related.......

Wow, I'm not really sure...... I do not know if you are aware but Bucking_horn was kind enough to assist me with my original issue where the Pihole admin page was not showing any metrics BUT WAS BLOCKING Ads. He noted that my test client was not actually using the Pi-hole for DNS resolution. Which considering how I understand Pi-hole works seems to be a bit impossible however that is definitely what was happening....

Hmmm..... if you have any suggestions on what I might take a closer look at I would be grateful for any guess you might have. That said, for me there are two unknowns in this 1) The AT&T ARRIS BGW210-700 Modem/Router which I have been trying unsuccessfully to abtain the admin guide for from AT&T but saddly if it isn't something that is on a written script the AT&T support techs aren't of much assistance. So it is unknown. and 2) IPv6...... I honestly know little to nothing about IPv6. I wonder about that because through this activity I have noticed it seems inconsistent in that sometimes v6 addresses are used and others they aren't, sometimes not at all. So that is something I can look at. I do know that the AT&T router appeared to have one toggle for enabling and disabling DHCP but after studying the effects before I turned in the request for help here I found another toggle buried on a page in the AT&T router admin GUI which not the DHCP page.. turns out you have to turn off DHCP for IPv4 and IPv6 individually. Ah... and there is the IPv6 option in the pihole admin GUI dealing with an IPv6 option for which I blindly turned on. So I can explore that as well. About time I learned something about it anyways.

Ultimately though I guess what I'm going to have to do is capture some packets and actually look and see what exactly is happening. Always a pain but when ya run out of guesses..........

AGain thank you and if you think of anything I might hold suspect I would love to hear it. I wish at least one device would function correctly so I'd have something to compare it to...... Hell this was supposed to be straight forward I thought, Buy a Pi, load the OS, load Pi-hole and enjoy :-)...... If I figure anything out I'll provide feedback.

Thank you and thank Bucking_horn for me as well
Dee

7

Bucking_horn, JFB,

I found where the issue was and a resolution which I think might be appropriate. I am putting a summary of what seemed to be happening and how I resolved it in case it helps someone else. I am a bit surprised that with as many AT&T fiber customers there are it isn't out on the net as a common problem for a lot of issues... at any rate hopefully it helps somebody down the road.

To recap the problem, Once obtaining the correct configuration of Pi-hole and the use of DHCP from the Pi-hole server many web sites were unreachable. Ad blocking worked fine but a significant portion of common web sites just didn't work.

The AT&T modem/router was blocking some ICMPv6 traffic using "Reflexive ACL" to block packets it seemingly has determined to not have been requested from a LAN side client.

The solution, on the AT&T Arris BGW210-700 modem/router, is to go to the Firewall menu in the admin interface and turn "Refelxive ACL" to OFF. Note that on the Pi-hole admin interface on the DHCP tab that "Enable IPv6 Support (SLAAC + RA)" must be enabled for it to function correctly.

I got to learn a lot looking through all the packet captures I did and I know a lot more now than I did before which is cool though I'm also much more aware of how little I know about IPv6. It seems to be a bit of gray area with regards to DHCP functionality so I hope the solution I employed isn't a kluge and would very much welcome alternative solutions which might be more in line with the intended proper configuration in support of using both IPv4 and IPv6. I didn't think enabling DHCPv6 was the correct method, though I wonder what the results would have been. And I didn't think just turning everything IPv6 off on my devices would have been cool, or even possible considering limitations on various versions of Android.

Anyhow I appreciate the assistance I received from the two of you and I hope my findings will help some other AT&T victim out in the future. (hmm... is it really on the shoulders of AT&T or perhaps it's the odd competing nature of IPv6's development to blame.....AT&T is always guilty of something, even it's just for being stupid....so let's let them own it :slight_smile: )

Thank You
Dee

8

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.