Skip to main content

Network and Address Reference

Purpose

This page documents the addressing, DNS, routing, and network-access model used by the Bytek homelab.

Use this page when:

  • Creating a new VM or LXC.
  • Adding a Pi-hole reservation.
  • Creating a Traefik route.
  • Troubleshooting an unreachable service.
  • Adding a new public hostname.
  • Configuring a firewall rule.
  • Diagnosing split-DNS or browser secure-DNS issues.

Home Network

Setting Value
LAN subnet 192.168.2.0/24
Default gateway 192.168.2.1
LAN DNS server 192.168.2.65
Router Bell Giga Hub 2.0
Public domain bytek.ca
Public DNS provider WHC cPanel
Public VPS address 38.29.213.101
Internal HTTPS proxy 192.168.2.182

Service Address Inventory

Service Private Address Primary Ports Access Scope
WireGuard gateway 192.168.2.64 Existing WireGuard port and SSH Infrastructure
Pi-hole 192.168.2.65 TCP and UDP 53 LAN
Nextcloud AIO 192.168.2.100 TCP 8080 and TCP 11000 LAN management and Traefik backend
Uptime Kuma 192.168.2.115 TCP 3001 Authentik proxy and monitoring
Vikunja 192.168.2.121 TCP 3456 Traefik backend
Authentik 192.168.2.162 TCP 9000 Traefik and internal services
Traefik 192.168.2.182 TCP 443 LAN and public ingress
Proxmox VE 192.168.2.254 TCP 8006 and TCP 22 LAN or trusted VPN
BookStack Confirm current IP TCP 6875 Traefik backend

Public Hostname Inventory

Service Public Hostname Public DNS Destination
Nextcloud cloud.bytek.ca 38.29.213.101
BookStack docs.bytek.ca 38.29.213.101
Authentik portal.bytek.ca 38.29.213.101
Vikunja projects.bytek.ca 38.29.213.101
Traefik dashboard proxy.bytek.ca 38.29.213.101
Uptime Kuma status.bytek.ca 38.29.213.101

The public application records are managed through the WHC cPanel Zone Editor.

The public DNS destination is the VPS, not the private application address.

Private Hostname Inventory

Service Private Hostname Pi-hole Destination
Nextcloud cloud.bytek.ca 192.168.2.182
BookStack docs.bytek.ca 192.168.2.182
Authentik portal.bytek.ca 192.168.2.182
Vikunja projects.bytek.ca 192.168.2.182
Traefik dashboard proxy.bytek.ca 192.168.2.182
Uptime Kuma status.bytek.ca 192.168.2.182
Proxmox VE pve.bytek.ca 192.168.2.254

All HTTPS application hostnames point internally to Traefik.

Proxmox is the exception because Proxmox does not sit behind Traefik.

Public DNS Flow

When an external client opens a hosted application:

  1. The client requests an application hostname such as docs.bytek.ca.
  2. Public DNS at WHC returns 38.29.213.101.
  3. The client connects to the VPS.
  4. The VPS forwards permitted traffic through WireGuard.
  5. The home WireGuard gateway forwards the request to Traefik.
  6. Traefik routes the request to the matching internal service.

Public DNS must never point directly to a private address such as 192.168.2.121.

Private RFC1918 addresses are not reachable from the public internet.

Internal Split-DNS Flow

When a client on the home LAN opens a hosted application:

  1. The client queries Pi-hole at 192.168.2.65.
  2. Pi-hole returns Traefik’s address, 192.168.2.182.
  3. The client connects directly to Traefik.
  4. Traefik routes the request to the matching backend.

This allows internal clients to use the same application hostnames and HTTPS certificates as external clients.

Benefits include:

  • No unnecessary trip through the VPS.
  • Lower latency.
  • No dependency on hairpin NAT.
  • Consistent HTTPS URLs.
  • Consistent Authentik callback addresses.
  • Simpler application configuration.

Public and Private DNS Comparison

Hostname Public Result Internal Pi-hole Result
cloud.bytek.ca 38.29.213.101 192.168.2.182
docs.bytek.ca 38.29.213.101 192.168.2.182
portal.bytek.ca 38.29.213.101 192.168.2.182
projects.bytek.ca 38.29.213.101 192.168.2.182
proxy.bytek.ca 38.29.213.101 192.168.2.182
status.bytek.ca 38.29.213.101 192.168.2.182
pve.bytek.ca No public record 192.168.2.254

Proxmox DNS Design

The Proxmox host intentionally uses Quad9:

  • DNS server: 9.9.9.9

Proxmox does not use Pi-hole as its general resolver.

This design prevents the hypervisor from depending on a guest VM or LXC for DNS.

As a result, the Proxmox host normally resolves:

  • portal.bytek.ca to 38.29.213.101

The Proxmox OIDC server-to-server path can therefore travel through:

  1. Proxmox.
  2. Public VPS.
  3. WireGuard.
  4. Traefik.
  5. Authentik.

If this public path causes a future OIDC reliability issue, a single entry may be added to the Proxmox /etc/hosts file:

  • portal.bytek.ca to 192.168.2.182

This would route only Authentik directly through local Traefik while keeping general Proxmox DNS on Quad9.

Proxmox Private Hostname

The hostname pve.bytek.ca is intentionally private.

Pi-hole resolves it to:

  • 192.168.2.254

No public WHC record should exist for pve.bytek.ca.

The Proxmox interface is accessed at:

Open Proxmox VE

Access should be limited to:

  • The home LAN.
  • A future trusted VPN.
  • An emergency SSH tunnel through the VPS if intentionally configured.

TCP port 8006 must not be exposed directly to the public internet.

Application Backend Reference

