rootless port-forward (pasta) loses real client IPs before Caddy

supernaut kommenterad

2026-07-17 13:50:31 +00:00

Ägare

Found during the v16 upgrade's BC1 verification (#73): real client IPs never reach Caddy at all — rootless Podman's port forwarding (pasta) rewrites the source of inbound connections to the container network, so Caddy logs remote_ip = 10.89.0.15 (its own address) for every external request, and forwards that in X-Forwarded-For.

Evidence (2026-07-17):

External request from a known IP → Caddy access.log shows remote_ip: 10.89.0.15, no incoming XFF.
Controlled probe from the Caddy container with a crafted X-Forwarded-For: 9.9.9.9 → Forgejo resolves and logs 9.9.9.9:0, proving the new v16 [security] REVERSE_PROXY_TRUSTED_PROXIES config works; the internal IP in logs is inherited from Caddy, not a Forgejo config problem.

Consequences: Forgejo audit logs, Forgejo/Caddy rate limiting (#48 edge rate limiting is blocked by this — it would rate-limit all external traffic as one client!), and Loki access-log analytics have never had real client IPs.

Fix candidates:

systemd socket activation for the Caddy Quadlet (the standard rootless reverse-proxy pattern: the host socket is passed to the container, preserving source addresses). Evaluate Quadlet [Socket] support + Caddy's bind on inherited fds.
Alternatively pasta option tuning (source preservation for forwarded ports), or publishing via host networking for Caddy only (weigh isolation trade-off).
After the fix: verify Forgejo logs real client IPs end-to-end (the v16 reverse-proxy trust config is already in place) and update runbook § v16 specifics.

Found during the v16 upgrade's BC1 verification (#73): **real client IPs never reach Caddy at all** — rootless Podman's port forwarding (pasta) rewrites the source of inbound connections to the container network, so Caddy logs `remote_ip = 10.89.0.15` (its own address) for every external request, and forwards that in `X-Forwarded-For`. Evidence (2026-07-17): - External request from a known IP → Caddy `access.log` shows `remote_ip: 10.89.0.15`, no incoming XFF. - Controlled probe from the Caddy container with a crafted `X-Forwarded-For: 9.9.9.9` → Forgejo resolves and logs `9.9.9.9:0`, proving the new v16 `[security] REVERSE_PROXY_TRUSTED_PROXIES` config works; the internal IP in logs is inherited from Caddy, not a Forgejo config problem. Consequences: Forgejo audit logs, Forgejo/Caddy rate limiting (#48 edge rate limiting is **blocked by this** — it would rate-limit all external traffic as one client!), and Loki access-log analytics have never had real client IPs. Fix candidates: - [ ] **systemd socket activation for the Caddy Quadlet** (the standard rootless reverse-proxy pattern: the host socket is passed to the container, preserving source addresses). Evaluate Quadlet `[Socket]` support + Caddy's `bind` on inherited fds. - [ ] Alternatively pasta option tuning (source preservation for forwarded ports), or publishing via host networking for Caddy only (weigh isolation trade-off). - [ ] After the fix: verify Forgejo logs real client IPs end-to-end (the v16 reverse-proxy trust config is already in place) and update runbook § v16 specifics.

supernaut lade till etiketterna

Rader
Kolumner

rootless port-forward (pasta) loses real client IPs before Caddy #81