[fixed] Pi-Hole newbie with DNS issues

deHakkelaar · February 5, 2020, 9:27pm

Asus routers are known to push their own IP for DNS via DHCP:

If want to be sure, install nmap on Pi-hole:

sudo apt install nmap

And post results for below one (might want to redact some):

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

C64 · February 5, 2020, 9:31pm

There's a majority of OS X machines here, so after renewing the lease the output of

is (adapted to ipconfig getpacket en1 for OS X)

ipconfig getpacket en1
op = BOOTREPLY
htype = 1
flags = 0
hlen = 6
hops = 0
xid = 0x9fa5e9cc
secs = 1
ciaddr = 0.0.0.0
yiaddr = 192.168.1.206
siaddr = 192.168.1.1
giaddr = 0.0.0.0
chaddr = 10:40:f3:ed:e1:10
sname =
file =
options:
Options count is 13
dhcp_message_type (uint8): ACK 0x5
server_identifier (ip): 192.168.1.1
lease_time (uint32): 0x15180
renewal_t1_time_value (uint32): 0xa8c0
rebinding_t2_time_value (uint32): 0x12750
subnet_mask (ip): 255.255.255.0
broadcast_address (ip): 192.168.1.255
proxy_auto_discovery_url (string):

nb_over_tcpip_name_server (ip_mult): {192.168.1.1}
domain_name (string): horst
domain_name_server (ip_mult): {192.168.1.57, 192.168.1.1}
router (ip_mult): {192.168.1.1}
end (none):

C64 · February 5, 2020, 9:35pm

Hi @deHakkelaar, thanks for chiming in! This is the result:

