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

---
type: reference
title: Container Network Namespaces
description: "How Podman builds container networks here: the network inventory, the netns sharing mechanism, and the isolation limits."
tags:
  - networking
  - podman
  - netavark
  - rootless
  - dankclaw
timestamp: 2026-09-02
---

# Container Network Namespaces

On a rootless-Podman host, "talk to a local service" is not one question — it is
one question **per network namespace**. A container in the host network
namespace sees every host listener on `127.0.0.1`; a container on a bridge
network does not, and cannot be made to by name or by loopback. This page is the
address map for Dankclaw (192.168.0.143) and the rule that explains it.

## The rule

A container only reaches services that are reachable **from inside its own
network namespace**:

- `Network=host` → the container *is* in the host netns. It dials other host
  services on loopback (`127.0.0.1:PORT`) and binds any free port itself.
- `Network=<name>.network` / `Network=dankclaw_default` (bridge, netavark) → the
  container has its own netns. Loopback inside it is **its own** loopback. The
  only host address it can dial is the network's gateway IP, and on a rootless
  host that path is served by `rootlessport`, which forwards **published port
  maps only**. An unpublished host listener is refused immediately (RST), not
  routed.
- Container DNS names (`gitea-server`, `authentik-postgres`, `valkey`) resolve
  **only inside the network that owns them**, so a container on another network
  can never reach a peer by name — see the naming quirk below.

## Live address map (Dankclaw, verified 2026-09-02)

| Container | `NetworkMode` | Reachable from it |
|---|---|---|
| `systemd-hermes` (gateway) | `host` | everything on the host netns, incl. signal-cli at `127.0.0.1:8080` and the webui on `:8787` |
| `hermes-webui` | `host` | same; binds `0.0.0.0:8787`, so it is LAN-reachable, not loopback-only |
| `chrome-devtools-protocol` | `host` | binds `127.0.0.1:9222` — deliberately loopback-only, unreachable from the LAN and from bridge nets |
| `hermes-dashboard` | `dankclaw_default` (bridge) | only published ports, via the gateway IP `10.89.1.1` |

`Network=` values are read from the live Quadlet sources in
`/home/dank/.config/containers/systemd/*.container`; runtime network names on the
host at the same date were `podman`, `dankclaw_default`, `systemd-gitea`
`systemd-searxng`, `systemd-open-webui`.

Two consequences that are easy to miss:

1. **The Hermes gateway can dial the Signal daemon on loopback only because it
   runs in the host netns.** The dashboard — same image, same `/data` — cannot;
   it shares state through the bind mount instead, never over the network.
2. **Caddy sits on `dankclaw_default`**, so every upstream it proxies must be
   reachable from that network by **IP + published port**. Cross-network traffic
   by container DNS name is not available to it: `gitea-server` lives on
   `systemd-gitea`, `valkey` on `systemd-searxng`, and neither resolves from
   Caddy's namespace. That is why Gitea is fronted as `IP:3000` and SearXNG as
   `:8081` rather than by service name.

## Naming quirk: `<name>.network` becomes `systemd-<name>`

A Quadlet `Network=gitea.network` yields a runtime network named
**`systemd-gitea`**, not `gitea`. Probe with `podman network ls`, never by the
filename, or health checks and `Network-Alias` plans target a network that does
not exist.

## Verification recipe (read-only)

```bash
# which containers are on which network? (`podman network inspect` in this
# podman version has no `.containers` field, so list from the container side)
podman ps -a --format '{{.Names}} {{.Networks}}'   # empty Networks = host or shared netns
# what listens on the host netns, and who owns it?
sudo ss -ltnp 'sport = :8080'

# what can a bridge-net container actually dial? run the probe inside its netns
podman exec <name> cat /proc/net/route          # default route → gateway IP
podman exec <name> sh -c 'timeout 2 bash -c "exec 3<>/dev/tcp/10.89.1.1/8080"; echo rc=$?'
```

Verified outcomes of that recipe on 2026-09-02: from inside `hermes-dashboard`
`10.89.1.1:3000` (Gitea, published), `:8081` (SearXNG via Gluetun's netns,
published) and `:9119` (its own published port) connect; `:8080` and `:8787`
are **refused instantly** even though both listeners are bound to `0.0.0.0` in
the host netns. Probes to `host.containers.internal` (`169.254.1.2`) from that
network time out rather than refuse — but see the 2026-10-19 re-measure below,
where the same alias answers from another `dankclaw_default` container.

### 2026-10-19: which published ports a rootless container can actually dial

Probed from inside `open-notebook` (rootless, on `dankclaw_default` **and** the
private `systemd-open-notebook`), each address aimed at a live listener:

