No internet access through ipv4 but dns is resolving on clients and on pihole

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

Expected Behaviour:

Ability to access ipv4 addresses through ping/wget/curl etc

Actual Behaviour:

I am not able to make any network requests that attempt ipv4 so my pihole -r fails since it can't grab github.

For ping I get

pi@raspberrypi:~ $ ping github.com
PING github.com (140.82.113.4) 56(84) bytes of data.
From wpad.lan (192.168.0.55) icmp_seq=1 Destination Host Unreachable
From wpad.lan (192.168.0.55) icmp_seq=2 Destination Host Unreachable

It appears my dns server is resolving it correctly but i'm not getting routed there.

My gatewaty is 192.168.0.1.

DHCP for ipv4 is handled by pihole and ipv6 by the router/modem combo NETGEAR C6300 since it cannot be turned off.

I have also tried forcing all DHCP through my router/modem combo with the same result on the pihole.

DNS is set on IPV6 DHCP on router/modem combo to be the pihole address

Various results:

pi@raspberrypi:~ $ ip route
default via 192.168.0.1 dev eth0 src 192.168.0.55 metric 202
192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.55 metric 202


pi@raspberrypi:~ $ arp
Address                  HWtype  HWaddress           Flags Mask            Iface
{removed}.lan               ether   90:dd:5d:5d:aa:e7   C                     eth0
192.168.0.1                      (incomplete)                              eth0
192.168.0.11                     (incomplete)                              eth0
{removed}.lan      ether   00:e0:4c:a3:47:f4   C                     eth0
192.168.0.14             ether   00:e0:4c:a3:47:f4   C                     eth0
{removed}t.lan           ether   f4:f5:e8:5c:5a:a4   C                     eth0
{removed}.lan          ether   38:60:77:f0:2d:d6   C                     eth0
{removed}  ether   b0:b9:8a:0f:99:62   C                     eth0
192.168.0.19                     (incomplete)                              eth0
192.168.0.15             ether   90:dd:5d:5d:aa:e7   C                     eth0
{removed}.lan                ether   78:67:d7:69:e1:7d   C                     eth0
{removed}.lan       ether   1c:91:48:6d:84:0e   C                     eth0
{removed}.lan               ether   e0:cb:4e:01:58:cd   C                     eth0
192.168.0.239            ether   30:4b:07:77:92:13   C                     eth0
192.168.0.253                    (incomplete)                              eth0
192.168.0.16                     (incomplete)                              eth0
192.168.0.222            ether   a0:02:dc:dc:7f:c8   C                     eth0
192.168.0.13             ether   f4:f5:e8:5c:5a:a4   C                     eth0


pi@raspberrypi:~ $ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.55 icmp_seq=1 Destination Host Unreachable
From 192.168.0.55 icmp_seq=2 Destination Host Unreachable

the ipv6 ping appears to work

pi@raspberrypi:~ $ ping google.com
PING google.com(iad30s09-in-x0e.1e100.net (2607:f8b0:4004:800::200e)) 56 data bytes
64 bytes from iad30s09-in-x0e.1e100.net (2607:f8b0:4004:800::200e): icmp_seq=1 ttl=54 time=22.3 ms
64 bytes from iad30s09-in-x0e.1e100.net (2607:f8b0:4004:800::200e): icmp_seq=2 ttl=54 time=19.5 ms

pi@raspberrypi:~ $ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1


pi@raspberrypi:~ $ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters

127.0.1.1       raspberrypi
pi@raspberrypi:~ $ cat /etc/dnsmasq.d/01-pihole.conf
# Pi-hole: A black hole for Internet advertisements
# (c) 2017 Pi-hole, LLC (https://pi-hole.net)
# Network-wide ad blocking via your own hardware.
#
# Dnsmasq config for Pi-hole's FTLDNS
#
# This file is copyright under the latest version of the EUPL.
# Please see LICENSE file for your rights under this license.

