[fixed] Pi-Hole newbie with DNS issues

Bucking_Horn · February 6, 2020, 12:39am

That, and the routing table, confirm that you can connect to your gateway.

The reason the debug couldn't get to it might have something to do with two interfaces being active, eth0 and wlan0.

In general (i.e. not specifically to fix the failed g/w ping), I'd recommend running Pi-hole on eth0 (stability and latency), and if you don't need it, disable wlan0 (less interference with existing WiFis, and saves some power, too).

Bucking_Horn · February 6, 2020, 12:44am

Only because I try to avoid typos more than you do - here's your correct sentence :

You are typing too slow

deHakkelaar · February 6, 2020, 12:45am

Yeah I noticed too

C64 · February 6, 2020, 12:49am

cat /etc/network/interfaces
#interfaces(5) file used by ifup(8) and ifdown(8)
#Please note that this file is written to be used with dhcpcd
#For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'
#Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d
grep -A6 '^\s*interface' /etc/dhcpcd.conf
interface eth0
static ip_address=192.168.1.57/24
static routers=192.168.1.1
static domain_name_servers=192.168.1.1
interface eth0
static ip_address=192.168.1.200
static routers=192.168.1.1
static domain_name_servers=127.0.0.1
interface eth0
static ip_address=192.168.1.200/24
static routers=192.168.1.1
static domain_name_servers=127.0.0.1

I think at least the first entry is obsolete and should be deleted (?), maybe along with the second entry. What do you suggest?

Good point, thank you for that! For the record:
sudo nano /boot/config.txt
there, add this line:

dtoverlay=disable-wifi

deHakkelaar · February 6, 2020, 12:57am

Make backup of that file if make mistake:

sudo cp /etc/dhcpcd.conf /etc/dhcpcd.conf.bak

Edit that file:

sudo nano /etc/dhcpcd.conf

Delete all the redundant interface sections and only leave below at the bottom before exit/saving the file:

interface eth0
  static ip_address=192.168.1.200/24
  static routers=192.168.1.1
  static domain_name_servers=127.0.0.1

Reboot and check below one again:

ip route

If only one default route, you can try run pihole -d again to see if fixed.

C64 · February 6, 2020, 1:03am

default via 192.168.1.1 dev eth0 src 192.168.1.200 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.200 metric 202

Now, pihole -d seems to report no more errors apart from IPv6 which, according to previous posts, is somewhat expected behaviour … right?

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
192.168.1.200/24 matches the IP found in /etc/pihole/setupVars.conf

[✓] IPv6 address(es) bound to the eth0 interface:
fe80::9edd:b635:2879:d87e does not match the IP found in /etc/pihole/setupVars.conf (Use IPv6 ULA addresses for Pi-hole)

^ Please note that you may have more than one IP address listed.
As long as one of them is green, and it matches what is in /etc/pihole/setupVars.conf, there is no need for concern.

The link to the FAQ is for an issue that sometimes occurs when the IPv6 address changes, which is why we check for it.

[i] Default IPv4 gateway: 192.168.1.1

Pinging 192.168.1.1...
[✓] Gateway responded.

Am I supposed to add above IPv6 to /etc/pihole/setupVars.conf ?

Bucking_Horn · February 6, 2020, 1:08am

Single G/W yes, single default route - not necessarily.
I think what we see is the result of a standard RPi config.

AFIAA, you can have two default routes, as long as they are attached to different interfaces and have different metrics attached.
The system would then default to the route with the higher metrics:

So in C64's setup, it would prefer wifi over lan routing, still with the same g/w.
EDIT: That way, route to g/w would stay operative even if WiFi would fail for some reason.

@C64: Feel free to ignore these tech mumblings, it's just some blokes getting carried away, brushing up their respective body of knowledge

deHakkelaar · February 6, 2020, 1:10am

Yeah metrics decides I realize.
But dont think the debugger can cope with two default routes @devs ???

EDIT: Looks like this bit goes south:

github.com

pi-hole/pi-hole/blob/1d43c0a2fa36ddc993db51b1751e26cbc8123fbf/advanced/Scripts/piholeDebug.sh#L613