Traefik connects to each application using a private IP and backend port.

Hostname Backend Destination
cloud.bytek.ca 192.168.2.100:11000
docs.bytek.ca BookStack private IP on TCP 6875
portal.bytek.ca 192.168.2.162:9000
projects.bytek.ca 192.168.2.121:3456
status.bytek.ca Uptime Kuma or Authentik outpost
proxy.bytek.ca Traefik internal dashboard service

Backend ports should be accessible only from the systems that require them.

For example:

  • Vikunja TCP 3456 should be available to Traefik and Uptime Kuma.
  • BookStack TCP 6875 should be available to Traefik and Uptime Kuma.
  • Nextcloud TCP 11000 should be available to Traefik.
  • Authentik TCP 9000 should be available to Traefik and approved internal services.
  • Uptime Kuma TCP 3001 should eventually be limited to the Authentik outpost.

DHCP Reservations

Infrastructure services should use DHCP reservations based on their virtual NIC MAC addresses.

Known reservations include:

Service Reserved Address
Nextcloud 192.168.2.100
Uptime Kuma 192.168.2.115
Vikunja 192.168.2.121

Additional infrastructure reservations should be confirmed in Pi-hole before being added to this page.

To locate a VM MAC address on Proxmox, use:

qm config <VMID>

Locate the net0 line and record the MAC address.

For an LXC, use:

pct config <CTID>

Reservations prevent unexpected address changes from breaking:

  • Traefik routes.
  • Firewall rules.
  • Uptime Kuma monitors.
  • Authentik providers.
  • Pi-hole records.
  • Administrative bookmarks.
  • Documentation.

Firewall Source Reference

Known infrastructure sources include:

Source Address
WireGuard gateway 192.168.2.64
Pi-hole 192.168.2.65
Uptime Kuma 192.168.2.115
Authentik 192.168.2.162
Traefik 192.168.2.182
Proxmox 192.168.2.254

Typical firewall requirements include:

  • Traefik to application backend ports.
  • Uptime Kuma to direct health endpoints.
  • Authentik outpost to Uptime Kuma.
  • LAN administrator devices to SSH.
  • Pi-hole DNS from approved LAN clients.
  • WireGuard gateway to Traefik.
  • Proxmox management access from the LAN or VPN.

Avoid broad any-source rules when a specific infrastructure source can be used.

Browser Secure-DNS Warning

Firefox and Zen can use DNS over HTTPS and bypass Pi-hole.

This can cause private hostnames such as pve.bytek.ca to fail even when Pi-hole is configured correctly.

Recommended browser setting:

  • DNS over HTTPS: Off or Default Protection

If an internal hostname fails only in the browser:

  1. Confirm the hostname resolves from the operating system.
  2. Query Pi-hole directly.
  3. Disable forced DNS over HTTPS.
  4. Clear the operating-system DNS cache.
  5. Clear the browser DNS cache.
  6. Close idle browser sockets.
  7. Completely restart the browser.

Useful Windows commands:

  • Resolve-DnsName pve.bytek.ca
  • nslookup pve.bytek.ca 192.168.2.65
  • Test-NetConnection pve.bytek.ca -Port 8006
  • Clear-DnsClientCache
  • ipconfig /flushdns

Expected result:

  • pve.bytek.ca resolves to 192.168.2.254.
  • TCP port 8006 succeeds.

DNS Validation

Verify an Internal Record

Use:

nslookup portal.bytek.ca 192.168.2.65

Expected result:

  • portal.bytek.ca resolves to 192.168.2.182.

Verify a Public Record Through Pi-hole

Use:

nslookup google.com 192.168.2.65

Expected result:

  • One or more public addresses are returned.

Verify Public WHC DNS

Query an authoritative WHC server and confirm that application hostnames resolve to:

  • 38.29.213.101

Verify a Backend Port

Examples:

  • nc -zv -w 5 192.168.2.121 3456
  • nc -zv -w 5 192.168.2.162 9000
  • nc -zv -w 5 192.168.2.254 8006

A successful connection confirms TCP reachability but does not prove the application is healthy.

Network Troubleshooting Order

When a hostname is unreachable, troubleshoot in this order:

  1. Confirm the destination VM or LXC is running.
  2. Confirm the destination still owns the documented IP.
  3. Confirm the hostname resolves to the expected address.
  4. Confirm the required TCP or UDP port is reachable.
  5. Test the application directly by private IP.
  6. Test the application through Traefik locally.
  7. Test the application through the public VPS path.
  8. Check browser secure-DNS settings.
  9. Review Proxmox and guest firewall rules.
  10. Review application and Traefik logs.

Do not change DNS, firewalling, and application configuration simultaneously.

Address-Change Procedure

If a service IP changes:

  1. Create or update the Pi-hole DHCP reservation.
  2. Renew the guest lease or restart the guest.
  3. Confirm the guest owns the new address.
  4. Update the Traefik backend.
  5. Update Proxmox firewall source or destination rules.
  6. Update Uptime Kuma monitors.
  7. Update Authentik Proxy Provider internal hosts if applicable.
  8. Update documentation.
  9. Search service configuration for the old address.
  10. Test internal and external access.

A stale backend IP previously affected several deployment steps, so the old address should be searched across configuration files after every change.

Document Control

  • Owner: Bryan Gagne-Plante
  • Last verified: YYYY-MM-DD
  • Public DNS provider: WHC cPanel
  • Internal DNS provider: Pi-hole
  • LAN subnet: 192.168.2.0/24
  • Known limitation: Browser DNS over HTTPS can bypass Pi-hole
  • Items to confirm: BookStack private IP and remaining DHCP reservations

No comments to display

Back to top