Starting Nmap 7.70 ( https://nmap.org ) at 2020-02-05 21:33 GMT
Nmap scan report for 192.168.1.1
Host is up (0.00030s 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
| WPAD:
|
| NetBIOS Name Server: 192.168.1.1
| Domain Name: horst
| Domain Name Server: 192.168.1.57, 192.168.1.1
|_ 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.52 seconds

Bucking_Horn · February 5, 2020, 9:37pm

Bugger - seems your router is distributing itself.

In that case, you have two options:

disable DHCP on your router and enable DHCP on Pi-hole
(This will keep individual clients identifiable in Pi-hole's Query Log)
remove Pi-hole from DHCP and set it as your router's upstream DNS, usually via its Internet / WAN settings
(This will make all DNS requests in Pi-hole'S Query Log appear to originate from your router. It doesn't affect Pi-hole's blocking in any way, but some features of Pi-hole's upcoming 5.0 release requiring client id probably won't apply)

You could also try to install a new firmware on your router, as @deHakkelaar suggests, but note that you would have to acquire support for doing so in the respective forums (Merlin, openWRT, DDWRT, pfSense, etc.).

deHakkelaar · February 5, 2020, 9:39pm

Another option is to flash another custom firmware onto the Asus router but is not without risks!

https://www.asuswrt-merlin.net/

C64 · February 5, 2020, 11:07pm

@deHakkelaar
Been considering this in the past, thank you, but I don't feel inclined to do it just now. It looks like I should do it, one of these days! I fondly remember DD-WRT being a major upgrade for my trusty old Linksys WRT54G.

@Bucking_Horn
Switching DHCP over to Pi-Hole seems to have resolved the initial problem, blocking works. The only caveat is when running pihole -d, Networking reports errors:

*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the eth0 interface:
192.168.1.200/24 does not match the IP found in /etc/pihole/setupVars.conf (Use IPv6 ULA addresses for Pi-hole)

[✓] 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
192.168.1.1

Pinging 192.168.1.1
192.168.1.1...
ping: 192.168.1.1
192.168.1.1: Name or service not known
[✗] Gateway did not respond. (Why is a default gateway important for Pi-hole?)

I'm worried about the error messages showing up. Any pointers on how to fix it?
Still no access to the admin panel via http://pi-hole/admin … no deal breaker, but maybe related to other settings still not being ideal.
192.168.1.1 = Asus router, static IP, DHCP turned off
192.168.1.200 = Pi-Hole, DHCP ranges from 192.168.1.201 to .251
https://tricorder.pi-hole.net/7tchhcen2p

deHakkelaar · February 5, 2020, 11:24pm

As you've changed IP from 192.168.1.57 into 192.168.1.200, you'll need to tell Pi-hole of these changes by running below one and select reconfigure:

pihole -r

Dont worry bout the IPv6 warning.

And on the client (Linux, Windows or MacOS), use the nslookup tool in a command prompt to diagnose DNS resolution eg:

nslookup pi.hole

nslookup pi.hole 192.168.1.200

Bucking_Horn · February 5, 2020, 11:26pm

Maybe more of a cosmetic issue, since you installed Pi-hole under a different IP (.57), and Pi-hole still remembers that in setupVars.conf.

Likely same as above, with a caveat:
fe80: prefixes a link-local IPv6 address.

While valid, it is non-routable, i.e. visible only to network clients on the same network segment. If you run a network with several routers / L3 switches / access points and/or several subnets, your Pi-hole may not be accessible by all of them.

You may want to change this to a ULA address (from range fd00::/8) by configuring your routers DHCPv6 settings accordingly.
EDIT: Actually, I wonder if this would still be necessary if you run Pi-hole as DHCP, but I am unaware of an option to configure a ULA via Pi-hole's UI - calling in @jfb, @deHakkelaar already reads and will comment if he knows)

Alternatively, do not enable IPv6 support in Pi-hole's DHCP and get rid of the IPV6_ADDRESS entry in setupVars.conf. Note that this might encourage some IPv6 capable devices to look for an IPv6 DNS server elsewhere, and some of them might succeed, thus bypassing Pi-hole. But then again, they might just as well do that if IPv6 is enabled. Happens more often than I'd wish for - darn! IPv6 auto configuration

This could be an issue, but I wouldn't expect Pi-hole to be blocking ads if that would fully affect your device.

To try and rectify all of the above, (optionally:) configure a ULA adress range and check your Pi-hole's ULA address, then ssh into your Pi-hole machine and run

pihole -r

and choose reconfigure.

EDIT: Afterwards, use @deHakkelaar's above nslookups in oder to verify your new setup

deHakkelaar · February 5, 2020, 11:50pm

I recon it depends what DHCP range of IP's has been set, ipv4 or ipv6, and if below is activated:

EDIT: just realized, ipv6 doesnt work same as with ipv4 range with auto discovery and all

C64 · February 5, 2020, 11:55pm

Thanks @deHakkelaar and @Bucking_Horn, I really appreciate your help!

Done. Now I can access http://pi-hole/admin correctly! pihole -d now shows:

*** [ 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
192.168.1.1

Pinging 192.168.1.1
192.168.1.1...
ping: 192.168.1.1
192.168.1.1: Name or service not known
[✗] Gateway did not respond. (Why is a default gateway important for Pi-hole?)

https://tricorder.pi-hole.net/suup8gp280

nslookup pi.hole
Server: 192.168.1.200
Address: 192.168.1.200#53
Name: pi.hole
Address: 192.168.1.200

nslookup pi.hole 192.168.1.200
Server: 192.168.1.200
Address: 192.168.1.200#53
Name: pi.hole
Address: 192.168.1.200

Enabling IPv6 support (SLAAC + RA) didn't change the Network debug output tho … should this be active?
(see https://tricorder.pi-hole.net/ke06y31kjx for that)

*** [ 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
192.168.1.1

Pinging 192.168.1.1
192.168.1.1...
ping: 192.168.1.1
192.168.1.1: Name or service not known
[✗] Gateway did not respond. (Why is a default gateway important for Pi-hole?)

Strangely enough, I can ping 192.168.1.1 from either the Pi and a local client.

drewski · February 5, 2020, 11:57pm

That might not be a problem. My router will not respond to lan gateway pings yet everthing else is fine.

That is not necessary!

deHakkelaar · February 5, 2020, 11:59pm

Firewall can drop ICMP (ping).

Bucking_Horn · February 6, 2020, 12:09am

Like I said previously, I wouldn’t expect Pi-hole to be blocking ads if that would fully affect your device. Any upstream connection (including DNS forwards) would fail if you had no route to your gateway, and the other two are right about possible ICMP firewalling.

So as long as you still can open pages and do nslookups on public names, you should be good to go.

Just curious:

Does that mean the Pi-hole machine's CLI can ping the router?

deHakkelaar · February 6, 2020, 12:14am

Here's the code:

github.com

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


        # and Google's public IPv6 address
        public_address="2001:4860:4860::8888"
    else
        # Otherwise, just use ping
        cmd="ping"
        # and Google's public IPv4 address
        public_address="8.8.8.8"
    fi
}
ping_gateway() {
    local protocol="${1}"
    ping_ipv4_or_ipv6 "${protocol}"
    # Check if we are using IPv4 or IPv6
    # Find the default gateway using IPv4 or IPv6
    local gateway
    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}"

EDIT: cmd is cmd="ping" or cmd="ping6"

@C64, what does below show ?

ip -4 route | grep default | cut -d ' ' -f 3

And below ?

ip route

C64 · February 6, 2020, 12:28am

Positive.

On the Pi itself:

ip -4 route | grep default | cut -d ' ' -f 3
192.168.1.1
192.168.1.1

ip route
default via 192.168.1.1 dev eth0 src 192.168.1.200 metric 202
default via 192.168.1.1 dev wlan0 proto dhcp src 192.168.1.239 metric 303
192.168.1.0/24 dev eth0 proto dhcp scope link src 192.168.1.200 metric 202
192.168.1.0/24 dev wlan0 proto dhcp scope link src 192.168.1.239 metric 303

deHakkelaar · February 6, 2020, 12:35am

Your typing to slow @Bucking_Horn

For @C64:

cat /etc/network/interfaces

grep -A6 '^\s*interface' /etc/dhcpcd.conf

???

EDIT: ow ps. you should only have one gateway/default route defined.

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