gateway="$(ip -"${protocol}" route | grep default | cut -d ' ' -f 3)"
# If the gateway variable has a value (meaning a gateway was found),
if [[ -n "${gateway}" ]]; then
    log_write "${INFO} Default IPv${protocol} gateway: ${gateway}"
    # Let the user know we will ping the gateway for a response
    log_write "   * Pinging ${gateway}..."
    # Try to quietly ping the gateway 3 times, with a timeout of 3 seconds, using numeric output only,
    # on the pihole interface, and tail the last three lines of the output
    # If pinging the gateway is not successful,
    if ! ${cmd} -c 1 -W 2 -n "${gateway}" -I "${PIHOLE_INTERFACE}" >/dev/null; then
        # let the user know
        log_write "${CROSS} ${COL_RED}Gateway did not respond.${COL_NC} ($FAQ_GATEWAY)\\n"
        # and return an error code
        return 1
    # Otherwise,
    else
        # show a success
        log_write "${TICK} ${COL_GREEN}Gateway responded.${COL_NC}"
        # and return a success code
        return 0

C64 · February 6, 2020, 1:11am

After disabling WiFi, not anymore:

default via 192.168.1.1 dev eth0 src 192.168.1.200 metric 202
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.200 metric 202

Bucking_Horn · February 6, 2020, 1:16am

Ah, so @deHakkelaar may be right and the failed g/w ping is a result of two default routes!

If you enable IPv6 support, yes.

Otherwise, it wouldn't affect functionality - but Pi-hole populates it's UI partially based on setupVars.conf, and I think it would display a potentially wrong IPv6 address if you'd leave it.

C64 · February 6, 2020, 1:30am

Thank you, @Bucking_Horn, after adding the IPv6, it shows up in green.
Is this

*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] www.new19year.000webhostapp.com is :: via localhost (::1)
[✓] www.new19year.000webhostapp.com is :: via Pi-hole (fe80::9edd:b635:2879:d87e)
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)

… expected behaviour? From what I understand, failing to resolve doubleclick proves blocking to work fine.

deHakkelaar · February 6, 2020, 1:37am

If your ISP doesnt provide you with IPv6 support, its of little use to have your LAN support IPv6 as well.
It only complicates matters.
The debugger failing to resolve via public DNS is expected if no IPv6 support upstream.

https://ipv6-test.com/

I would disable everything IPv6 related on router and Pi-hole.

C64 · February 6, 2020, 1:45am

I see IPv6 isn't supported by my ISP, thanks for clarifying @deHakkelaar. IPv6 now is disabled.

I guess I made it now, only thanks to all of your patience and wisdom, helping me walk through this dense forest of options. @deHakkelaar @Bucking_Horn

Good night!

C64 · February 6, 2020, 11:13am

Sadly, the fun lasted only a few hours, I can't access WAN anymore. Clients receive their IPs and correct local DNS server address, http://pi-hole/admin is accessible, but ultimately all clients fail to connect to the internet.

My setup:

Cable Modem, IP address 192.168.0.1, serving DHCPv4 and DHCPv6 to the Asus RT-AC68U. The Cable Modem currently assigned 192.168.0.31/24 to the router.
Asus RT-AC68U router, sees WAN connection active. Router’s DHCP server is deactivated.
Pi-Hole, static IP 192.168.1.200. Clients can connect and properly see Pi-Hole as DNS server.

I‘ve rebooted Cable Mode, Router and Pi-Hole, alas, no client can connect to a website. Something has changed over night, like an IP address or so, a new may have been given, and things got broken.

What do I miss here?

Bucking_Horn · February 6, 2020, 1:10pm

Instant research hit here on the forums:

Your router may cause this if it tries to verify internet connectivity via DNS Probe, as described in Seems to block everything after a few hours - #18 by xelemorf (currently the very last post by xelemorf in there).

I will be off soon for a long weekend, so I won't be able to assist you much longer.

In the meantime, try searching the forums for your router model, or alert a mod or some of the guys from yesterday by @ing them

deHakkelaar · February 6, 2020, 3:50pm

IP failing or DNS failing ?
For IP try run a traceroute from clients and Pi-hole eg:

pi@noads:~ $ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.0.0.1  0.708 ms  0.534 ms  0.562 ms
 2  192.168.1.1  0.880 ms  0.749 ms  0.858 ms
 3  62.58.240.1  8.086 ms  8.428 ms  8.238 ms
 4  212.53.25.201  8.476 ms  8.175 ms  8.302 ms
 5  212.53.25.193  8.525 ms  8.404 ms  8.356 ms
 6  212.151.190.0  8.781 ms  9.217 ms  9.648 ms
 7  72.14.223.246  9.334 ms  9.037 ms  8.738 ms
 8  * * *
 9  8.8.8.8  8.393 ms  8.417 ms  8.577 ms

For Windows, you have the tracert tool eg.:

tracert -d 8.8.8.8

For troubleshooting DNS, use the nslookup tool on clients as well as on Pi-hole eg:

nslookup pi-hole.net

nslookup pi-hole.net 192.168.1.200

nslookup pi-hole.net 192.168.1.1

