I installed pihole in an Ubuntu 22.04 LXC container.
this is my network configuration in proxmox:
FROM THE PiHOLE LXC CONTAINER:
I can not ping www.google.com or my router 192.168.1.1, get updates with apt update, apt upgrade, e.t.c.
I can though ping 8.8.8.8
FROM MY PC:
i can ping the container
i can ssh into container
my /etc/dhcpcd.conf is empty
my /etc/network/interfaces is empty
my /etc/resolv.conf is:
# ---BEGIN PVE---
search home
nameserver 1.1.1.1
# ---END PVE---
i cant upload a debug token since i have no connection.
i also have set as both my Primary and Secondary DNS on my router the container but my network works fine. maybe it's because no device is connecting to pihole on my tools -> network page.
EDIT 1: after router and container reboot, the nameserver in /etc/resolv.conf is 192.168.1.1. Other than that, it is all the same
EDIT 2: I reset my router DNS settings, and now my internet connectivity is back. What am i missing?
This doesn't seem related to Pi-hole:
You have OS level issues preventing you from updating your OS.
And as you can't ping your router's IP, that may suggest your container does not integrate into your private network correctly.
the issue i'm having started right after i installed pihole. I mean, i needed an internet connection to install it right? and i had it working properly. i even spun up another container on my cluster (not installing pihole) just to see if there is any setting i missed. But the container is working properly.
It must be something that pihole jiggled with and i cant find it
Hmm, I'd assume you would have used your host system's network connection to download a Pi-hole image and starting a container from it? Or are you referring to a different method of installation?
Anyway, the only way that Pi-hole could be involved here would be if DNS wouldn't work as expected.
It's obvious that DNS may have an impact in accessing your OS's repositories by domain names.
But DNS is not involved at all if you ping by IP address. As you can't ping your router at 192.168.1.1, that raised my concerns about your private range network connectivity.
To verify Pi-hole is operational for your clients, please run the following commands from a client:
nslookup pi.hole
nslookup flurry.com
nslookup flurry.com 192.168.1.102
(assuming that your Pi-hole lives at 192.168.1.102)
fun thing is, as i mentioned in my edits, after i remove my pihole as a dns from my router, i get my internet back and i can ping my router and all of my devices on the network. am i missing something here?
That client isn't using Pi-hole for DNS, but your router at 192.168.1.1.
Your router is capable of providing resolution of public domain names, but it is not returning the 0.0.0.0 block for flurry.com (of course).
This would imply that clients should be able to use 192.168.1.1 for DNS without issues (but by-passing PI-hole's filtering, of course ).
The last nslookups demonstrates that Pi-hole is correctly receiving and filtering DNS requests - provided those requests would go to Pi-hole.
Together, this would leave me at a loss when trying to explain how Pi-hole could be involved in your observation: According to your information, your container is using 192.168.1.1 for DNS, and your nslookup has demonstrated that to work, at least from outside the container.
Could you please run the same set of nslookups from within the container?
correct me if i'm wrong but shouldn't all my clients use my router (192.168.1.1) as their DNS? and then my router using my container running pihole (192.168.1.102) as its DNS, so all my DNS requests get to my router and then to pihole to resolve?
on your requests now:
when having set my router DNS as my pihole, my pihole container returns:
;; communications error to 192.168.1.1#53: timed out
on both pi.hole and flurry.com
when having set my router DNS as my ISP's default (or 1.1.1.1), pihole returns:
Server: 192.168.1.1
Address: 192.168.1.1#53
** server can't find pi.hole: NXDOMAIN
For flurry.com, and for flurry.com 192.168.1.102, pihole returns the same as the picture above
That would directly depend on your router's configuration.
If you did configure it to use Pi-hole as its upstream DNS resolver (commonly, a WAN/Internet kind of setting), then your assumption would be correct.
If you instead (or in addition) did configure your router to distribute Pi-hole as local DNS server (often, a LAN/DHCP setting), then DHCP clients with a current DHCP lease would use Pi-hole for DNS.
Both router configuration variants are valid, but the latter would be the preferred approach, as it would allow Pi-hole to attribute DNS requests to individual clients.
Your previous nslookup results do imply that Pi-hole was not used for DNS for those specific requests at all, neither directly nor indirectly.
If both nslookups for pi.hole as well as flurry.com have failed that way, then that would suggest that something is blocking DNS requests on the way from your router to the container.
As Pi-hole would return a private range IP for pi.hole:
Is your router's DNS rebind protection active for pi.hole?
If so, can you exempt your Pi-hole from it?
And did the request for flurry.com register in Pi-hole's Query Log at all?
If not, then a firewall rule for the container or the container's host may block Pi-hole's required ports (though your previous results make that unlikely).
i see in my pihole dashboard that a query to flurry.com was indeed blocked when i did the nslookup for it with my mac. I'm gonna fiddle around in my router settings to try and find something about DNS rebind protection. though i doubt i'll find anything. my router is as crappy as generic ISP routers get
The more interesting flurry.com DNS query is the one that was met with a time-out, in particular to confirm or reject whether that request did reach Pi-hole or not.
as expected i couldn't find anything about rebind protection on my router. if it is of any help, my dns settings on my router are on the "network configuration" tab, where my isp credentials and other settings for the wan connection live (VPI/VCI, MTU, etc). My DHCP settings have only one drop down option: enable, disable or set as a relay the routers DHCP server.
Perhaps, as it would provide some additional insights.
It may also reveal other, unrelated issues that would or could need addressing.
Sharing your router's make and model (and perhaps firmware) may also help in attracting users experienced in configuring that specific device for Pi-hole.
Have you been able to research those time-out lookups?
Your Pi-hole log looks normal - almost:
It is showing that your Pi-hole has been receiving DNS requests from public IP addresses (e.g. 94<redacted>61).
(It may seem like that, but in between, I've been away for 10 hours at least. )
Ok, that finally allows for an explanation then.
Your router only supports configuring upstream DNS resolvers.
It seems it is also assuming those DNS resolvers would be public ones, so it is using its public IP for sending DNS requests.
Your Pi-hole, however, is residing at a local, private range IP address, and what's more, it is by default ignoring DNS requests that are not local - hence the time-outs.
You should consider to disable your router's DHCP server and enable Pi-hole's instead.
You must make sure that Pi-hole's IP is static in that case - your earlier screenshots would suggest that you've done so, and Pi-hole is residing at a static 192.168.1.102.
Clients would need to acquire a DHCP lease with Pi-hole's DHCP server for that to work.
You could force a client to do so, e.g. by dis- and reconnecting it to your network, or by power-cycling it.
noted. what about clients that already have a static local ip (such as my proxmox server and/or my pc? will pihole automatically find them or should i do something else?
Clients would always need to be configured for DNS, one way or another.
Manually static configuration clients must also be manually pointed to use Pi-hole for DNS.
Alternatively, since Pi-hole is going to act as DHCP server, then you may consider to define DHCP lease reservations for those previous static clients via Pi-hole's Static DHCP leases configuration.
).