ipv4 connections should be going through e.x.
ping 8.8.8.8
ping github.com
using traffic over ipv4.
Operating system: Raspberry Pi 4 - Debian
IPv6 works, IPv4 does not. As simple as that, maybe has to do with wlan; tried disabling it, but maybe not correct (I am looking at the debug data right now whilst I write this)
I have been banging my head for an entire day so far. Any suggestions?
[edit: moved log]
I also don't want to use IPv6 since my router doesn't support changing the DNS-server of IPv6 (yet). I can ping IPv6 servers just fine with my Raspberry Pi, but it is probably making use of my ISP-provider instead of through Pi-Hole itself
As a reminder for the future, don't post your debug log publicly. It has been moved and made private in this post. As noted at the top of each debug log:
NOTE: All log files auto-delete after 48 hours and ONLY the Pi-hole developers can access your data via the given token. We have taken these extra steps to secure your data and will work to further reduce any personal information gathered.
Ping is not a reliable method to check DNS resolution. In your specific case, the first ping goes directly to an IP and there is no DNS resolution involved (Pi-hole sees nothing).
In the second case, there is DNS resolution involved, but even if the DNS resolution completes normally, the ping process may fail.
I see, any other way to properly debug it? I can't load or go on any website if it goes through IPv4 on my Pi-Hole
Your debug log is the primary debug tool. It is available to you locally (either on your screen or in the log file at /var/log/pihole/pihole_debug.log).
To make the file accessible to the developers, we have the upload option.
We will take a look at your log and see what's going on. There are a number of oddities.
Per your debug log, Pi-hole has the IPV4 IP of 192.168.2.9. Your default IPv4 gateway is 192.168.2.1 and the Pi-hole host OS can ping that address with success.
In your DHCP discover in the debug log, the following DHCP server responded: eth0:192.168.2.254. What is this device?
Your gravity database is empty, which results in no blocking. All your adlists are diabled.
*** [ DIAGNOSING ]: Gravity Database
-rw-rw-r-- 1 pihole pihole 96K Jul 26 15:54 /etc/pihole/gravity.db
*** [ DIAGNOSING ]: Info table
property value
-------------------- ----------------------------------------
version 15
updated 1722002059
gravity_count 0
Last gravity run finished at: Fri 26 Jul 15:54:19 CEST 2024
Your pihole.log shows that the Pi-hole is receiving A queries, is processing them and responding to the requesting client:
Jul 26 00:00:17 dnsmasq[25033]: query[A] imonster.antares.usbx.me from 192.168.2.1
Jul 26 00:00:17 dnsmasq[25033]: cached imonster.antares.usbx.me is <CNAME>
Jul 26 00:00:17 dnsmasq[25033]: forwarded imonster.antares.usbx.me to 2606:4700:4700::1111
Jul 26 00:00:17 dnsmasq[25033]: reply imonster.antares.usbx.me is <CNAME>
Jul 26 00:00:17 dnsmasq[25033]: reply antares.usbx.me is 46.232.210.167
...
Jul 26 15:56:17 dnsmasq[2691]: query[A] play.googleapis.com from 192.168.2.8
Jul 26 15:56:17 dnsmasq[2691]: forwarded play.googleapis.com to 2606:4700:4700::1111
Jul 26 15:56:17 dnsmasq[2691]: reply play.googleapis.com is 2001:4860:4802:36::223
Jul 26 15:56:17 dnsmasq[2691]: reply play.googleapis.com is 2001:4860:4802:34::223
Jul 26 15:56:17 dnsmasq[2691]: reply play.googleapis.com is 2001:4860:4802:32::223
Jul 26 15:56:17 dnsmasq[2691]: reply play.googleapis.com is 2001:4860:4802:38::223
Jul 26 15:56:17 dnsmasq[2691]: reply play.googleapis.com is 216.239.32.223
Jul 26 15:56:17 dnsmasq[2691]: reply play.googleapis.com is 216.239.36.223
Jul 26 15:56:17 dnsmasq[2691]: reply play.googleapis.com is 216.239.34.223
Jul 26 15:56:17 dnsmasq[2691]: reply play.googleapis.com is 216.239.38.223
Please elaborate on the problems you are experiencing with IPv4 compared to IPv6.
eth0:192.168.2.254 is the local ip adres of my router.
In my router I am using 192.168.2.9 as my DNS-server (the pi-hole).
I disabled all adlists to see if something was causing a problem or not.
I am not sure why those A-queries are going through, but I can't load anything and almost all devices on my network don't have a working internet connection when I use IPv4 only.
Your debug log is showing that your router is at 192.168.2.1. And then there is a DHCP server at .254 responding.
[i] Default IPv4 gateway(s):
192.168.2.1
* Pinging first gateway 192.168.2.1...
[✓] Gateway responded.
Scanning all your interfaces for DHCP servers
* Received 328 bytes from eth0:192.168.2.254
It's difficult to know how much of what you are seeing is down to your router setup. There is a separate DHCP server and your gateway is not at the address you think it's at.
I would suggest temporarily taking Pi-hole out of the equation and configuring your network so that it is laid out correctly and works. Ensure that devices on your network are using the router and have an Internet connection. This can then be considered a known working baseline.
Once that is in place you can introduce the Pi-hole at a fixed IPv4 address on the network and confirm that it too has an Internet connection. You can then test Pi-hole by making DNS requests against it and looking for a 0.0.0.0 response indicating the domain is blocked, for example:
nslookup flurry.com IP_OF_PIHOLE
Once confirmed as working, update the DHCP server to tell clients to use the Pi-hole for DNS.
It's okay to do that for testing, but while they are disabled they are not blocking anything, and the debug log is reflecting that.
Huh.. I have no idea how it ended up using 192.168.2.1; that is my android tv-receiver device, haha that is odd. I just changed my dhcpcd.conf to make use of the router.
Thank you so much for pointing that out. It all works now... What the hell haha
Ah good, that explains the lack of routing!
There was something else unusual in your log. Lots of entries in the error log like this:
-----head of error-pihole.log------
2024-07-21 00:00:01: (server.c.1848) logfiles cycled UID = 0 PID = 297671
2024-07-21 00:58:16: (connections.c.714) unexpected TLS ClientHello on clear port (x.x.x.x)
2024-07-21 06:11:49: (connections.c.714) invalid request-line -> sending Status 400 (x.x.x.x)
2024-07-21 06:44:44: (connections.c.714) unexpected TLS ClientHello on clear port (x.x.x.x)
2024-07-21 06:46:10: (connections.c.714) unexpected TLS ClientHello on clear port (x.x.x.x)
where x.x.x.x are all different public IP addresses. Do you by chance have your router interface exposed to the Internet, or even some port forwarding going on which would allow external traffic in? Something to be aware of and lock down as needed.
Thank you for mentioning that. The old software in use by my KPN-router doesn't allow to setup a proper firewall.
I have some ports open for SSH, JellyFin and Plex, but not 53 on the router. DMZ is also disabled so it should never even open them to begin with.
I currently have the following setting:
But from my understanding changing to the potentially dangerous options shouldn't be dangerous if 53 isn't exposed (port forwarding).
For some odd reason my router forwards that port even though I don't want it to.
See the docs linked below those options. The local option means Pi-hole is only responding to clients on the same subnet, and this is perfect for the vast majority of home users. The potentially dangerous options open it up progressively until Pi-hole is responding to any request from anywhere.
As long as you are happy that the only access to Pi-hole can come from trusted devices and networks, you can use those lower options to give the flexibility you need, for example to respond to requests from an adjacent subnet which is also bound to the same network interface.
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.
