Post

Proxmox & Pi-hole: V2 Core Infrastructure

Reinstalling Proxmox VE and Pi-hole, and adapting both to fit within the new network architecture.

Proxmox & Pi-hole: V2 Core Infrastructure

Overview

With the network segmented into three VLANs, the next phase was standing up core infrastructure on pavilion. V1’s Proxmox installation was wiped entirely, it had no VLAN awareness, leftover configurations, and no clean foundation for V2. This post covers the fresh Proxmox deployment, essential post-install steps, and a new Pi-hole configuration.


Proxmox VE — 2nd Time

Why a Full Reinstall

The V1 Proxmox instance ran on a flat network with no VLAN configuration. While migrating an existing node to a segmented network is technically possible, a clean reinstall configured correctly from the start felt like the correct option, and eliminated any legacy configuration that may cause issues down the line.

Installation

Proxmox VE was installed from the official ISO with the management IP set statically on VLAN 20 during installation. The FQDN was set to pavilion.lan to match the OpenWRT domain configuration.

The resulting bridge configuration in /etc/network/interfaces:

1
2
3
4
5
6
7
auto vmbr0
iface vmbr0 inet static
    address  192.168.20.XX/24
    gateway  192.168.20.1
    bridge-ports enp3s0
    bridge-stp off
    bridge-fd 0

All VMs and containers attach to vmbr0, which bridges to the physical ethernet interface. From the network’s perspective, each workload appears as its own device on VLAN 20.

Post-Install

Disabling the Enterprise Repository

Proxmox ships with the enterprise repository enabled by default, requiring a paid subscription. Without a subscription key, apt update fails with authentication errors.

1
2
3
4
5
6
7
8
# Disable the enterprise repo
echo "# disabled" > /etc/apt/sources.list.d/pve-enterprise.list

# Enable the community (no-subscription) repo
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" \
  > /etc/apt/sources.list.d/pve-no-subscription.list

apt update && apt dist-upgrade -y

The community repository is fully functional for homelab use. The enterprise repo is for organizations requiring long-term support contracts.

Removing the Subscription Nag

The Proxmox web UI displays a subscription dialog on every login when no license is active:

1
2
3
sed -i "s/data.status !== 'Active'/false/" \
  /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js
systemctl restart pveproxy

Running this command in the shell should remove this nagging notification.

Pi-hole - 2nd Time

Container Deployment

SettingValue
CT ID100
Base ImageUbuntu 22.04 (LXC template)
VLAN20 — Lab
CPU1 core
RAM512 MB
Disk8 GB
NestingEnabled (required)

LXC nesting must be enabled, Pi-hole’s FTL process will not run correctly inside a container without it.

Installation was different this time around. I used a community resource, Proxmox VE Scripts, which provide helper script to install various services. There was an install script for Pi-hole and I decided to use it.

BE CAREFUL when running scripts from the internet. VERIFY the SCRIPT and SOURCE. For More Details

1
bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/pihole.sh)"

Choose the Advanced Install option, most of my choices were similar to the first install. Except those relating to my new network architecture.

Solving Cross-VLAN DNS

This is where V2 introduced a problem V1 never had. Pi-hole defaults its listening mode to LOCAL, accepting DNS queries only from its own subnet (VLAN 20). Trusted devices on VLAN 10 were rejected with:

1
ignoring query from non-local network

The fix: In the Pi-hole admin UI → Settings > DNS > Interface settings → set listening mode to Permit all origins.

Alternatively, in /etc/pihole/pihole.toml:

1
listeningMode = "all"

This is safe in this deployment because Pi-hole is on a firewalled internal network and port 53 is not exposed externally. The firewall ensures only trusted internal traffic reaches it.

Local DNS Records

Pi-hole serves local DNS records for all lab services, mapping each subdomain to the Nginx Proxy Manager IP. NPM then routes requests to the correct backend based on hostname. (See NGINX post for more details)

HostnameResolves ToService
proxmox.jamcre.devNPM IPProxmox web UI
pihole.jamcre.devNPM IPPi-hole admin
nginx.jamcre.devNPM IPNPM admin panel
wazuh.jamcre.devNPM IPWazuh dashboard

All four records resolve to the same IP, the hostname in the request is what NPM uses to route to the correct backend service.

Local DNS records Local DNS records mapping all lab subdomains to NPM


What’s Next

Pavilion is running Proxmox with Pi-hole handling DNS for the VLANs. The naming infrastructure is in place, every service deployed from here will be accessible at a clean hostname rather than an IP and port combination.

Next: Nginx Proxy Manager, the wildcard SSL certificate, and routing all those hostnames to their backend services over HTTPS.

This post is licensed under CC BY 4.0 by the author.