Skip to main content

Networking and Ingress

Public ingress​

The webserver VM (10.0.0.14) is the only server reachable from the public internet. It terminates TLS for every *.abair.ie domain using a single wildcard Let's Encrypt certificate (issued via Certbot's Cloudflare DNS-01 challenge) and reverse-proxies to the correct backend VM over the private 10.0.0.0/24 network. Cloudflare sits in front of it for DNS and DDoS protection; nginx is configured to trust Cloudflare's real-IP headers so backend apps still see genuine client IPs.

Every site's nginx vhost is defined in networking/nginx-config/ in the automation repo — see Modifying Infrastructure for how to add one.

The Amergin vSwitch​

Amergin, the GPU server, isn't a Proxmox VM and doesn't sit on 10.0.0.0/24 directly. It connects to the fleet over a dedicated Hetzner vSwitch (VLAN 4000), configured as a routed (not bridged) transit network on 192.168.100.0/24:

  • Amergin: 192.168.100.2/24, with a static route sending 10.0.0.0/24 traffic via the Proxmox host.
  • Proxmox host: 192.168.100.1/24 on the same VLAN, with IP forwarding enabled and routing between the transit network and the VM bridge.

The transit network runs at MTU 1400 (a Hetzner vSwitch requirement), while the VM network runs at MTU 1500 — bridging the two instead of routing them would silently drop large packets (e.g. audio/video uploads to Fotheidil), so the Proxmox host also clamps TCP MSS on the vSwitch interface to protect large transfers crossing the MTU boundary.

Amergin's services are published on 192.168.100.2 and reached either by the webserver VM (public-facing services like Triton streaming and Qomhrá) or the api-gateway VM (internal API calls like Fotheidil diarisation) — see the Amergin page for the current port table and a known discrepancy in one of those ingress rules.

Firewall pattern​

Every server runs UFW with the same shape: allow SSH (22), deny all other inbound by default, then explicitly allow only the specific hosts that legitimately need to reach it — almost always just the webserver VM as the reverse-proxy ingress, plus occasional narrow exceptions for cross-VM telemetry (e.g. the observability VM is allowed to reach app ports directly on services-user, so Uptime Kuma can distinguish an app outage from an ingress outage).