nimmo/nixos-config
nimmo/nixos-config
Watch
1
0
Fork
You've already forked nixos-config
 0
Code Issues 15 Pull requests Wiki Activity Actions
Page: 14 Network and Access Topology
Pages
00 Documentation Map and Scope 00 Documentation Standards 00 Start Here and Governance 10 System Atlas 11 Fleet Overview 12 Host Inventory 13 Service Catalogue 14 Network and Access Topology 15 Storage and Data Map 16 Automation and Control Plane 20 Architecture Decisions 21 ADR 001 Electra Hardware Specialisations 22 ADR 002 Workload Placement 23 ADR 003 Network Exposure 23 Project Tracking 24 ADR 004 Engram Durable Agent Memory 24 Security Baseline 25 ADR 005 Auto Update Control Plane 26 ADR 006 Scoped Secret Files 30 Operations and Runbooks 31 Routine Fleet Operations 32 Safe Testing and Deployment 33 Host Provisioning 34 Monitoring and Service Investigation 35 Backup Verification and Partial Restore 36 Full Host Recovery 37 Electra Boot Trust Recovery 38 Secret Editing and Recipient Rotation 39 Auto Update Incident Response 39a Service Migration and Cutover 39b Wrapper Repository Packaging 40 Engineering Handbook 41 Repository Structure and Import Chain 42 Configuration Ownership Boundaries 43 Adding Packages and Flake Inputs 44 Adding a Module or Profile 45 Adding a Host 46 Adding or Migrating a Service 47 Testing and CI Contracts 48 Secrets Implementation Conventions 49 Documentation Maintenance 50 NixOS Learning Path 51 Guided Repository Tour 52 Nix Language Essentials 53 Declarative Configuration Store and Generations 54 Flakes and Inputs 55 NixOS Modules and Option Merging 56 SpecialArgs and Home Manager Argument Flow 57 Electra Specialisations Worked Example 58 Nix Troubleshooting Primer 90 Historical Material 91 Electra Secure Boot Hardening Record Home
3 14 Network and Access Topology
Nimmo edited this page 2026-09-12 16:56:13 +01:00
Table of contents

Network and Access Topology

  • Type: Reference
  • Status: Current
  • Scope: Fleet network paths, naming, listeners, and access boundaries
  • Canonical sources: modules/networking/nebula.nix, modules/services/newt.nix, host firewall declarations, service listener options, and container network declarations
  • Last verified: Source commit 556df88494686003b1c4f20c8e0b99b5afc16a6e (2026-09-12)
  • Review triggers: Nebula address or lighthouse changes, DNS changes, listener/firewall changes, Pangolin/Newt routing changes, Docker-network changes, VPN changes, or service moves

This page describes how traffic crosses the fleet. The Service Catalogue owns individual endpoints and authentication; this page owns the route classes and their trust boundaries.

Topology at a glance

Public clients
    |
    | HTTPS / public DNS
    v
Pangolin (external) <---- outbound Newt tunnels ---- Vega / Lyra / Chaos
    |                                                   |
    |                                                   `-- loopback, host,
    `-- selected public routes                              or Docker targets

