Creating the Network Bridge

The first step is to set up a network bridge on the LAN adapter of the Linux server that will run the Pi-hole container later. Usually this bridge will be br0. It also hosts the static IP address of the physical application server. If you want to bridge the primary LAN adapter of a server, you will usually have to do so while the network is running. Of course, this can go wrong and simply disconnect the server from the LAN. But a small script and the Linux NetworkManager make sure that this task runs smoothly. You can even bridge the LAN configuration of a remote cloud server while you are connected to it via SSH.

During system installation, NetworkManager usually creates a logical network with the name of the underlying physical adapter or a label such as Wired 1. After NetworkManager has done so, transfer the UUID displayed by entering the nmcli connection show command to the Bash bridge-lan.sh script shown in Listing 1 along with the static IP address of the bridge and the other LAN parameters. In my example, the IP addresses are 192.168.2.12 for the application server and 192.168.12.1 for the router. For the DNS address, enter the server itself, because this is currently the only DNS still active.

#!/bin/bash
nmcli conn delete <UUID of network interface card>
nmcli conn add type bridge con-name br0 ifname br0
nmcli conn modify br0 ipv4.addresses '192.168.2.12/24'
nmcli conn modify br0 ipv4.gateway '192.168.2.1'
nmcli conn modify br0 ipv4.dns '192.168.2.12'
nmcli conn modify br0 ipv4.method manual
nmcli conn add type ethernet slave-type bridge \
 ** ** ** ** ** con-name bridge-br0 \
 ** ** ** ** ** ifname enp1s0 master br0
nmcli conn up br0

Make the script executable and run it. It first deletes the old connection, configures the bridge, and finally, puts it into operation. After a few seconds, you can access the server via the bridge. The next step is to add a container network that Podman can use for the Pi-hole container and others later on.

Podman manages its networks in the /etc/cni/net.d/ directory. To create a bridge network for the br0 bridge, you first need to generate a suitable conflist file – see pub_net.conflist in Listing 2. You can now launch containers with their own IP addresses on the pub_net network.

{"cniVersion": "0.4.0", "name": "pub_net", "plugins": type: "bridge", "bridge": "br0", "ipam": { "type": "host-local", "ranges": [[ { "subnet": "192.168.2.0/24", "gateway": "192.168.2.1 }]],
"routes": [{"dst": "0.0.0.0/0"} ]}},{"type": "tuning", "capabilities": {"mac": true }}]}
{"type": "tuning", "capabilities": {"mac": true }}]}
"routes": [{"dst": "0.0.0.0/0"} ]}}, {"type": "tuning", "capabilities": {"mac": true }}]}

Configuring Filter Lists

Armed with the appropriate bridge and a Podman network for it, you now define the Pi-hole container as a systemd service to let it start up automatically when the application server is restarted (see Listing 3). In my sample setup, the Pi-hole container is given an IP address of 192.168.2.2 and a matching MAC address, which is composed of the vendor string 52:54 – typical of KVM virtual machines (VMs) – and an IP address in hexadecimal format, C0:A8:02:02.

"/etc/systemd/system/pihole.service":
[Unit]
 ** ** ** ** ** Description=pihole
 ** ** ** ** ** After=network-online.target
 ** ** ** ** ** Wants=network-online.target
[Service]
ExecStartPre=/bin/podman kill pihole
 ** ** ** ** ** ExecStartPre=-/bin/podman rm pihole
 ** ** ** ** ** ExecStartPre=-/bin/podman pull
 ** ** ** ** ** docker.io/pihole/pihole:latest
 ** ** ** ** ** ExecStart=/bin/podman run \ g
 ** ** ** ** ** ** ** ** ** ** --name pihole \
 ** ** ** ** ** ** ** ** ** ** --volume /var/pods/pihole/etc:/etc/pihole:Z
 ** ** ** ** ** ** ** ** ** ** --volume
 ** ** ** ** **  ** ** ** ** ** --volume
 ** ** ** ** ** /var/pods/pihole/dnsmasq:/etc/dnsmasq.d:Z \
 ** ** ** ** **  ** ** ** ** ** --net --ip 192.168.2.2 \
 ** ** ** ** **  ** ** ** ** ** --mac-address 52:54:C0:A8:02:02 \
 ** ** ** ** **  ** ** ** ** ** docker.io/pihole/pihole:latest
 ** ** ** ** ** ExecStop=/bin/podman stop pihole
[Install]
 ** ** ** ** ** WantedBy=multi-user.target

Last but not least, let's create two directories, etc and dnsmasq, below /var/pods/pihole, where Pi-hole will immediately store the configuration files. Now use systemd to start the container by typing systemctl start pihole. The first call initially creates the required configuration files and directory structures before the Pi-hole DNS starts its work. To be able to manage the Pi-hole service via web UI, you first need to define an admin password. To do this, log into the running container on the Podman host:

podman exec -it pihole /bin/bash

At the following prompt, type the admin command pihole -a -p to set a new admin password. Then start the web interface in your client's browser, in my case on http://192.168.2.2, and log in with the previously assigned password. Go to the Settings menu and then to the DNS tab when you get there. In the basic configuration, Pi-hole uses Google as its upstream DNS server. Switch off the Google server in the upstream list and enter the internal DNS server in the dialog on the right, in my example, 192.168.2.12#53. Now Pi-hole can resolve both internal and external names. When everything is running, enable autostart for the Pi-hole service by typing systemctl enable pihole.

You can see which domains Pi-hole filters in the Adlist tab. A default list of about 160,000 domains is defined here. More filter lists can be found on GitHub [2]; the YouTube_ads_pi-hole list is highly recommended. You can simply add lists via their URLs. Pi-hole automatically updates them once a week. If you want to initiate a manual update, you will find the Update Gravity option in the Tools menu.

In the Domains tab, you can then add your own individual entries or regex selections to the white- or blacklist. For example, the basic filter isolates Amazon devices on your LAN from their metrics collectors (device-metrics-us-2.amazon.com). This affects the function of Alexa and company and can slow down the response of these devices. If you do not want this, you need to explicitly allow the domain.

As a Podman container, Pi-hole can basically run on any machine and in any VM that has a hybridized LAN adapter. With the MAC and IP address defined in the systemd unit, the container always starts up with the same network parameters, regardless of the host system. During operation, Pi-hole makes virtually no changes to the underlying filesystem. This is why you can use built-in tools to copy the two directories of the Pi-hole setup to a backup drive or a second host regularly and in a relatively simple way, with rsync, for example. It is also possible to store the Pi-hole data in an NFS share so multiple hosts can access the information.

Customize DNS and DHCP Service

For Pi-hole to cooperate with the existing DNS/DHCP configuration, some changes to the existing settings are required. First you need to change DHCP option 6 (DNS server) of your DHCP service to the Pi-hole server. With dnsmasq, the option then looks like this:

dhcp-option=6,192.168.2.2

Similarly, dnsmasq can use other DNS servers than the host it is running on as forwarders. You need to list all the required DNS servers in an /etc/nameservers.conf file as follows:

nameserver 9.9.9.9
nameserver 1.1.1.1
nameserver 149.112.112.112
nameserver 1.0.0.1

Then specify this list in your dnsmasq.conf file:

resolv-file=/etc/nameservers.conf

Now the underlying host itself could also use the Pi-hole server for name resolution, but a secondary DNS is absolutely essential. When you restart the Pi-hole container, the host must be able to resolve the Docker registry URL to do this. The host must not rely solely on the Pi-hole server.