Can't get pihole to work on br0 interface

[jbee]

Uhg, you're right. I was so excited about DNS working, I didn't thoroughly look at the output of netstat. I must have uninstalled dnsmasq, and either stupidly reinstalled it, or does pihole install it during a reconfiguration when running pihole -r?

Here's the update output with dnsmasq actually removed:

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      1913/nginx -g daemo
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1634/pihole-FTL
tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      1634/pihole-FTL
tcp6       0      0 :::53                   :::*                    LISTEN      1634/pihole-FTL
tcp6       0      0 ::1:4711                :::*                    LISTEN      1634/pihole-FTL
udp        0      0 0.0.0.0:53              0.0.0.0:*                           1634/pihole-FTL
udp6       0      0 :::53                   :::*                                1634/pihole-FTL

And the config files:

/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

However, after uninstalling dnsmasq, and even though pihole is running,

● pihole-FTL.service - LSB: pihole-FTL daemon
   Loaded: loaded (/etc/init.d/pihole-FTL; bad; vendor preset: enabled)
   Active: active (exited) since Fri 2019-12-13 00:30:18 PST; 5min ago
     Docs: man:systemd-sysv-generator(8)
  Process: 900 ExecStart=/etc/init.d/pihole-FTL start (code=exited, status=0/SUCCESS)
    Tasks: 0
   Memory: 0B
      CPU: 0

Dec 13 00:29:56 server systemd[1]: Starting LSB: pihole-FTL daemon...
Dec 13 00:29:58 server pihole-FTL[900]: Not running
Dec 13 00:30:17 server su[1268]: Successful su for pihole by root
Dec 13 00:30:17 server su[1268]: + ??? root:pihole
Dec 13 00:30:17 server su[1268]: pam_unix(su:session): session opened for user pihole by (uid=0)
Dec 13 00:30:18 server pihole-FTL[900]: FTL started!
Dec 13 00:30:18 server systemd[1]: Started LSB: pihole-FTL daemon.

The Windows machine reports:

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

*** UnKnown can't find google.com: Query refused

I was so close

[deHakkelaar]

@jbee

I must have uninstalled dnsmasq, and either stupidly reinstalled it, or does pihole install it during a reconfiguration when running pihole -r ?

No.
In the past, Pi-hole depended on the dnsmasq binary.
Now its embedded in the pihole-FTL binary so dont need it anymore.

@jbee

The Windows machine reports:

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

*** UnKnown can't find google.com: Query refused

And if you query for a domain that Pi-hole knows about and wont need to be forwarded to upstream configured Google DNS 8.8.8.8/8.8.4.4 ?

nslookup pi.hole

EDIT: I forgot, you can live tail the logs at same time:

pihole -t

EDIT2: and to make thngs easier, you can also use below to query (without the win PC depending on DHCP DNS):

nslookup pi.hole 192.168.0.201

[jbee]

Actually I executed a pihole -r and reconfigured pihole after removing the dnsmasq utility, set it back on virbr0, rebooted and it, again works. Perhaps I could have gotten away with a pihole restartdns. In anycase, it works for real this time:

tcp        0      0 127.0.0.1:4711          0.0.0.0:*               LISTEN      1257/pihole-FTL
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      1914/nginx -g daemo
tcp        0      0 0.0.0.0:53              0.0.0.0:*               LISTEN      1257/pihole-FTL
tcp6       0      0 ::1:4711                :::*                    LISTEN      1257/pihole-FTL
tcp6       0      0 :::53                   :::*                    LISTEN      1257/pihole-FTL
udp        0      0 0.0.0.0:53              0.0.0.0:*                           1257/pihole-FTL
udp6       0      0 :::53                   :::*                                1257/pihole-FTL

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
          172.217.14.78

Final pihole -d output.

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

Looks good to me. Does everything look correct? FWIW, again the VMs are working fine, I don't see any issues.

[deHakkelaar]

Looks good.
Could check that last one on the Windows client:

nslookup pi.hole

Or see if a blocked domain gets redirected to 0.0.0.0:

nslookup doubleclick.com

And check stats:

nc localhost 4711 <<< $'>stats'

[jbee]

C:\Users\user>nslookup pi.hole
Server:  server
Address:  192.168.0.201

Name:    pi.hole
Addresses:  2606:6000:cd41:5d00:d63d:7eff:fe9e:9de2
          192.168.0.201

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

Name:    doubleclick.com
Addresses:  ::
          0.0.0.0

user@server:~$ nc localhost 4711 <<< $'>stats'
domains_being_blocked 113706
dns_queries_today 30310
ads_blocked_today 1099
ads_percentage_today 3.625866
unique_domains 770
queries_forwarded 6227
queries_cached 10816
clients_ever_seen 12
unique_clients 11
dns_queries_all_types 30310
reply_NODATA 133
reply_NXDOMAIN 92
reply_CNAME 49
reply_IP 225
privacy_level 0
status enabled
---EOM---

[deHakkelaar]

@jbee

C:\Users\user>nslookup pi.hole
Server: server
Address: 192.168.0.201

Name: pi.hole
Addresses: 2606:6000:cd41:5d00:d63d:7eff:fe9e:9de2
 192.168.0.201