###############################################################################
#      FILE AUTOMATICALLY POPULATED BY PI-HOLE INSTALL/UPDATE PROCEDURE.      #
# ANY CHANGES MADE TO THIS FILE AFTER INSTALL WILL BE LOST ON THE NEXT UPDATE #
#                                                                             #
#        IF YOU WISH TO CHANGE THE UPSTREAM SERVERS, CHANGE THEM IN:          #
#                      /etc/pihole/setupVars.conf                             #
#                                                                             #
#        ANY OTHER CHANGES SHOULD BE MADE IN A SEPARATE CONFIG FILE           #
#                    WITHIN /etc/dnsmasq.d/yourname.conf                      #
###############################################################################

addn-hosts=/etc/pihole/gravity.list
addn-hosts=/etc/pihole/black.list
addn-hosts=/etc/pihole/local.list


localise-queries


no-resolv



cache-size=10000

log-queries
log-facility=/var/log/pihole.log

local-ttl=2

log-async

# If a DHCP client claims that its name is "wpad", ignore that.
# This fixes a security hole. see CERT Vulnerability VU#598349
server=8.8.8.8
server=8.8.4.4
server=2001:4860:4860:0:0:0:0:8888
server=2001:4860:4860:0:0:0:0:8844
host-record=wpad.lan,192.168.0.55
except-interface=nonexisting

Ping from a local windows 10 machine to pi

C:\Users\{removed}>ping 192.168.0.55

Pinging 192.168.0.55 with 32 bytes of data:
Reply from 192.168.0.55: bytes=32 time<1ms TTL=64
Reply from 192.168.0.55: bytes=32 time<1ms TTL=64
``

I have been attempting to trouble shoot the problem and in many cases of similar issues the person in question just reinstalled. I would like to avoid that if possible. Thank you



## Debug Token:

https://tricorder.pi-hole.net/2qs3ia2cw5

192.168.0.1 is not on the internet, it's on your local network. 192.168.0.55 is telling you that.

And your ping to github is resolving to the correct internet accessible address but the router or host at 192.168.0.55 has no way to get there. This is not a Pi-hole issue since we have no way to affect the routing of your traffic and the correct IP address shows the DNS service is working correctly.

I'd take a look at what 192.168.0.55 is and why it's not able to route your packets correctly.

192.168.0.55 is the raspberry pi running pihole.

I am able to ping the gateway from my windows 10 machine fine.

On the Pi-hole, ping 192.168.0.1, 192.168.0.55 and 8.8.8.8.

If any of those fail then the network is not set up correctly. Take a look at /etc/dhcpcd.conf and make sure all the information is correct there for the static IP setup.

pi@raspberrypi:~ $ ping 192.168.0.1
PING 192.168.0.1 (192.168.0.1) 56(84) bytes of data.
From 192.168.0.55 icmp_seq=1 Destination Host Unreachable
From 192.168.0.55 icmp_seq=2 Destination Host Unreachable
From 192.168.0.55 icmp_seq=3 Destination Host Unreachable
^C
--- 192.168.0.1 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3153ms
pipe 4
pi@raspberrypi:~ $ ping 192.168.0.55
PING 192.168.0.55 (192.168.0.55) 56(84) bytes of data.
64 bytes from 192.168.0.55: icmp_seq=1 ttl=64 time=0.125 ms
64 bytes from 192.168.0.55: icmp_seq=2 ttl=64 time=0.133 ms
64 bytes from 192.168.0.55: icmp_seq=3 ttl=64 time=0.133 ms
^C
--- 192.168.0.55 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2094ms
rtt min/avg/max/mdev = 0.125/0.130/0.133/0.010 ms
pi@raspberrypi:~ $ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
From 192.168.0.55 icmp_seq=1 Destination Host Unreachable
From 192.168.0.55 icmp_seq=2 Destination Host Unreachable
From 192.168.0.55 icmp_seq=3 Destination Host Unreachable
^C
--- 8.8.8.8 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3122ms

I reviewed /etc/dhcpcd.conf but it appears fine

# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.55/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.0.55
#static routers=192.168.0.1
#static domain_name_servers=127.0.0.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0

interface eth0
static ip_address=192.168.0.55/24
static routers=192.168.0.1
static domain_name_servers=127.0.0.1

For some reason your node at .55 can not contact the router at .1. How are the two physically connected? If it is wired then have you tried checking all the cables, pulling and pushing back in again. The arp cache has no MAC record for .1 so there is something preventing discovery over the local network segment.

