Can't get pihole to work on br0 interface

jbee · December 11, 2019, 10:58am

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

Expected Behaviour:

Pihole DNS server works on virtual bridge.

Actual Behaviour:

Pihole DNS server does not work on virtual bridge.

Debug Token:

https://tricorder.pi-hole.net/7jih3upjao

My /etc/network/interfaces configuration is as follows:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
auto virbr0
iface virbr0 inet dhcp
        bridge_ports    eth0
        bridge_stp              off
        bridge_maxwait  0
        bridge_fd               0

When installing, I install Pihole on virbr0.

pihole status reports
[✓] DNS service is running
[✓] Pi-hole blocking is Enabled

deHakkelaar · December 11, 2019, 9:09pm

Pointers for bridge setup halfway down in below posting of mine:

Ps. dhcpcd5 gets installed as "network manager" to deal with IP settings etc:

pi@noads:~ $ apt policy dhcpcd5
dhcpcd5:
  Installed: 1:6.11.5-1+rpt7
[..]

pi@noads:~ $ man dhcpcd5
[..]
DESCRIPTION
     dhcpcd is an implementation of the DHCP client specified in RFC
     2131.  dhcpcd gets the host information (IP address, routes, etc)
     from a DHCP server and configures the network interface of the
     machine on which it is running.  dhcpcd then runs the configuration
     script which writes DNS information to resolvconf(8), if available,
     otherwise directly to /etc/resolv.conf.  If the hostname is cur‐
     rently blank, (null) or localhost, or force_hostname is YES or TRUE
     or 1 then dhcpcd sets the hostname to the one supplied by the DHCP
     server.  dhcpcd then daemonises and waits for the lease renewal
     time to lapse.  It will then attempt to renew its lease and recon‐
     figure if the new lease changes when the lease beings to expire or
     the DHCP server sends message to renew early.

     If any interface reports a working carrier then dhcpcd will try and
     obtain a lease before forking to the background, otherwise it will
     fork right away.  This behaviour can be modified with the -b,
     --background and -w, --waitip options.
[..]

jbee · December 12, 2019, 6:47am

Hey deHakkelaar,

Thanks for the response. I didn't know that pihole was using dhcpcd5 as a dhcp client. If that's the case, what I would rather do would be to remove dhcpcd5 instead apt-get remove --purge dhcpcd5, and let the old school network manager handle dhcp client duties.

A little bit of background, the bridge is for VMs running on QEMU/KVM. When one comes up, it's automatically added to the bridge.

Here's an updated interfaces file:

# The loopback network interface
auto lo
iface lo inet loopback

# The eth0 interface
iface eth0 inet manual

# The primary network interface
auto virbr0
iface virbr0 inet dhcp
        bridge_ports    eth0
        bridge_stp              off
        bridge_maxwait  0
        bridge_fd               0

Here's the output of ifconfig for relevant interfaces:

eth0      Link encap:Ethernet  HWaddr d4:3d:7e:9e:9d:e2
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7146 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5408 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:1004296 (1.0 MB)  TX bytes:696453 (696.4 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:1097 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1097 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:83246 (83.2 KB)  TX bytes:83246 (83.2 KB)

virbr0    Link encap:Ethernet  HWaddr d4:3d:7e:9e:9d:e2
          inet addr:192.168.0.201  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: 2606:6000:cd41:5d00:a14a:b1ff:e129:cb63/64 Scope:Global
          inet6 addr: 2606:6000:cd41:5d00:d63d:7eff:fe9e:9de2/64 Scope:Global
          inet6 addr: fe80::d63d:7eff:fe9e:9de2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:6937 errors:0 dropped:0 overruns:0 frame:0
          TX packets:5408 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:852990 (852.9 KB)  TX bytes:696453 (696.4 KB)

And Pihole is still failing to resolve.

https://tricorder.pi-hole.net/l6afmoa0a5

However.

If I install Pihole on eth0 instead of virbr0, DNS resolution works the first time after install. After a reboot, it no longer works. Here's the ifconfig output after reboot.

eth0      Link encap:Ethernet  HWaddr d4:3d:7e:9e:9d:e2
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:334 errors:0 dropped:0 overruns:0 frame:0
          TX packets:272 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:46977 (46.9 KB)  TX bytes:36266 (36.2 KB)

lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:587 errors:0 dropped:0 overruns:0 frame:0
          TX packets:587 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1
          RX bytes:45963 (45.9 KB)  TX bytes:45963 (45.9 KB)

virbr0    Link encap:Ethernet  HWaddr d4:3d:7e:9e:9d:e2
          inet addr:192.168.0.201  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: 2606:6000:cd41:5d00:e896:ffb:91a6:f0cf/64 Scope:Global
          inet6 addr: 2606:6000:cd41:5d00:d63d:7eff:fe9e:9de2/64 Scope:Global
          inet6 addr: fe80::d63d:7eff:fe9e:9de2/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:334 errors:0 dropped:0 overruns:0 frame:0
          TX packets:272 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:42217 (42.2 KB)  TX bytes:36266 (36.2 KB)

user@server:~$ sudo pihole status
  [✗] DNS service is NOT running

Now I run dhclient eth0 and get an IP address for eth0 (201 as reserved by my router), and run pihole restartdns. It works!

Okay, so it looks like the issue is maybe that eth0 should be configured by dhcp at boot? After all, that's what I'm doing manually with dhcp client eth0, right?

So I change my /etc/network/interfaces file to:

# The loopback network interface
auto lo
iface lo inet loopback

# The eth0 interface
auto eth0
iface eth0 inet dhcp

# The primary network interface
auto virbr0
iface virbr0 inet dhcp
        bridge_ports    eth0
        bridge_stp              off
        bridge_maxwait  0
        bridge_fd               0

and reboot.

However, now I can't ping or ssh into my server. Is it because both eth0 and virbr0 are getting the same dhcp config as eachother, and they're on a bridge, so there's contention?

If I run a dhclient eth0 followed by pihole restartdns once again, everything works. Am I supposed to install pihole on the eth0 interface instead of the bridge? What networking options am I screwing up to get this to work at boot?

Bucking_Horn · December 12, 2019, 2:22pm

It would seem that this isn't strictly a Pi-hole issue, but likely your VM's network configuration needing optimisation. My following considerations try to highlight two possible issues, but you probably have more luck searching associated resources at the respective QEMU / KVM / libvirt sites.

If you did setup your VM's networking yourself, you may need to configure iptables to handle traffic between your network interfaces.

However, as you've recently added this piece of information:

If you installed libvirt along with KVM, libvrt will likely have configured iptables as necessary.

Be aware that libvirt starts a new instance of dnsmasq for each virtual network.
This might cause conflicts with Pi-hole's dnsmasq instance if both instances try to bind the same network interface.

By default, dnsmasq will try to bind all addresses, even if configured to listen only on specific interfaces - it just discards requests from unconfigured interfaces.

To avoid such conflicts, you have to force dnsmasq to bind only the very interfaces it is listening to. You can do that by enabling the bind-interfaces option within dnsmasq.

Whether you should apply this to libvrt's dnsmasq or Pi-hole's or both and what interfaces would go where will likely depend on your specfific configuration needs.
Should you decide to alter Pi-hole's dnsmasq configuration, you could do so by adding a custom file like /etc/dnsmasq.d/99-kvm-coexistence.conf with the necessary options.

jbee · December 12, 2019, 3:01pm

I wouldn't imagine this to be a libvrt issue, as the VMs are never spun up during this whole topic, and the bridge interface only has eth0 on it during this time (this is all on the host machine, btw)

user@server:~$ brctl show
bridge name	bridge id		STP enabled	interfaces
virbr0		8000.d43d7e9e9de2	no		eth0

At this point, I think it's more of a networking configuration issue on the host, but I'm missing the key to get it working after a reboot without intervention.

Again, when I install pihole on eth0, it works after a reboot but only after I run dhcp eth0 and restart pihole. When I run dhcp eth0, what is dnsmasq doing, or fixing, so that I can implement a permanent solution? Or maybe I'm misunderstanding your last reply.

deHakkelaar · December 12, 2019, 3:48pm

iptables not involved in this.
Most hypervisors use a bridge to connect the virtual interfaces created for the VM's to the physical network layer:

root@xen01:~# xm list
Name                                        ID   Mem VCPUs      State   Time(s)
Domain-0                                     0  1023     1     r----- 257092.1
gam01.dehakkelaar.nl                        39  4096     4     -b----  24360.3
vps01.xbian.org                             35  4096     6     -b---- 14298699.0
zandbak.dehakkelaar.nl                       2  4096     2     -b---- 5798190.1
zb01.dehakkelaar.nl                         38  4096     2     -b---- 135555.8

root@xen01:~# brctl show
bridge name     bridge id               STP enabled     interfaces
xenbr0          8000.001e0bxxxxxx       no              eth0
                                                        vif2.0
                                                        vif38.0
xenbr1          8000.feffffffffff       no              vif2.1
                                                        vif35.0
                                                        vif38.1
                                                        vif39.0

root@xen01:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master xenbr0 state UP qlen 1000
    link/ether 00:1e:0b:xx:xx:xx brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN qlen 1000
    link/ether 00:1e:0b:xx:xx:xx brd ff:ff:ff:ff:ff:ff
5: xenbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether 00:1e:0b:xx:xx:xx brd ff:ff:ff:ff:ff:ff
       valid_lft forever preferred_lft forever
6: xenbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP
    link/ether fe:ff:ff:xx:xx:xx brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.1/24 brd 192.168.0.255 scope global xenbr1
       valid_lft forever preferred_lft forever
8: vif2.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master xenbr0 state UP qlen 32
    link/ether fe:ff:ff:xx:xx:xx brd ff:ff:ff:ff:ff:ff
       valid_lft forever preferred_lft forever
9: vif2.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master xenbr1 state UP qlen 32
    link/ether fe:ff:ff:xx:xx:xx brd ff:ff:ff:ff:ff:ff
       valid_lft forever preferred_lft forever
52: vif35.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master xenbr1 state UP qlen 32
    link/ether fe:ff:ff:xx:xx:xx brd ff:ff:ff:ff:ff:ff
       valid_lft forever preferred_lft forever
55: vif38.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master xenbr0 state UP qlen 32
    link/ether fe:ff:ff:xx:xx:xx brd ff:ff:ff:ff:ff:ff
       valid_lft forever preferred_lft forever
56: vif38.1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master xenbr1 state UP qlen 32
    link/ether fe:ff:ff:xx:xx:xx brd ff:ff:ff:ff:ff:ff
       valid_lft forever preferred_lft forever
57: vif39.0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master xenbr1 state UP qlen 32
    link/ether fe:ff:ff:xx:xx:xx brd ff:ff:ff:ff:ff:ff
       valid_lft forever preferred_lft forever

deHakkelaar · December 12, 2019, 3:51pm

Whenever you run the updater pihole -up or repair/reconfigure pihole -r , dhcpcd5 will get reinstalled and mangle your IP setup!
Below how to prevent:

You want to assign a static IP to the bridge interface for at least two reasons I can think of.

Make your hypervisor independent from your router's DHCP service so a router reboot wont affect your setup;
If want to use Pi-hole's build in DHCP service, you would need to disable the DHCP service on the router in which case your hypervisor would lose IP settings.

Try assign static IP like below with 192.168.0.10 IP and /24 subnet mask as an example:

# The loopback network interface
auto lo
iface lo inet loopback

# The eth0 interface
iface eth0 inet manual

# The primary network interface
auto virbr0
iface virbr0 inet static
        address 192.168.0.10
        netmask 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
        gateway 192.168.0.1
        bridge_ports    eth0
        bridge_stp      off
        bridge_maxwait  0
        bridge_fd       0

And run reconfigure to select bridge interface:

pihole -r

EDIT: !!!! I made mistake, virbr0 needs to be set to static !!!!
ARggggg static

jbee · December 12, 2019, 4:07pm

EDIT: !!! I made mistake, virbr0 needs to be set to static !!!

I was just about to comment on that

I will try that out as soon as I get home and see if it helps on reboot. I thought getting a reserved IP from the router would be the "cleaner" way of doing it, but I agree with your points, I'll configure a static IP on the box itself and try it out.

Bucking_Horn · December 12, 2019, 4:11pm

You don't have to - check whether dnsmasq is running a separate instance on your system to rule this out as a possible cause You also could explore why pihole-FTL failed to start.

Also, if you are indeed using libvirt, I wonder about your brctl show just listing virbr0.
I don't run KVM myself atm, but in the installations I remember, br0 was bridging eth0 while virbr0 was not bound to any interface at all. I also wonder why your bridge iface is set to use DHCP, as I remember that to be static.

It's hard to tell whether this observation qualifies as a reason of concern without detailed knowledge of your setup, though

deHakkelaar · December 12, 2019, 4:19pm

Yeah first get bridge interface up and running in such a way that you can SSH into the IP.
Afterwards diagnose other issues.
Below one might be helpful showing processes:

ps -e

Or check for listeners:

sudo netstat -nltup

Bucking_Horn · December 12, 2019, 4:24pm

That would depend on your needs, e.g. whether you'd want NATing for some reasons.
(Also, libvirt's default virtual network will create iptables rules automatically to "allow traffic to/from guests attached to the virbr0 device in the INPUT, FORWARD, OUTPUT and POSTROUTING chains")

That's why I wrote 'you may need' instead of 'you have to'

deHakkelaar · December 12, 2019, 4:28pm

No routing involved with bridging on the privileged domain.
The interfaces dont have an IP to route anyway (except for the bridge interface).

jbee · December 12, 2019, 4:30pm

Bucking_Horn: Right now none of the VMs are spun up until I can resolve this issue, so I don't think iptables, or NATing are causing any issues as of yet. The brctl show command only lists the interfaces I have in /etc/network/interfaces as libvrt hasn't started any of the virtual interfaces yet. The set up is just eth0 on a bridge virbr0. Virbr0 isn't virtual, maybe that was a bad choice in naming.

I'll check systemctl status pihole-FTW when I get to the box again upon a fresh reboot when I know pihole hasn't started. Are the other mechanisms for trying to figure out why pihole doesn't start on boot so I'm ready when I get on the box again?

deHakkelaar · December 12, 2019, 4:36pm

sudo systemctl status --full --no-pager pihole-FTL

And check ports used by Pi-hole if conflicting with other daemons:

pi@noads:~ $ sudo netstat -nltup | grep 'Proto\|:53 \|:67 \|:80 \|:471[1-8] '
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      30074/pihole-FTL
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      30074/pihole-FTL
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      602/lighttpd
tcp6       0      0 :::53                   :::*                    LISTEN      30074/pihole-FTL
tcp6       0      0 ::1:4711                :::*                    LISTEN      30074/pihole-FTL
tcp6       0      0 :::80                   :::*                    LISTEN      602/lighttpd
udp        0      0 0.0.0.0:53              0.0.0.0:*                           30074/pihole-FTL
udp        0      0 0.0.0.0:67              0.0.0.0:*                           30074/pihole-FTL
udp6       0      0 :::53                   :::*                                30074/pihole-FTL

jbee · December 13, 2019, 7:00am

Okay, so with the changes to the network/interfaces file, and reconfiguring pihole on virbr0, here are the outputs:

sudo netstat -nltup | grep 'Proto\|:53 \| :67 \|:80 \|:471[1-8]'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      1267/pihole-FTL
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1901/nginx -g daemo
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1267/pihole-FTL
tcp6       0      0 ::1:4711                :::*                    LISTEN      1267/pihole-FTL
tcp6       0      0 ::1:53                  :::*                    LISTEN      1267/pihole-FTL
udp        0      0 127.0.0.1:53            0.0.0.0:*                           1267/pihole-FTL
udp6       0      0 ::1:53                  :::*                                1267/pihole-FTL

user@server:~$ pihole status
  [✓] DNS service is running
  [✓] Pi-hole blocking is Enabled

So it should be running on 192.168.0.201 (as per the static IP). I have my router using 192.168.0.201 as the DNS it hands out to clients. This is the output from a Windows machine on the network:

C:\Users\user>nslookup google.com
DNS request timed out.
    timeout was 2 seconds.
Server:  UnKnown
Address:  192.168.0.201

DNS request timed out.
    timeout was 2 seconds.

I've kind of been down this road before, and had more luck with configuring pihole in eth0 instead of virbr0. But since I'm here asking for help, is there anywhere else I can look for clues as to what's going on?

(Also I discovered that I don't have dnsmasq installed. When I try installing it, I get the following error: dnsmasq: failed to create listening socket for 127.0.0.1: Address already in use, not sure if that helps at all)

deHakkelaar · December 13, 2019, 7:19am

You dont need dnsmasq anymore as its embedded into the pihole-FTL binary already.
Make sure its removed or disabled:

sudo systemctl disable dnsmasq

sudo systemctl stop dnsmasq

sudo systemctl restart pihole-FTL

Can you SSH into the IP from remote PC now ?
Whats output for below ones ?

sudo brctl show

ip l

ip a

ip r

If you compare my netstat with yours, you can see pihole-FTL is not listening to IPv4 ports 53 TCP or UDP for DNS.
Most of the times this is caused by rogue config file(s).
What config files do you have ?

sudo grep -v '^#\|^$' -R /etc/dnsmasq.* | sort

Below how mine looks like:

pi@noads:~ $ sudo grep -v '^#\|^$' -R /etc/dnsmasq.* | sort
/etc/dnsmasq.conf:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.conf.dpkg-old:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.conf.old:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/black.list
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/gravity.list
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/local.list
/etc/dnsmasq.d/01-pihole.conf:bogus-priv
/etc/dnsmasq.d/01-pihole.conf:cache-size=10000
/etc/dnsmasq.d/01-pihole.conf:dhcp-ignore-names=tag:wpad-ignore
/etc/dnsmasq.d/01-pihole.conf:dhcp-name-match=set:wpad-ignore,wpad
/etc/dnsmasq.d/01-pihole.conf:domain-needed
/etc/dnsmasq.d/01-pihole.conf:interface=eth0
/etc/dnsmasq.d/01-pihole.conf:localise-queries
/etc/dnsmasq.d/01-pihole.conf:local-ttl=2
/etc/dnsmasq.d/01-pihole.conf:log-async
/etc/dnsmasq.d/01-pihole.conf:log-facility=/var/log/pihole.log
/etc/dnsmasq.d/01-pihole.conf:log-queries
/etc/dnsmasq.d/01-pihole.conf:no-resolv
/etc/dnsmasq.d/01-pihole.conf:server=149.112.112.10
/etc/dnsmasq.d/01-pihole.conf:server=9.9.9.10

jbee · December 13, 2019, 7:51am

Before I post the outputs of the other commands, I believe you might be on to something in that there might be a rogue configuration in the dnsmasq configuration files.

user@server:~$ sudo grep -v '^#\|^$' -R /etc/dnsmasq.* | sort
/etc/dnsmasq.conf.dpkg-old:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.conf.old:conf-dir=/etc/dnsmasq.d
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/black.list
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/gravity.list
/etc/dnsmasq.d/01-pihole.conf:addn-hosts=/etc/pihole/local.list
/etc/dnsmasq.d/01-pihole.conf:cache-size=10000
/etc/dnsmasq.d/01-pihole.conf:interface=virbr0
/etc/dnsmasq.d/01-pihole.conf:localise-queries
/etc/dnsmasq.d/01-pihole.conf:local-ttl=2
/etc/dnsmasq.d/01-pihole.conf:log-async
/etc/dnsmasq.d/01-pihole.conf:log-facility=/var/log/pihole.log
/etc/dnsmasq.d/01-pihole.conf:log-queries
/etc/dnsmasq.d/01-pihole.conf:no-resolv
/etc/dnsmasq.d/01-pihole.conf:server=8.8.4.4
/etc/dnsmasq.d/01-pihole.conf:server=8.8.8.8
/etc/dnsmasq.d-available/libvirt-bin:bind-interfaces
/etc/dnsmasq.d/libvirt-bin:bind-interfaces
/etc/dnsmasq.d/network-manager:bind-interfaces

Anything look funky? I don't know enough about these configs, but I don't see any bind-interface configurations in your output.

Also, I apt-get remove dnsmaq --purge ed the dnsmasq utility, and yes I'm able to ssh into my box.

deHakkelaar · December 13, 2019, 8:08am

Get ride of above two files and move them to your home folder for backup:

sudo mv /etc/dnsmasq.d/libvirt-bin ~

sudo mv /etc/dnsmasq.d/network-manager ~

Restart to apply:

sudo service pihole-FTL restart

And check netstat again if listening now:

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

Is network-manager active ?

sudo service network-manager status

Thats another network manager that can mangle your IP setup!

EDIT:typo

jbee · December 13, 2019, 8:13am

It works!

For now I just commented out the bind-interfaces directives, and it works. As a bonus, I spun up the VMs, and it looks like they're doing fine as well. I wonder why libvirt added those directives? It looks like it works fine without them. Maybe I added them long ago and forgot?

Would you mind explaining in simple terms what the bind-interfaces directive does and why it broke pihole's DNS capabilities?

Also,

user@server~$ sudo netstat -nltup | grep 'Proto\|:53 \| :67 \|:80 \|:471[1-8]'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2099/nginx -g daemo
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1193/dnsmasq
tcp6       0      0 :::53                   :::*                    LISTEN      1193/dnsmasq
udp        0      0 0.0.0.0:53              0.0.0.0:*                           1193/dnsmasq
udp6       0      0 :::53                   :::*                                1193/dnsmasq

Lastly I thought network-manager is the utility that reads and applies your /etc/network/interfaces settings. Does pihole handle this natively as well?

user@server:~$ sudo service network-manager status
● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-12-12 23:59:44 PST; 9min ago
     Docs: man:NetworkManager(8)
 Main PID: 1068 (NetworkManager)
    Tasks: 3
   Memory: 8.4M
      CPU: 158ms
   CGroup: /system.slice/NetworkManager.service
           └─1068 /usr/sbin/NetworkManager --no-daemon

On the Windows machine on the network:

C:\Users\user>nslookup google.com
Server:  server
Address:  192.168.0.201

Non-authoritative answer:
Name:    google.com
Addresses:  2607:f8b0:4007:803::200e
          216.58.217.206

deHakkelaar · December 13, 2019, 8:26am

Shame you uninstalled dnsmasq again as the man pages can be useful:

pi@noads:~ $ man dnsmasq
[..]
       -z, --bind-interfaces
              On  systems  which  support it, dnsmasq binds the wildcard
              address, even when it is listening  on  only  some  inter‐
              faces.  It  then discards requests that it shouldn't reply
              to. This has the advantage of working even when interfaces
              come and go and change address. This option forces dnsmasq
              to really bind only the interfaces  it  is  listening  on.
              About  the  only  time when this is useful is when running
              another nameserver (or another instance of dnsmasq) on the
              same  machine.  Setting  this option also enables multiple
              instances of dnsmasq which provide DHCP service to run  in
              the same machine.

Its most of the times used to assure the daemon is only listening on one or more specific IP's.
Right now, your setup is listening on all IP's 0.0.0.0.

jbee:

Also,

user@server~$ sudo netstat -nltup | grep 'Proto\|:53 \| :67 \|:80 \|:471[1-8]'
Proto Recv-Q Send-Q Local Address           Foreign Address         State       PID/Program name
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      2099/nginx -g daemo
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1193/dnsmasq
tcp6       0      0 :::53                   :::*                    LISTEN      1193/dnsmasq
udp        0      0 0.0.0.0:53              0.0.0.0:*                           1193/dnsmasq
udp6       0      0 :::53                   :::*                                1193/dnsmasq

Is that a current netstat output ?
dnsmasq shouldn't be active like explained before.

I believe ifupdown does that:

pi@noads:~ $ apt policy ifupdown
ifupdown:
  Installed: 0.8.19
[..]

pi@noads:~ $ apt show ifupdown
[..]
Description: high level tools to configure network interfaces
 This package provides the tools ifup and ifdown which may be used to
 configure (or, respectively, deconfigure) network interfaces based on
 interface definitions in the file /etc/network/interfaces.