| Dial | Result | Mechanism |
|---|---|---|
| `192.168.0.143:3000` (Gitea) | **200** | published by a **rootless** container — rootless egress crosses the host netfilter where netavark installed that DNAT |
| `192.168.0.143:7770` (`frank-dragoon`) | refused | the container is **rootless on podman's default `pasta` netns** (the root unit's `User=dank` runs `podman run`, so it lands in dank's storage). Pasta forwards the published port in the host netns — the host and the LAN both answer 200 — but installs no netavark DNAT for traffic arriving from a rootless bridge, so the same address is refused from a container. This is NOT a root/rootless rule-set split: `podman ps` as `dank` lists it |
| `host.containers.internal:7770` (`169.254.1.2`) | **200** | the pasta forwarder is bound `0.0.0.0` on the host, so the gateway alias reaches it — and the alias is link-local, which is the dead end below |
| `192.168.0.143:7771` (`frank-zealot`) | refused | host-netns listener, unpublished — the rule above, reconfirmed |
| `10.89.1.1:7771` | refused | the bridge gateway address belongs to the rootlesskit netns, not to the host |
| `host.containers.internal:7771` (`169.254.1.2`) | **200** | the gateway alias is the one address that carries a rootless container to a host-netns listener. Why `hermes-dashboard` timed out on this alias in 2026-09-02 while `open-notebook` answers today is **not established**; the difference to check first is the second network and where the default route lands |
| `192.168.0.235:7770` (`frank-archon`) | **200** | a different machine: plain routing, no DNAT in the path |

The consequence that changes designs: **a rootless container's menu of local model
endpoints is `frank-tts` (container DNS, same network) and `frank-archon` (LAN
address on another host).** A `pasta` endpoint has no address an app container can
use: the LAN address is refused, and the one alias that answers is link-local,
which some applications refuse to store at all ([[Open Notebook]] meets exactly
that refusal). Pasta cannot be *added to* either —

```
podman run --network pasta --network dankclaw_default …
Error: cannot set multiple networks without bridge network mode, selected mode pasta
```

so the only shape that makes such an endpoint nameable is **moving it onto
`dankclaw_default`** (`FRANK_DRAGOON_NETWORK` in `scripts/frank-dragoon.env`,
2026-10-19). For frank-dragoon that is not an exposure change: the engine's
unauthenticated token port binds the container's **own loopback**
(`/proc/net/tcp` on 2026-10-19: `127.0.0.1:8730`, `0.0.0.0:8731`), so only the
API port becomes name-resolvable, which is the same trust the published 7770
already carries on the LAN. `frank-zealot` (7771) stays a host-netns binary and
remains unreachable except through the link-local alias.

## Operational rules

- Health checks for a bridge-network service must target a **published** port (or
  run via `podman exec` inside the unit), never `localhost:<port>` from the
  host — and never the reverse either: the deployer's health probe runs on the
  host, so it sees host-netns listeners that the container itself cannot dial.
- To give a bridge-net container access to a host-netns listener, the options
  are (a) move it to `Network=host`, or (b) publish the needed port — but
  publishing is advertised **only inside the Podman that owns the container**:
  a root container's published port stays invisible to a rootless consumer
  (2026-10-19 table above), so the fix must be made on the same root/rootless
  side as the consumer. Either way it is an exposure change — a published port
  also answers on the LAN — and needs operator approval before deployment, not
  a silent fix.
- `chrome-devtools-protocol` is intentionally `Network=host` with a loopback-only
  bind so the browser tool stays unreachable from the LAN; do not "tidy" it onto
  a bridge network — its two consumers (gateway, webui) are host-netns and reach
  it on loopback.

## Exposure note: signal-cli-daemon is a host process, not a container

`signal-cli-daemon.service` runs as a **user** unit for `dank`
(`systemctl --user cat signal-cli-daemon.service`) with
`org.asamk.signal.Main --account <redacted> daemon --http 0.0.0.0:8080`. The
bind is all-interfaces, so the daemon's HTTP API is reachable from anywhere on
the LAN; verified from a second LAN machine with an unauthenticated
`GET /v1/version` → `HTTP 404` and body `<h1>404 Not Found</h1>No context found
for request` (Micronaut's no-route response), i.e. the socket answers to
strangers. The Hermes gateway in the host netns dials it on loopback, which is
the only reason a non-loopback bind is not *required* by any consumer here —
see [[Hermes]] for the consumer side.

## See Also

- [[Hermes]] — the gateway + Signal daemon this page's address map is keyed on
- [[Hermes-Dashboard]] — the one Hermes container that is *not* in the host netns
- [[Hermes-WebUI]] — host-netns service with a `0.0.0.0` bind and password-only auth
- [[Network Architecture]] — the Caddy/Anubis/Authentik front door this map feeds