Pihole wrong client IP & DHCP not detected

Help
1

Hello everyone, I hope you're having a good day, thank you for trying to help me.

Expected Behaviour:

1- IP shown on the query logs should be client local address IP
2- When DHCP is activated on pihole and desactivated on router, dhcp clients should be able to see DCHP server using command below:

nmap --script broadcast-dhcp-discover -e enp2s0

Actual Behaviour:

1-It's showing Pihole IP address

image
image982×620 39.8 KB

2- Pihole DCHP is not found even on the same machine that it is running on

  • Router DHCP ON, Pihole DHCP OFF (this config works):
nmap --script broadcast-dhcp-discover -e enp2s0

Starting Nmap 7.60 ( https://nmap.org ) at 2020-01-31 11:58 CET
Pre-scan script results:
| broadcast-dhcp-discover:
|   Response 1 of 1:
|     IP Offered: 192.168.1.28
|     DHCP Message Type: DHCPOFFER
|     Server Identifier: 192.168.1.254
|     IP Address Lease Time: 12h00m00s
|     Subnet Mask: 255.255.255.0
|     Router: 192.168.1.254
|     Domain Name Server: 192.168.1.92
|_    Broadcast Address: 192.168.1.255

Router DHCP OFF, pihole DHCP ON (this config does not work)

nmap --script broadcast-dhcp-discover -e enp2s0

Starting Nmap 7.60 ( https://nmap.org ) at 2020-01-31 11:59 CET
WARNING: No targets were specified, so 0 hosts scanned.
Nmap done: 0 IP addresses (0 hosts up) scanned in 10.31 seconds

Debug Token:

zadk9czen8

Additional information

Alright, more info on this issue:

Pihole works perfectly fine, however it shows it's own IP address as you saw.

Because everyone recommends to activate pihole DHCP instead of router DHCP to solve this issue, I did it, then only my static IP devices were able to keep internet connection and no DHCP client were able to find pihole DHCP server

my DNS configuration now is the following:

Domain clients->samba DNS (192.168.1.91) --forward--> Pihole DNS 192.168.1.92 -->Google DNS
Non Domain clients --> Router DNS (192.168.1.254) --forward-->pihole DNS 192.168.1.92 -> Google DNS

I'm using Ubuntu 18.04 and Netplan with networkd as renderer.

I hope all this information will help you to identify the issue and help me, thank you very much for your time and efforts.

Have a nice day.

3

I believe a firewall is blocking inbound UDP requests for port 67 and 68.

Everything looks good in your debug log. Make sure your Ubuntu doesn't have a firewall enabled that restricts those ports.

4

Thank you for your answer.

I just allowed ports 67 & 68 on my firewall.

As you can see in my log I have several NICs, however only 1 is interesting here

enp2s0 is 192.168.1.91 and is used for samba ad dc DNS
vlan11 is made on enp2s0 , its ip is 192.168.1.92 and is used for pihole.

Reminder of how dns queries work in my config:

Domain clients->samba DNS (192.168.1.91) --forward–> Pihole DNS 192.168.1.92 -->Google DNS

Now I've found some more info:

When I run this command nmap --script broadcast-dhcp-discover -e vlan11 I can see the DHCP server and I have this as a result on pihole.log

Jan 31 18:27:20 dnsmasq-dhcp[29700]: DHCPDISCOVER(vlan11) de:ad:c0:de:ca:fe
Jan 31 18:27:20 dnsmasq-dhcp[29700]: DHCPOFFER(vlan11) 192.168.1.29 de:ad:c0:de:ca:fe

However when I run this command nmap --script broadcast-dhcp-discover -e enp2s0 I can't see the server anymore even if they're part of the same subnet ! also nothing on the logs.

The result of sudo netstat -peanut | grep :67
udp 0 0 0.0.0.0:67 0.0.0.0:* 999 2248826 29700/pihole-FTL

I think one of the ways to find the issue should start from here:

  • Why am I not able to see the DHCP from the same interface using another IP
  • Why don't I see 192.168.1.92:67 with the netstat command ?
5

I think it has something to do with this setup. I never used samba for anything but sharing files (and ditched it because ... samba).
I don't know how that whole thing is working ....

6

Try run nmap from a client PC.
Running nmap from the same host thats serving DHCP is going to fail.

Sounds like rebind protection:

Try enable DHCP on Pi-hole,
connect a client PC, with network settings set to auto, directly to Pi-hole without router in between and
run below one on the client to check if resolves:

nslookup pi.hole

7

Try run nmap from a client PC.
Running nmap from the same host thats serving DHCP is going to fail.

All my clients are windows sadly..

Because everyone recommends to activate pihole DHCP instead of router DHCP to solve this issue, I did it, then only my static IP devices were able to keep internet connection and no DHCP client were able to find pihole DHCP server

Sounds like rebind protection:
What is DNS rebind protection? If your router has an option called DNS rebind protection enabled, you may run into issues when trying to use Pi-hole as your DNS server. The reasons for this are quite technical, but to summarize what this option does in one sentence: DNS rebind protection does not allow DNS queries to be answered with a local IP address. Why does this interfere with Pi-hole? DNS rebind is meant to be a countermeasure to an attack on your network. So in many cases, it’s actu…

Can't be this, DNS is being forwarded correctly to pihole and the config works perfectly.

I think the culprit here is the fact that pi-hole is not listening on port 67 as the previous answer show it, also tried this nmap 192.168.1.92

Nmap scan report for 192.168.1.92
Host is up (0.000060s latency).
Not shown: 998 closed ports
PORT   STATE SERVICE
53/tcp open  domain
80/tcp open  http

As you can see, the port 76 is not shown as open, that's why nothing is able to communicate with it.

Do you have any idea why pihole is not listening on that port ?

8

I would not know how broadcasting a DHCPDISCOVER to a certain virtual network device would be handled when VLANs are involved additionally ..

DHCP is making use of broadcasts, visible only for devices on the same network segment.
VLANs are limiting broadcasts to devices on participating ports (and clients, if tagged and they are VLAN aware), so in your setup, this is a likely source of interference that may be tricky to troubleshoot (To help with that: nmap is officially available as a Windows binary also).

But maybe that is not necessary - let's take a look at your original problem first:

It seems that you are seeing Pi-hole as only source of your DNS queries, and you are trying to alleviate this by making Pi-hole your DHCP server, as related by recommendations here on these forums.

Yet, the vast majority of those recommendations apply to a scenario where a router appears as the only source of DNS requests, specifically when the router can only be configured to redirect its upstream DNS traffic to Pi-hole (as opposed to distribute Pi-hole as local DNS server).

Your setup differs:
Pi-hole is correctly distributed as local DNS server.
It is just showing DNS queries to orginate from Pi-hole itself (i.e. not a router).

With all likelihood, this can be attributed directly to the fact that you are forwarding your DNS requests to Pi-hole from a Samba instance on the same machine:

(..) samba DNS (192.168.1.91) --forward–> Pihole DNS 192.168.1.92 (..)

I am afraid that setting up Pi-hole as DHCP will not change this:
Samba will still be the originator of all DNS requests your Pi-hole will ever see.

Furthermore, I am unaware of any concrete means to circumvent this.

Forwarding or copying your DNS packets through an elaborate series of iptables rules where you hold on to the original request's source address might work, but I do not have any ready-to-use recommendations here. :thinking:

1 Like
9

Thank you very much for that detailed analysis.

So, about this part:

would not know how broadcasting a DHCPDISCOVER to a certain virtual network device would be handled when VLANs are involved additionally …

DHCP is making use of broadcasts, visible only for devices on the same network segment.
VLANs are limiting broadcasts to devices on participating ports (and clients, if tagged and they are VLAN aware), so in your setup, this is a likely source of interference that may be tricky to troubleshoot (To help with that: nmap is officially available as a Windows binary also).

I've additional info and tested that I've tried, the reason for that VLAN interface is just to be able to put pihole on it on the same NIC, if you have other suggestion please feel free to share as I think you're more experienced than I am.

Also, Yesterday, I've tried something I created an isc-dhcp-server on the exact same card as pihole is installed on, I've kept router DHCP OFF and pihole DHCP ON.

What happened is the isc-dhcp-server worked instantly and succesfully, was able to be seen from all the local network.

In short, isc-dhcp-server & pihole DHCP server on the same interface, still, every device was able to see isc-dhcp-server.

I think that this way I can now say that the issue seems to come from pihole DHCP, there is something stopping it from working properly as DHCP server.

I will wait for your suggestions, also on the same time this afternoon I'll try to watch the logs when pihole DHCP is turning on.

Is there any way to see DHCP logs on pihole with the maximum of details possible ?

With all likelihood, this can be attributed directly to the fact that you are forwarding your DNS requests to Pi-hole from a Samba instance on the same machine:

    (…) samba DNS (192.168.1.91) --forward–> Pihole DNS 192.168.1.92 (…)

I am afraid that setting up Pi-hole as DHCP will not change this:
Samba will still be the originator of all DNS requests your Pi-hole will ever see.

Samba is 192.168.1.91, that's why I'm not really sure about that, I will try to intervert the location of samba & pihole in the loop this afternoon and see what happens.

Thanks to all of you for your support and suggestions, I'm not asking people for a direct solution that they're sure it works, I'm just asking to post here any ideas that can help me to "unblock" my thinking by giving my new ideas/solutions.

10

Good news !

Problem solved, a lot of you pointed that the potential problem was this:

(…) samba DNS (192.168.1.91) --forward–> Pihole DNS 192.168.1.92 (…)

I've changed the setup and put samba as the primary DNS on samba client, which make the setup like this:

Domain clients->Pihole DNS 192.168.1.92–>samba DNS (192.168.1.91) -->Google DNS
Non Domain clients --> Router DNS (192.168.1.254) --forward–>pihole DNS 192.168.1.92 -> SambaDNS --> Google NDS

This way, my samba clients are first contacted by pihole and pihole is getting the names and even the hostnames correctly !
I didn't want to do that at first because
1- I was afraid that non domain clients will be blocked if they try to pass through samba DNS, as Samba will be the main forwarded to google DNS, but somehow it works.
2- Non domain users in my local network are now able to see my domain users...

Problem 1 (the main issue) have been solved with your help, however I would have loved if there was "another way" of doing it without exposing my domain to whole local network.

Still, it was not a pihole issue so thank you very much everyone, have an excellent day.

11

My mistake :wink:
Next time you diagnose DHCP issues on a Windows client, use below ones to release/renew DHCP lease:

ipconfig /release

ipconfig /renew

And check network config with below one:

ipconfig /all

And at same time tail the logs on Pi-hole filtering/grepping for DHCP:

tailf /var/log/pihole.log | grep dnsmasq-dhcp

And for nmap, as @Bucking_Horn already mentioned, a client sends out a broadcast packet targeting port 67 UDP intended to be received by all hosts on your network segment except the own host of course.
Thats why you cant run nmap with DHCP broadcast discovery on the host doing DHCP.
If Pi-hole is configured to do DHCP on port 67 UDP, below one should display listening ports used by Pi-hole:

sudo netstat -nltup | grep 'Proto\|:53 \|:67 \|:80 \|:471[1-8] '

And when run nmap without arguments, I believe it only scans the first 1000 common ports on TCP and not UDP:

pi@noads:~ $ sudo nmap 10.0.0.2

Starting Nmap 7.40 ( https://nmap.org ) at 2020-02-01 18:07 CET
Nmap scan report for noads.dehakkelaar.nl (10.0.0.2)
Host is up (0.00021s latency).
Not shown: 997 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
53/tcp  open  domain
80/tcp  open  http

Nmap done: 1 IP address (1 host up) scanned in 6.42 seconds

If want it to scan for UDP, you'd have to tell nmap to do so like in below example:

pi@noads:~ $ sudo nmap -sU 10.0.0.2

Starting Nmap 7.40 ( https://nmap.org ) at 2020-02-01 18:07 CET
Nmap scan report for noads.dehakkelaar.nl (10.0.0.2)
Host is up (0.00038s latency).
Not shown: 997 closed ports
PORT    STATE         SERVICE
53/udp  open          domain
67/udp  open|filtered dhcps
68/udp  open|filtered dhcpc

Nmap done: 1 IP address (1 host up) scanned in 128.29 seconds
12

Alright, here is what nmap -sU 192.168.1.92 is giving:

Starting Nmap 7.60 ( https://nmap.org ) at 2020-02-01 23:52 CET
mass_dns: warning: Unable to open /etc/resolv.conf. Try using --system-dns or specify valid servers with --dns-servers
mass_dns: warning: Unable to determine any DNS servers. Reverse DNS is disabled. Try using --system-dns or specify valid servers with --dns-servers
Nmap scan report for 192.168.1.92
Host is up (0.000016s latency).
Not shown: 995 closed ports
PORT     STATE         SERVICE
53/udp   open          domain
67/udp   open|filtered dhcps
500/udp  open          isakmp
1701/udp open|filtered L2TP
4500/udp open|filtered nat-t-ike

So you were right and the ouput is different, we actually see the port thank you !

However the port is... open ? but I don't understand the filtered part, can anybody give a hint on that ?

Quick update: here is my ufw status on port 67 so I don't really understand why it's filtered

[27] 67/udp                     ALLOW IN    Anywhere
13

From the man page:

pi@noads:~ $ man nmap
[..]
             The state is either open, filtered, closed, or unfiltered.
       Open means that an application on the target machine is listening
       for connections/packets on that port.  Filtered means that a
       firewall, filter, or other network obstacle is blocking the port
       so that Nmap cannot tell whether it is open or closed.  Closed
       ports have no application listening on them, though they could
       open up at any time. Ports are classified as unfiltered when they
       are responsive to Nmap's probes, but Nmap cannot determine
       whether they are open or closed. Nmap reports the state
       combinations open|filtered and closed|filtered when it cannot
       determine which of the two states describe a port.
[..]
14

This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.