It is directly connected through Ethernet and I just checked the cables to make sure it had a good connection but even after that it has the same results. What could be causing this?

Anything that could be blocking arp discovery or icmp packets. Firewall or security software. Can you ping .1 and .55 from other systems on the same network segment?

Yes I can ping them from a windows 10 machine on the same network segment also connected through ethernet to the router/modem combo.

C:\Users{removed}>ping 192.168.0.1

Pinging 192.168.0.1 with 32 bytes of data:
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=2ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64
Reply from 192.168.0.1: bytes=32 time=1ms TTL=64

Ping statistics for 192.168.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 2ms, Average = 1ms

C:\Users{removed}>ping 192.168.0.55

Pinging 192.168.0.55 with 32 bytes of data:
Reply from 192.168.0.55: bytes=32 time<1ms TTL=64
Reply from 192.168.0.55: bytes=32 time<1ms TTL=64
Reply from 192.168.0.55: bytes=32 time<1ms TTL=64
Reply from 192.168.0.55: bytes=32 time<1ms TTL=64

Ping statistics for 192.168.0.55:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

You can try installing arping on the Pi device and then sudo arping 192.168.0.1 and check if that gives you some information on why the arp table is not being populated.

I tried to install arping but it gave an error for unable fetch some archives due to 113: no route to host. I installed it from the package locally and just get time out on it.

pi@raspberrypi:~ $ sudo arping 192.168.0.1
ARPING 192.168.0.1
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
Timeout
^C
--- 192.168.0.1 statistics ---
24 packets transmitted, 0 packets received, 100% unanswered (0 extra)

Does sudo arp -a or sudo ping -b 192.168.0.255 and then a sudo arp -a show a MAC address for 192.168.0.1?

sudo arp -a shows


pi@raspberrypi:~ $ sudo arp -a
{removed}.lan (192.168.0.245) at 00:e0:4c:a3:47:f4 [ether] on eth0
{removed}.lan (192.168.0.233) at e0:cb:4e:01:58:cd [ether] on eth0
{removed}.lan (192.168.0.208) at f4:f5:e8:5c:5a:a4 [ether] on eth0
{removed}.lan (192.168.0.228) at 38:60:77:f0:2d:d6 [ether] on eth0
? (192.168.0.1) at <incomplete> on eth0




pi@raspberrypi:~ $ sudo ping -b 192.168.0.255
WARNING: pinging broadcast address
PING 192.168.0.255 (192.168.0.255) 56(84) bytes of data.
64 bytes from 192.168.0.208: icmp_seq=1 ttl=64 time=131 ms
64 bytes from 192.168.0.208: icmp_seq=1 ttl=64 time=131 ms (DUP!)
64 bytes from 192.168.0.208: icmp_seq=2 ttl=64 time=356 ms
64 bytes from 192.168.0.208: icmp_seq=2 ttl=64 time=357 ms (DUP!)

and after

sudo arp -a

pi@raspberrypi:~ $ sudo arp -a
{removed}.lan (192.168.0.245) at 00:e0:4c:a3:47:f4 [ether] on eth0
{removed}.lan (192.168.0.233) at e0:cb:4e:01:58:cd [ether] on eth0
{removed}.lan (192.168.0.208) at f4:f5:e8:5c:5a:a4 [ether] on eth0
{removed}.lan (192.168.0.228) at 38:60:77:f0:2d:d6 [ether] on eth0
? (192.168.0.1) at <incomplete> on eth0

Thank you for all your help with this.

UPDATE:

I just checked sudo arp -a and it is now showing the gateway mac address for 192.168.0.1 but it keeps going in and out. I will check in once and it shows the mac address then it goes incomplete upon the next check.

What type of device is the router?

It is a NETGEAR C6300 .

And there is no other devices between the Pi-hole and the router? It's a direct connection?

Correct, it is connected directly with an Ethernet cable. I also just swapped out the cable to cover all the bases.

I don't have any other suggestion for things that may solve this. Intermittent arp failures seems like a hardware issue, perhaps a port going bad on the router or on the Pi-hole itself. Might be power related if the Pi device is not provided enough of a supply.

I understand, I am going to do a reinstall of raspbian to see if that changes it and go from there. Thank you again for all the help. This was an odd one.