serverAppConfigs/serverAppConfigs-docs/Architecture/Network Architecture.md

type, description, tags, timestamp

type	description	tags	timestamp
reference	One Caddy fronts both hosts.	architecture network	2026-09-02

Network Architecture

One Caddy fronts both hosts. It runs as a container on Dankclaw (192.168.0.143) and terminates TLS for every service on the LAN. Pi-hole on Dankclaw answers the service names for LAN clients; Porkbun answers them for the WAN. The G36 router firewall governs external access. SearXNG outbound traffic exits through the Gluetun VPN container.

Topology

As of 2026-08-28 the front door is a two-tier chain: Caddy terminates TLS, Anubis verifies the client (DENY known AI scrapers, CHALLENGE everyone else), and accepted traffic returns to Caddy's internal listener on :8016, which proxies every request whole to the Authentik server with the Host header preserved; Authentik's embedded outpost routes on that Host against each proxy provider's external_host, serves the login flow in place for sessionless clients, and forwards authenticated traffic back to Caddy's post-auth listener :8017, where per-vhost routing reaches the app. See Anubis and Authentik.

graph TB
    EXT[Internet] -->|port forwards 80/443| CADDY[Caddy TLS :80 :443 — Dankclaw]
    LAN[LAN clients] -->|Pi-hole DNS :53| CADDY

    subgraph Dankclaw[Dankclaw 192.168.0.143]
        CADDY -->|unwrapped vhosts route direct| DIRECT{direct routes}
        CADDY -->|guarded vhosts| ANUBIS[Anubis verify :8923]
        ANUBIS -->|deny AI bots| EXT
        ANUBIS -->|challenge solved or transport-exempt| INT[Caddy internal listener :8016]
        INT -->|whole request, Host preserved| AUTH[Authentik embedded outpost :9000]
        AUTH -->|session valid, provider internal_host| POST[Caddy post-auth listener :8017]
        POST --> HOME[Homepage file_server]
        POST --> SEARCH[SearXNG via Gluetun netns :8081]
        POST --> PROM[Prometheus :9090]
        DIRECT -->|3000 + ssh 2222| GITEA[Gitea]
        DIRECT -->|3005| OWEBUI[OpenWebUI]
        DIRECT -->|3002| GRAFANA[Grafana :3000]
        DIRECT -->|8083 web UI| PIHOLE[Pi-hole]
        AUTH -->|login UI + sessions| AUTHDB[(Authentik Postgres :5432)]
        SEARCH -.->|tunnel exit| GLU[Gluetun VPN]
        GLU -.-> EXT
    end

    subgraph Dankserver[Dankserver 192.168.0.235]
        ROMM[RomM :8085]
        COPY[Copyparty :3923]
        CAL[Calibre-Web :8083]
        PLEX[Plex :32400]
        JEL[Jellyfin :8096]
        ARR[*arr stack + qBittorrent]
    end

    POST -->|romm| ROMM
    POST -->|files| COPY
    DIRECT -->|plex plain-HTTP passthrough| PLEX
    DIRECT --> CAL
    DIRECT --> JEL
    DIRECT --> ARR

Guarded (through Anubis): homepage, search, prometheus, romm, files. Exempt by construction: auth. (the IdP login itself), plex (plain HTTP), gitea (git smart-HTTP clients cannot solve JS challenges — /info/refs and git-*-pack pass unchallenged), grafana (own auth).

Dankserver runs no proxy of its own. Its services expose published LAN ports, and the Dankclaw Caddy routes the names to those ports.

Hostnames

Scope	Convention	Resolved by
LAN	romm.franksdank.cloud → 192.168.0.143	Pi-hole (addn-hosts)
WAN	romm.franksdank.cloud → 71.227.227.172	Porkbun A record

Users type a name and nothing else. Caddy maps the name to the upstream. The split between the two resolvers removes the need for router NAT loopback. See LAN-DNS for the flow and the router hand-off.

TLS

Caddy holds one Let's Encrypt certificate per vhost, issued and renewed through the DNS-01 challenge via the Porkbun module. No inbound port 80/443 is required. Details in Caddy.

Gluetun Path (SearXNG only)

gluetun.container, searxng.container and searxng-valkey.container all set Network=searxng.network in their Quadlet sources (runtime network systemd-searxng); only those three share the tunnel. The old compose idiom (network_mode: service:gluetun) is gone — a shared named network is what carries SearXNG's outbound traffic through the VPN exit. Everything else on Dankclaw uses the normal LAN route. This matches KB Pattern 2 in Gluetun. See Container Network Namespaces for which addresses are reachable from that namespace (none of the unpublished host-netns listeners).

Access Policy

• The G36 router firewall governs what the WAN can reach. Port forwards are manual router steps; the repo tracks no router state.
• Access is layered: Anubis challenges/denies bots at the front door, then Authentik's embedded outpost (whole-request proxy, routed by Host → provider external_host) gates the wrapped apps — one proxy provider per guarded host is mandatory, and Anubis exempts the /outpost.goauthentik.io/* transport paths so login can happen before a challenge cookie exists. Apps with their own login (Grafana, Gitea, Plex) run unwrapped. See Anubis and Authentik.
• LAN subnet: 192.168.0.0/24.

See Also

• LAN-DNS — name resolution, Pi-hole, router hand-off
• Caddy — vhost map, TLS, basic auth
• Dankserver Stack, Dankclaw Stack
• Gluetun
• Knowledge base: Gluetun, SearXNG
• Container Network Namespaces — who can dial what on Dankclaw (host netns vs bridge nets)