nslookup pi-hole.net 8.8.8.8

C64 · February 6, 2020, 5:36pm

Internet Detection options PPP Echo or DNS probe are only available when selecting a WAN connection type enforcing Authentication. As per my ISP, there is no authentication (WAN connection type is Automatic IP, I'm on cable internet). Unless I'm wrong, I cannot choose a method of Internet Detection as per your suggestion.

From my understanding, DNS, but heck do I know …

on Pi-hole:

traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.1.1 0.314 ms 0.348 ms 0.322 ms
2 192.168.0.1 1.873 ms 2.760 ms 4.109 ms
3 * * *
4 84.116.190.37 39.798 ms 40.150 ms 40.438 ms
5 84.116.197.245 56.217 ms 55.762 ms 56.337 ms
6 84.116.133.118 48.099 ms 47.996 ms 56.091 ms
7 72.14.195.116 56.283 ms 55.948 ms 55.229 ms
8 * * *
9 8.8.8.8 31.630 ms 25.633 ms 25.672 ms

nslookup pi-hole.net
Server: 127.0.0.1
Address: 127.0.0.1#53
Non-authoritative answer:
Name: pi-hole.net
Address: 206.189.252.21
Name: pi-hole.net
Address: 2604:a880:400:d0::1071:1

nslookup pi-hole.net 192.168.1.200
Server: 192.168.1.200
Address: 192.168.1.200#53
Non-authoritative answer:
Name: pi-hole.net
Address: 206.189.252.21
Name: pi-hole.net
Address: 2604:a880:400:d0::1071:1

nslookup pi-hole.net 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: pi-hole.net
Address: 206.189.252.21
Name: pi-hole.net
Address: 2604:a880:400:d0::1071:1

nslookup pi-hole.net 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: pi-hole.net
Address: 206.189.252.21
Name: pi-hole.net
Address: 2604:a880:400:d0::1071:1

on an OS X client:

traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets
1 * * *
2 * * *
3 * * *
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 *^C

nslookup pi-hole.net
Server: 192.168.1.200
Address: 192.168.1.200#53
Non-authoritative answer:
Name: pi-hole.net
Address: 206.189.252.21

nslookup pi-hole.net 192.168.1.200
Server: 192.168.1.200
Address: 192.168.1.200#53
Non-authoritative answer:
Name: pi-hole.net
Address: 206.189.252.21

nslookup pi-hole.net 192.168.1.1
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: pi-hole.net
Address: 206.189.252.21

nslookup pi-hole.net 8.8.8.8
;; connection timed out; no servers could be reached

In the meantime, I've installed Asuswrt-Merlin on the RT-AC68U, and reverted the router to serve DHCP again, and Pi-hole to a static IP client. I could access the Internet again, but it wouldn't adblock as much as it should (had). Asuswrt-Merlin luckily has an option to set "Advertise router's IP in addition to user-specified DNS", which is now off.

I have no preference over Pi-hole or the router being the DHCP server, I only need a reliable setup

deHakkelaar · February 6, 2020, 5:56pm

If that traceroute on the OS X client is from after the switch to Asuswrt-Merlin, you must have configured something wrong or different compared to the old setup.
From the traceroute, it looks like that OS X client doesnt have a default route/GW.
What does below show you now on Pi-hole:

sudo nmap -sU -p67 --script dhcp-discover 192.168.1.1

C64 · February 6, 2020, 6:13pm

sudo nmap -sU -p67 --script dhcp-discover 192.168.1.1
Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-06 18:11 GMT
Nmap scan report for 192.168.1.1
Host is up (0.00026s latency).

PORT STATE SERVICE
67/udp open dhcps
| dhcp-discover:
| DHCP Message Type: DHCPACK
| Server Identifier: 192.168.1.1
| Subnet Mask: 255.255.255.0
| Broadcast Address: 192.168.1.255
| Hostname: pi-lan
| WPAD:
|
| NetBIOS Name Server: 192.168.1.1
| Domain Name: horst
| Domain Name Server: 192.168.1.200
|_ Router: 192.168.1.1
MAC Address: 54:A0:50:D8:23:E8 (Asustek Computer)

Nmap done: 1 IP address (1 host up) scanned in 1.57 seconds

deHakkelaar · February 6, 2020, 6:19pm

nmap looks good and only one DNS server this time 192.168.1.200.
Do you have issues with all your clients or just this one OS X client ?
Have you renewed the DHCP lease on that OS X client after the Merlin switch ?
Gateway set manually on that OS X client by mistake maybe ?
Does below work on that OS X client displaying routes ?

ip r

EDIT: one more for that OS X client:

sudo dhclient -v