It might be that network-manager aquired IPv6 2606:6000:cd41:5d00:d63d:7eff:fe9e:9de2 for the bridge interface:

ip a

I would make sure network-manager isn't involved anymore:

sudo systemctl disable network-manager

sudo reboot

And check again:

ip a

host pi.hole localhost

[jbee]

● NetworkManager.service - Network Manager
   Loaded: loaded (/lib/systemd/system/NetworkManager.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:NetworkManager(8)

Dec 13 01:12:38 server systemd[1]: Network Manager is not active.

ip a:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master virbr0 state UP group default qlen 1000
    link/ether d4:3d:7e:9e:9d:e2 brd ff:ff:ff:ff:ff:ff
3: virbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether d4:3d:7e:9e:9d:e2 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.201/24 brd 192.168.0.255 scope global virbr0
       valid_lft forever preferred_lft forever
    inet6 2606:6000:cd41:5d00:dce4:8334:67c8:ca4/64 scope global temporary dynamic
       valid_lft 604649sec preferred_lft 85649sec
    inet6 2606:6000:cd41:5d00:d63d:7eff:fe9e:9de2/64 scope global mngtmpaddr dynamic
       valid_lft 604797sec preferred_lft 604797sec
    inet6 fe80::d63d:7eff:fe9e:9de2/64 scope link
       valid_lft forever preferred_lft forever

host pi.hole localhost:

Using domain server:
Name: localhost
Address: 127.0.0.1#53
Aliases:

pi.hole has address 192.168.0.201
pi.hole has IPv6 address 2606:6000:cd41:5d00:d63d:7eff:fe9e:9de2

I'm not sure what this means. What is it supposed to be?

[deHakkelaar]

@jbee

I’m not sure what this means. What is it supposed to be?

host is another lookup tool same as nslookup.
Am wondering where those IPv6 addresses are coming from.
Am not that proficient with IPv6.
And got to leave now so maybe at later time look into it or someone else can enlighten ?

[jbee]

I'm not that proficient at IPv6 either.

Thank you for your help, the support has been well above-and-beyond. As far as I can tell, things are working. I'll look into this further when I get a chance, but this has been a huge roadblock for me in configuring the rest of my network. I donated what I could, although the support has been worth much more than that.

If others stumble upon this thread, there has been a lot of back-and-forth in regards to configuration, but I think the main offender for DNS not working was rogue dnsmasq configurations.

Thank you again.

[Bucking_Horn]

@jbee

I wonder why libvirt added those directives? It looks like it works fine without them.
Maybe I added them long ago and forgot?

No, libvirt added these configuration options, just as I have suspected libvirt and `bind-interfaces` in my original answer (click for more)

@Bucking_Horn

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.

While your removal of two configuration files (libvirt-bin and network-manager) allowed Pi-hole to work again (as it is bound to all interfaces now), I am not entirely convinced that this won't interfere with libvirts designated use of dnsmasq.

---

Keep an eye on this, as libvirt could re-enable these configuration options on consecutive runs.

With regards to your IPv6 address:

NetworkManager would not touch any interfaces declared in /etc/network/interfaces by default, and you've disabled/uninstalled it anyhow.

Some musings on NetworkManager (click for details)

@jbee

Lastly I thought network-manager is the utility that reads and applies your /etc/network/interfaces settings.

NetworkManager tries to simplify your network setup by aggregating configuration options (including dnsmasq, iptables, sysctl) for each network it detects into separate profiles.
By default, NetworkManager does not handle any interface declared in /etc/network/interfaces.

Also by default, NetworkManager is configuring its own dnsmasq instance via /etc/NetworkManager/dnsmasq.d/, which might well result in conflicts with Pi-hole.

Uninstalling it is a good idea, but if you are dependent on NetworkManager (e.g. because your favourite VPN tool requires it), you could try to disable it by commenting the corresponding line in /etc/NetworkManager/NetworkManager.conf like this:

# dns=dnsmasq

---

So that means IPv6 auto configuration has taken over, which means your system works as expected (if not quite as intended by you )

Auto configuration is a core feature of IPv6, so not at all a bad thing (though it is bound to create some head-aches with regards to enforcing Pi-hole as DNS, but that's an entirely different topic).

However, you should use a ULA prefix address (e.g. fd00::) for your Pi-hole, not a global one (like 2606:: - click for more)

Your address starts with 2606:, and that means it is using a globally visible (which is not the same as accessible) address prefix, likely supplied by your ISP.

It would be better if you'd use a ULA prefix (fd00:by default) as supplied by your router - read Use IPv6 ULA addresses for Pi-hole for details. You'd have to consult your router's documentation on how you do this for your network.

---

If you do not need IPv6, you could also disable IPv6 altogether in your router (if your router allows this), sparing you many of the afore-mentioned head-aches.

If you decide to disable IPv6 on just your Linux machine instead, you can do so (click)

The following lines will disable IPv6 for your entire machine.
Edit /etc/sysctl.conf:

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1

If you'd prefer to disable IPv6 for just one interface, just use

net.ipv6.conf.eth0.disable_ipv6 = 1

Replace eth0 above with another interface name as needed.

Be aware that other programs (like libvirt and NetworkManager) also write to these files and might overwrite your settings if you use their configuration facilities.

---