Pi-Hole running on Ubuntu 18.x. When changing my router's DNS to PiHole, internet is not available for any devices other than the Pi-Hole host (DNS not resolving?) I suspect it has something to do with the failure to resolve the advertising link on a remove public DNS server.
The active IP on the device is:
*** [ DIAGNOSING ]: Networking
[✓] IPv4 address(es) bound to the enp7s0 interface:
192.168.68.62/22
But, Pi-hole is configured on a different IP:
*** [ DIAGNOSING ]: Setup variables
IPV4_ADDRESS=10.0.0.113/24
PIHOLE_INTERFACE=enp7s0
Run pihole -r and select the reconfigure option to get Pi-hole on the active IP and interface.
Thank you for your reply.
I reconfigured pi-hole and made sure the IP was 192.168.68.62, however the debug still shows 10.0.0.113 as the setup variables. Is there someway pi-hole is grabbing 10.0.0.113 from another file after the config wizard completes?
EDIT: I manually edited SetupVars.conf and repaired pihole again, it successfully changed the setup IP, but I still have the same error: https://tricorder.pi-hole.net/p612Yzr0/
Still looking for help. How could I reset whatever internet configurations my device has? I did move from one house to another with a different gateway. Although I searched the debug log for the old IP and I am not sure what else to try.
New log:
https://tricorder.pi-hole.net/Li1BoqmG/
You should verify your Pi-hole host machine's network configuration.
It would depend on your specific OS variety how and where to check that (and probably personal choice as well).
For a start, let's have a look at dhcpcd.conf, as for a long time that has been Pi-hole's target for setting a specific IP:
Run from your Pi-hole machine, what's the output of
grep -v '^#\|^$' /etc/dhcpcd.conf
:~$ grep -v '^#|^$' /etc/dhcpcd.conf
hostname
duid
persistent
option rapid_commit
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
option ntp_servers
option interface_mtu
require dhcp_server_identifier
slaac private
interface enp7s0
static ip_address=192.168.68.62/22
static routers=192.168.68.1
static domain_name_servers=
My OS is Ubuntu 18.04, willing to verify/reset network configuration however is recommended.
And what for below one?
grep -v '^#\|^$' -R /etc/netplan*
FYI:
pi@ph5b:~ $ apt show netplan.io
[..]
Description: YAML network configuration abstraction for various backends
netplan reads YAML network configuration files which are written
by administrators, installers, cloud image instantiations, or other OS
deployments. During early boot it then generates backend specific
configuration files in /run to hand off control of devices to a particular
networking daemon.
.
Currently supported backends are networkd and NetworkManager.
EDIT:
Ow ps, you should at least configure one or more DNS server IP's on above line for the host to be able to resolve through DNS.
Can be your router IP, your ISP provided DNS IP's or public DNS resolvers like Cloudflare, Quad9 etc.
And run below to apply (or reboot if still not working):
sudo service dhcpcd restart
:~$ grep -v '^#|^$' -R /etc/netplan*
/etc/netplan/01-network-manager-all.yaml:network:
/etc/netplan/01-network-manager-all.yaml: version: 2
/etc/netplan/01-network-manager-all.yaml: renderer: NetworkManager
To configure the DNS IP, I just edited the line in /etc/dhcpcd.conf, static domain_name_servers=192.168.68.1, (Router IP) is that correct?
Thats correct.
But NetworkManager is similar as what dhcpcd does:
pi@ph5b:~ $ apt show network-manager
[..]
Description: network management framework (daemon and userspace tools)
NetworkManager is a system network service that manages your network devices
and connections, attempting to keep active network connectivity when
available. It manages ethernet, Wi-Fi, mobile broadband (WWAN), and PPPoE
devices, and provides VPN integration with a variety of different VPN
services.
.
This package provides the userspace daemons and a command line interface to
interact with NetworkManager.
pi@ph5b:~ $ apt show dhcpcd5
[..]
Description: DHCPv4, IPv6RA and DHCPv6 client with IPv4LL support
dhcpcd is a one stop network management daemon which includes
* RFC compliant DHCPv4 and DHCPv6 clients
* DHCPv6 Prefix Delegation support
* IPv4LL (aka ZeroConf) support
* ARP address conflict resolution
* Link carrier detection
* Wireless SSID profiles
* ARP ping profiles
Is NM active?
systemctl status NetworkManager.service
I got that from:
pi@ph5b:~ $ apt-file list network-manager
[..]
network-manager: /lib/systemd/system/NetworkManager.service
Below might reveal its activities:
journalctl --full --no-pager -u NetworkManager.service
And below to see what dhcpcd does:
journalctl --full --no-pager -u dhcpcd.service
You cant have two network managers fighting over network control.
You either have to disable NM that comes with netplan and configure dhcpcd properly.
Or you disable dhcpcd and configure the netplan / network-manager combo with proper IP details.
dhcpcd can be disabled with below:
sudo systemctl disable --now dhcpcd.service
Am not sure how to disable NM that comes with netplan.
Ow it might be as simple as just hashing/commenting out above three lines and reboot.
Check below one afterwards:
systemctl status NetworkManager.service
NetworkManager.service is active and running.
The journalctl output of NetworkManager was long mostly filled with connectivity going on and off.
Aug 05 22:24:13 NetworkManager[1241]: <info> [1659752653.0061] manager: NetworkManager state is now CONNECTED_SITE
Aug 05 22:24:13 NetworkManager[1241]: <info> [1659752653.0062] policy: set 'Wired connection 1' (enp7s0) as default for IPv4 routing and DNS
Aug 05 22:24:14 NetworkManager[1241]: <info> [1659752654.0858] manager: NetworkManager state is now CONNECTED_GLOBAL
Aug 05 22:46:57 NetworkManager[1241]: <info> [1659754017.5985] connectivity: (enp7s0) timed out
Aug 05 22:46:57 NetworkManager[1241]: <info> [1659754017.5986] manager: NetworkManager state is now CONNECTED_SITE
Aug 05 22:51:30 NetworkManager[1241]: <info> [1659754290.0728] manager: NetworkManager state is now CONNECTED_GLOBAL
Aug 05 23:16:57 NetworkManager[1241]: <info> [1659755817.5986] connectivity: (enp7s0) timed out
Aug 05 23:16:57 NetworkManager[1241]: <info> [1659755817.6428] manager: NetworkManager state is now CONNECTED_SITE
Aug 05 23:21:28 NetworkManager[1241]: <info> [1659756088.7588] manager: NetworkManager state is now CONNECTED_GLOBAL
dhcpcd.service only has data from last year. repeating
Sep 11 23:50:23 dhcpcd[1206]: enp7s0: adding default route via [IPv6]
Sep 11 23:50:23 dhcpcd[1206]: if_route6 (ADD): File exists
Sep 11 23:50:26 dhcpcd[1206]: enp7s0: adding default route via [IPv6]
Sep 11 23:50:26 dhcpcd[1206]: if_route6 (ADD): File exists
I went ahead and stopped and disabled dhcpcd.service. After looking up the two services, I may not even need either since I am connected via ethernet and Ubuntu should have a native package to control?
Should I disable NM as well? How to test if disabling dhcpcd fixed the issue? I will reboot and retest pihole.
EDIT: Internet on the host machine is not working now
Am not that familiar with the netplan & NM combo but I believe static IP details need to be configured similar like below:
Afterwards you can check stuff with below commands:
Links and UP status:
ip -br l
Adresses:
ip -br a
Routes:
ip r
Neighbours:
ip n
Do mind the older iproute2 versions didnt support the -br argument yet so omit that bit if not working.
How did you configure networking?
Do you run a desktop and do it via the GUI?
netplan with NM is the default OOTB "native" manager for Ubuntu 18.x.
I do have a desktop and configure via GUI typically. I must have been mistaken about not needing NM if it is the default OOTB.
I configured the netplan static IP according to the instructions and the host computer has internet again, although the pihole error is still the same,
*** [ DIAGNOSING ]: Name resolution (IPv4) using a random blocked domain and a known ad-serving domain
[✓] qc65ga1dit4s3blyukv13vjfhn.org is 0.0.0.0 on lo (127.0.0.1)
[✓] qc65ga1dit4s3blyukv13vjfhn.org is 0.0.0.0 on enp7s0 (192.168.68.62)
[✓] doubleclick.com is 108.177.122.102 via a remote, public DNS server (8.8.8.8)
*** [ DIAGNOSING ]: Name resolution (IPv6) using a random blocked domain and a known ad-serving domain
[✓] www.wikipenza.info is :: on lo (::1)
[✓] www.wikipenza.info is :: on enp7s0 ([IP6])
[✗] Failed to resolve doubleclick.com via a remote, public DNS server (2001:4860:4860::8888)
Log: https://tricorder.pi-hole.net/h4i5EObh/
I appreciate the help so far.
If you run a desktop, configure static network settings via the GUI tool and not manually in .yaml config files.
The GUI tool will take care of how NM will be configured.
Dont forget to configure DNS server(s)!
And check with the ip commands I provided.
Ow above is not an error per se.
It just informs you that DNS resolution via IPv6 failed.
Resolution via IPv4 only works just fine.
(EDIT: You can lookup IPv6 addresses via IPv4 and vice versa)
Do you have IPv6 support upstream from your ISP?
:~$ ip -br l
lo UNKNOWN 00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
enp7s0 UP 04:d4:c4:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>
:~$ ip -br a
lo UNKNOWN 127.0.0.1/8 ::1/128
enp7s0 UP 192.168.68.62/23 [IP6]
:~$ ip r
default via 192.168.68.1 dev enp7s0 proto static metric 100
169.254.0.0/16 dev enp7s0 scope link metric 1000
192.168.68.0/23 dev enp7s0 proto kernel scope link src 192.168.68.62 metric 100
:~$ ip n
192.168.68.61 dev enp7s0 lladdr 8c:b8:7e:XX:XX:XX REACHABLE
192.168.68.1 dev enp7s0 lladdr c0:06:c3:XX:XX:XX REACHABLE
192.168.68.54 dev enp7s0 lladdr 00:17:88:XX:XX:XX STALE
My ISP does not support upstream IPv6 according to that test. Not a problem to me. I guess the overall issue is that when using the pihole as the DNS in my router, all devices lose internet connection.
Check if you run a firewall that might block stuff:
sudo nft list tables
sudo iptables -nL
Check if the own host can resolve domains to IP's:
host pi-hole.net
Check if pihole-FTL is answering when queried:
host pi.hole localhost
host pi.hole 192.168.68.62
Check if still resolves to an IP if the domain needs to be forwarded upstream:
host pi-hole.net 192.168.68.62
Grab a Linux/Windows/MacOS client and run below on it to see if it resolves:
nslookup pi.hole 192.168.68.62
And without the Pi-hole IP:
nslookup pi.hole
If that all works, you've proven that pihole-FTL functions as expected and need to look into router/client settings.
Maybe your router has got some protective settings for which you must create an exception for Pi-hole or maybe even disable it.
Well I just realized I was using the default policies of UFW, which blocks ports 53 and 67. I followed the instructions here: Prerequisites - Pi-hole documentation and everything clicked into place and my clients connected to the internet and pi-hole is now functioning!
I do appreciate the education on dhcpcd, and netplan. Thanks for your time!
Sweet.
I marked your last reply as a solution if you dont mind.