[fixed] Pi-Hole newbie with DNS issues

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

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?