Paseo clients ---- TLS to code.nimmog.uk:443 ---- public relay route
                                                       |-- Chaos relay target
                                                       `-- Vega fallback relay
                                                            |
                                                            `-- registered daemons

                         public VPS
                    Nebula lighthouse + relay
                              |
               encrypted 10.10.0.0/16 overlay
           +----------+------+--------+----------+
           |          |               |          |
        laptops    Vega resolver/   Lyra       Cosmos/Chaos
                   IPv4 exit node
                              |
                              `-- NAS and other mesh members

Pangolin, the public VPS, public DNS, the NAS, and Proxmox are external dependencies. This repository configures the fleet side of their relationships but cannot prove the external side from Nix evaluation alone.

Nebula mesh

All registered hosts join the mesh Nebula network. The repository also reserves names for external or staged members.

Name Overlay address Repository status or role
pangolin-vps 10.10.0.1 External public lighthouse and relay
vega 10.10.0.2 Managed client, CoreDNS resolver, IPv4 exit node
lyra 10.10.0.3 Managed GPU/media server
nova 10.10.0.4 Staged NixOS target; currently external to the managed NixOS fleet
mass-storage 10.10.0.5 External NAS dependency
media1 10.10.0.6 Legacy external/reserved member
nimmog-de 10.10.0.7 External member
cosmos 10.10.0.8 Managed database VM
chaos 10.10.0.9 Managed container VM
electra 10.10.0.20 Managed laptop
lena 10.10.0.21 Managed laptop

The public VPS at 10.10.0.1 is the sole configured lighthouse. Ordinary clients bootstrap through its public UDP endpoint and use it as their relay when direct NAT traversal fails. Vega is explicitly configured as neither a lighthouse nor a relay; older two-lighthouse descriptions are stale. The module retains a Vega entry in its lighthouse map for lighthouse-to-lighthouse logic, but no current managed host enables that role.

Nebula has its own encrypted overlay firewall and the NixOS host firewall adds a second layer:

  • Nebula outbound and inbound policy is presently permissive within the mesh. Tightening this with group rules remains planned work.
  • Services intended only for the mesh normally bind to an overlay address and open their port only on nebula.mesh in the NixOS firewall.
  • Binding to 0.0.0.0 and using networking.firewall.allowedTCPPorts is a broader exposure class: it permits the port on physical/LAN interfaces too.
  • A listener on loopback or a private Docker bridge is not reachable merely because the mesh firewall is permissive.

Host Nebula private keys are delivered from host-scoped SOPS files. The CA and host certificates are repository inputs; key material is not stored in the wiki.

Mesh naming and DNS

NixOS mesh members receive static /etc/hosts entries for both bare names and name.mesh. This makes managed-host lookup independent of a live DNS server.

Vega additionally runs CoreDNS on 10.10.0.2:53 for non-NixOS clients and the phone full-tunnel path. Static name.mesh zones come from the same host map. Other .mesh queries forward to the public lighthouse's Nebula serve_dns on port 5300; ordinary DNS forwards to public recursive resolvers. Port 53 is opened only on Vega's nebula.mesh interface.

Public application names such as wiki.nimmog.uk and code.nimmog.uk are a separate DNS and ingress plane. The repository records the names applications expect, but public DNS records and Pangolin route definitions live outside it.

Public ingress through Pangolin and Newt

Vega, Lyra, and Chaos run native Newt clients. Each makes an outbound connection to https://pangolin.nimmog.uk using a host-scoped SOPS environment. Public HTTPS terminates in the external Pangolin plane and is forwarded through the corresponding tunnel to a configured upstream.

The upstream can have one of three shapes:

Target class Example Consequence
Host loopback BookStack 127.0.0.1:80, Paperless 127.0.0.1:28981 Service is reachable locally and through its tunnel, not directly from LAN or mesh
Dedicated Docker bridge gateway FreshRSS on Vega's newt_default gateway 172.18.0.1:8082 Newt's container network can reach the host without a LAN-wide listener
Container name/private network Vega's fallback Paseo relay on newt_default Traffic stays inside the selected Docker network

The repository declares the Newt clients and many expected application URLs, but the Pangolin-side target list is external state. A working NixOS service therefore does not by itself prove that its public route is correct.

Lyra's retained SWAG boundary

Lyra still has a mutable Docker/SWAG estate under /srv/stacks. Native Jellyfin and Immich deliberately expose host ports so that the retained proxy can reach them through the Docker host gateway. Other firewall entries on Lyra support retained containers and local services.

The Nix repository can verify host listeners, firewall openings, mounts, and native services. It cannot fully inventory SWAG routes or container-network membership because their definitions are not stored here. Treat claims about a specific public SWAG route as requiring inspection of the live stack.

Docker network boundaries

  • Vega's newt_default bridge uses host gateway 172.18.0.1 for selected Newt-to-host traffic. A separate 172.22.0.0/16 Whisparr bridge may reach Vega PostgreSQL at gateway 172.22.0.1.
  • Chaos assigns Docker networks from 172.30.0.0/16 in /24 blocks to avoid overlap with the Nebula 10.10.0.0/16 range.
  • Chaos's slskd-net is a private application network. SynthSeek reaches slskd and Plexdrome by container alias; Plexdrome publishes no host port.
  • Docker group membership is treated as root-equivalent access and is an accepted convenience on these personal machines.

Docker networking is not a security boundary against a user with Docker daemon access. Service isolation still depends on listener choices, host firewall rules, application authentication, and the external ingress policy.

Administrative and client access

Path Scope
SSH on Electra and Lena Port 22 opened only on nebula.mesh; password and root login disabled
SSH and Mosh on server hosts Enabled by the server profile with host-wide firewall openings; SSH password and root login disabled
Laptop WireGuard profile Electra and Lena have a manually activated NetworkManager full-tunnel profile; this is independent of Nebula
Vega exit node Provides IPv4 NAT for Nebula unsafe-route clients through enp86s0; IPv6 forwarding is deliberately disabled
Service administration Prefer the narrowest applicable path: local socket/loopback, then Nebula, then authenticated public ingress

Declared exposure findings

These are configuration facts to feed the later Security Baseline, not claims of active compromise:

  • The Nebula overlay policy currently accepts any inbound mesh traffic; NixOS interface firewall rules provide the service-by-service restriction.
  • Engram Cloud, Lyra's Ollama and Wyoming services, and several retained media service ports use all-interface listeners or global firewall openings.
  • Paseo daemons currently bind their hosts' Nebula addresses and open port 6767 on nebula.mesh; their TLS relay registration is a separate path.
  • Server-profile SSH and Mosh openings are host-wide, whereas laptop SSH is mesh-only.
  • Pangolin routes and Lyra's SWAG definitions are operational dependencies not reviewable from this repository.

The Storage and Data Map documents how local, NAS, database, and backup traffic relate. Operational changes belong in Operations and Runbooks, and accepted trust-boundary choices are recorded in ADR-003. Return to the System Atlas.