INBOX/STATUS-netbird-mesh-continuation.md
2026-08-07 15:50:54 +02:00

117 lines
6.1 KiB
Markdown

# Continuation Prompt — NetBird Mesh / Local LLM Remote Access
*Paste this entire block as the first message in a new chat.*
---
I'm continuing my local infrastructure project. The VPN mesh between my
desktop, laptop, and phone is built and mostly working — this thread picked
up mid-way through fixing one specific bug, plus a few smaller things left
open.
## Working style (important)
- One thing at a time, confirmation before moving on.
- I type every command myself; explain each step, wait for my output/error/"done".
- No unsolicited finished scripts or configs — I want to understand and
reproduce each step.
- Architecture/structural decisions: lay out options + trade-offs first,
decide together, don't just implement.
- If I put a **"?"** before a question, I want a short answer only.
- English throughout (technical topic).
- End meaningful steps with a short "Done / Learned" bullet-journal note.
- Check current info/versions before recommending specific tools when it
matters — this space moves fast.
## Devices and identities
| Device | Hostname | NetBird IP | Notes |
|---|---|---|---|
| Desktop | Heimdall-home | `100.105.210.21` | EndeavourOS, user `heimdall`, runs llama-swap |
| Laptop | heymdall-750xed | `100.105.247.153` | EndeavourOS, user `heymdall`, runs Open WebUI |
| Phone | — | — | Joined mesh, not yet pointed at anything |
- Home LAN subnet: `192.168.178.0/24`
- Desktop's Docker bridge: `172.17.0.0/16`, gateway `172.17.0.1`
## Fully working / confirmed
- **NetBird Cloud mesh** — all three devices joined, dashboard shows 3
peers, peer-to-peer connectivity verified (desktop ↔ laptop ping test,
direct path not relayed).
- **llama-swap on the desktop** — running as a proper systemd service
(`llama-swap.service`, `Restart=on-failure`, enabled for boot). Old
manually-run process was killed cleanly; no port conflict.
- **UFW on the desktop** — installed, default-deny incoming / default-allow
outgoing. Port 8080 (llama-swap) restricted to the `wt0` (NetBird)
interface only — verified from the laptop: mesh access works, raw LAN
access is blocked (hangs/times out, doesn't refuse instantly).
- **Desktop sleep prevention** — confirmed KDE PowerDevil and
`systemd-logind` both defaulted to no idle action; additionally hard-masked
`sleep.target`, `suspend.target`, `hibernate.target`, `hybrid-sleep.target`
at the systemd level as a belt-and-suspenders guarantee.
- **Open WebUI on the laptop** (Docker) — installed, connected to the
desktop's llama-swap via `http://100.105.210.21:8080/v1`, all configured
models (`daily`, `coder-fim`, `architect`, etc.) tested and confirmed
working with real inference, not just model-list loading.
- **Cline on the laptop** — pointed at the desktop's llama-swap, confirmed
working.
- **Phone** — added to the NetBird mesh, shows as a connected peer. Not yet
pointed at anything (see below).
## 🔴 Immediate unresolved issue (where this thread left off)
**The desktop's own Open WebUI container can't reach the desktop's own
llama-swap.** Its connection is configured as `host.docker.internal:8080`.
- Root cause **confirmed** via `sudo journalctl -k | grep -i block`: UFW is
blocking the request. `host.docker.internal` resolves to the Docker
bridge gateway (`172.17.0.1`), so the request arrives on the `docker0`
interface — which was never given an allow rule (Step 4 in the setup
guide only opened `wt0`).
- **Fix identified but not yet confirmed executed/tested:**
```bash
sudo ufw allow in on docker0 to any port 8080 proto tcp
```
- **Next action:** have the user run that command, then send a real test
message from the desktop's Open WebUI, then confirm with
`sudo journalctl -u llama-swap -n 5 --no-pager` that a fresh request
appears from the container's Docker IP (`172.17.0.2`).
## Other open items (not urgent, in rough priority order)
1. **Laptop's Open WebUI (port 3000)** is still bound to all interfaces
(`0.0.0.0`), reachable on whatever network the laptop happens to be
connected to — not just the mesh. A fix was proposed (rebind the Docker
port publish to the laptop's specific NetBird IP,
`-p 100.105.247.153:3000:8080`) but never executed — the conversation
moved to the desktop bug above before this was actioned.
2. **Phone → Open WebUI** — not yet tested end to end. Depends on resolving
item 1 first (decide whether phone should reach the laptop's Open WebUI
via its LAN IP or mesh IP going forward).
3. **SSH remote access to the desktop** — deliberately deferred by the user
("when I have time to set up correctly"). Current state: SSH daemon is
running on the desktop, but UFW has no rule for port 22 at all, so it's
unreachable remotely (local keyboard access only). No key-based auth set
up yet either — would need a new ed25519 keypair on the laptop (per the
user's per-device key policy) plus a UFW rule, likely scoped to the home
LAN subnet specifically (not just `wt0`) so it still works as a fallback
if NetBird itself is ever the thing that's broken.
4. **Docker's general iptables/UFW interaction** — flagged as a topic worth
understanding properly later (the `DOCKER-USER` chain approach), since it
will likely recur with future Dockerized services. Not blocking anything
right now — the desktop/laptop specific cases so far have had narrower
fixes that didn't require it.
5. **Vault entries** — three candidates were identified and offered to the
user, but no response yet on which (if any) to draft:
- Kernel/module mismatch after an unrebooted update (general Arch lesson)
- Instant refusal vs. hang/timeout as a firewall diagnostic signal
- Docker bypassing UFW for published ports (the *incoming* case, distinct
from the `docker0`-outbound case solved in this session)
## Reference: full setup as documented
A companion tutorial-style document (`README-netbird-mesh-llm-setup.md`)
captures every step taken so far in reproducible form, including the two
non-obvious pitfalls hit along the way (kernel/module mismatch, and the
`docker0` UFW gap). Bring that in if a fresh recreation or a review of
exact commands is needed.