Skip to content

Network Configuration

Network Topology

flowchart LR
    subgraph External
        Internet((Internet))
        DNS[DNS<br/>*.mdhmedia.uk]
    end

    subgraph DMZ
        Caddy[Caddy<br/>Reverse Proxy]
        WG[WireGuard<br/>192.168.1.236]
    end

    subgraph Internal
        PVE1[Proxmox 1<br/>192.168.1.199]
        PVE2[Proxmox 2<br/>192.168.1.151]
        PVE3[Proxmox 3<br/>192.168.1.28]
        Holly[Unraid<br/>192.168.1.200]
        Docker1[Docker LXC CT 101<br/>192.168.1.241]
    end

    Internet --> DNS
    DNS --> Caddy
    Internet --> WG
    Caddy --> PVE1
    Caddy --> PVE2
    Caddy --> Holly
    Caddy --> Docker1
Host Uplink NIC Speed Notes
pve1 (.199) enx3c18a0d4eddd — USB3 RTL8153 1 Gb/s Sole uplink since 2026-07-28; onboard eno1 (10/100 RTL8106E, unplugged but working) split out of vmbr0
pve2 (.151) enp4s0f0 10 GbE
pve3 (.28) enp6s0 1 GbE Also the wake-on-LAN target NIC (r8169) — see Proxmox

pve1's 100 Mb mystery — solved 2026-07-28

pve1's USB NIC had been renegotiating at 100 Mb/s. The cause was a wedged USB negotiation, not a bad cable — an xHCI reset restored the full 1 Gb/s link. Boot remediation now guards against a recurrence: restart-usb.service → usbup.sh → /usr/local/sbin/nic-link-up.sh (NIC_EXPECTED_SPEED=1000, xHCI reset + force-gigabit retry). The onboard eno1 — an unplugged 10/100 RTL8106E, working but slow — was split out of vmbr0 the same day so it can never drag the bridge down to 100 Mb.

The link-guard tooling is version-controlled in the repo at proxmox/network/: nic-link-up.sh plus a templated nic-link-up@.service boot oneshot, enabled for pve2's enp4s0f0 (expected 10 GbE) and pve3's enp6s0 (expected 1 GbE); pve1 runs the script via its restart-usb.service chain above. A Prometheus alert, NetworkLinkDegraded, fires whenever a physical link drops to <=100 Mb (from the netclass collector's node_network_speed_bytes).

Reverse Proxy (Caddy)

Caddy runs as the main reverse proxy handling all external traffic for *.mdhmedia.uk.

Configuration Location

The Caddyfile is stored in this repository at edge/caddy/Caddyfile.

Features

  • Automatic HTTPS with Let's Encrypt
  • Log rotation (10MB, keep 5 files, 14 days)
  • TLS termination for all services

Subdomain Routing

Subdomain Internal Target Service
mdhmedia.uk 192.168.1.241:3080 Homepage (behind tinyauth SSO)
pve1.mdhmedia.uk 192.168.1.199:8006 Proxmox 1
pve2.mdhmedia.uk 192.168.1.151:8006 Proxmox 2
holly.mdhmedia.uk 192.168.1.200:80 Unraid
arcane.mdhmedia.uk 192.168.1.241:3552 Arcane

Consolidation — 2026-07-20

The Arcane manager (was CT 100, 192.168.1.243) and Homepage (was CT 113, 192.168.1.242) now both run on the Docker LXC CT 101 (192.168.1.241); the two old LXCs are retired (stopped, onboot=0, kept as rollbacks). Homepage sits on host port 3080 because kicad already owns 3000 on CT 101.

DNS

DNS is managed externally with wildcard records pointing to the Caddy host.

WAN Throughput

RESOLVED 2026-07-08 — router-side fix applied

After correcting the 100BASE-T link at the router↔ONT handoff, a single-stream download from pve1 measures ~689 Mbit/s (previously ~92). Multi-stream tests should get closer to line rate. The diagnosis below is kept for reference.

Internet capped at ~94 Mbit/s on a 1 Gbit line (2026-07-07)

The Speedtest Tracker (on Holly) reports ~94 Mbit/s down and up, despite a YouFibre 1000 (symmetric ~1 Gbit) plan. Diagnosed as a 100BASE-T (Fast Ethernet) link at the router ↔ ONT handoff — not the homelab.

Evidence. Fresh Cloudflare pulls from three independent hosts all cap at the same ~92 Mbit/s, and every in-path NIC negotiates gigabit or better:

Host Path NIC ethtool Speed Fresh pull
Holly (.200) virtio → vmbr1 (enp4s0f0) 10000 Mb/s 91.9 Mbit/s
pve2 (.151) eno1 (vmbr0) 1000 Mb/s 91.9 Mbit/s
pve1 (.199) USB NIC enx3c18a0d4eddd (USB3) 1000 Mb/s 91.8 Mbit/s

Three physically distinct gigabit/10-gig uplinks producing byte-identical ~92 Mbit/s means the bottleneck is a shared downstream 100 Mbit segment — the router's WAN port or the ONT↔router cable. The pve1 USB NIC (a common suspect) is exonerated: it's USB3-gigabit and isn't even in Holly's path. The pinned test server is also cleared (a direct Cloudflare pull matches).

Fix (at the router — nothing to change in the homelab):

  1. Check the router's WAN interface link speed — it should read 1000, not 100.
  2. Most likely a faulty/old ONT → router Ethernet cable (a single bad pair drops the link to 100 Mb/s) — reseat, then replace with known-good Cat5e/6.
  3. Or the router WAN/LAN port is forced/stuck at 100 Mb/s (or is a Fast-Ethernet-only port) — move to a gigabit port / clear any forced-speed setting.
  4. Re-run a speed test; expect ~900+ Mbit/s. All internal links are already gigabit+.

VPN (WireGuard)

WireGuard VPN server runs at 192.168.1.236 providing secure remote access to the homelab.

Access Points

Service URL Port Purpose
VPN Endpoint wg.mdhmedia.uk 51820/UDP WireGuard tunnel
Admin Dashboard wgadmin.mdhmedia.uk 10086 Peer management

Network Configuration

Setting Value
Server IP 192.168.1.236
VPN Subnet 10.8.0.0/24 (typical)
Listen Port 51820
Protocol UDP

Client Setup

Adding New Peers

Use the admin dashboard at wgadmin.mdhmedia.uk to:

  1. Create a new peer/client configuration
  2. Download the configuration file or scan QR code
  3. Import into WireGuard client on your device

Supported Clients

Platform Client
Windows WireGuard for Windows
macOS WireGuard for macOS
iOS WireGuard for iOS
Android WireGuard for Android
Linux apt install wireguard or equivalent

Split Tunnel vs Full Tunnel

Routing Options

  • Split Tunnel: Only homelab traffic (192.168.1.0/24) routes through VPN
  • Full Tunnel: All traffic routes through VPN (use AllowedIPs = 0.0.0.0/0)

Split tunnel is recommended for better performance when only accessing local services.

Firewall Rules

Ensure the following ports are forwarded to the WireGuard server:

Port Protocol Purpose
51820 UDP WireGuard tunnel

Troubleshooting

Connection Issues
  1. Verify UDP port 51820 is forwarded on your router
  2. Check that the endpoint hostname resolves correctly
  3. Ensure client private key matches server's peer public key
  4. Verify the AllowedIPs configuration on both ends
  5. Check firewall rules on the WireGuard container/host