Treat LAN as semi-hostile: inventory + bind services to tailnet/loopback #110

New issue

Closed

opened 2026-05-24 21:45:52 +00:00 by coilysiren · 0 comments

coilysiren commented

2026-05-24 21:45:52 +00:00

Owner

Problem

Today the LAN is implicitly treated as a trust boundary - devices on the home network can reach each other and reach kai-server's LAN-side surface without per-flow authentication. That's the conventional home posture but it's wrong for Kai's actual threat model: a router compromise, an IoT device compromise, or a guest-device compromise all become full LAN access.

Goal

Move from 'LAN = trust boundary' to 'LAN = routing boundary, tailnet = trust boundary.' kai-server already does this for SSH (tailnet-only); extend the pattern.

Scope - in

Inventory every service on every coilysiren-owned host that currently listens on the LAN interface. Build the list before changing anything.
For each service, decide: (a) tailnet-only, (b) loopback + tailnet, or (c) genuinely needs LAN exposure (printers, Chromecast-style devices).
Bind LAN-only-by-accident services to tailnet or loopback.
Document any service that must stay LAN-exposed and why, so the next sweep doesn't re-litigate.
Consider VLAN segmentation for IoT/guest traffic once the router has the capability (likely after the Ubiquiti migration).

Scope - out

Mutual TLS / per-service auth uplift. Tailnet identity is the auth layer for now; service-level auth is a later concern.
Anything requiring router VLAN support before the Ubiquiti migration.

Why now

Posture work that's cheap to start and compounds. Doesn't block on hardware.

Filed by Claude.

**Problem** Today the LAN is implicitly treated as a trust boundary - devices on the home network can reach each other and reach kai-server's LAN-side surface without per-flow authentication. That's the conventional home posture but it's wrong for Kai's actual threat model: a router compromise, an IoT device compromise, or a guest-device compromise all become full LAN access. **Goal** Move from 'LAN = trust boundary' to 'LAN = routing boundary, tailnet = trust boundary.' kai-server already does this for SSH (tailnet-only); extend the pattern. **Scope - in** 1. Inventory every service on every coilysiren-owned host that currently listens on the LAN interface. Build the list before changing anything. 2. For each service, decide: (a) tailnet-only, (b) loopback + tailnet, or (c) genuinely needs LAN exposure (printers, Chromecast-style devices). 3. Bind LAN-only-by-accident services to tailnet or loopback. 4. Document any service that must stay LAN-exposed and why, so the next sweep doesn't re-litigate. 5. Consider VLAN segmentation for IoT/guest traffic once the router has the capability (likely after the Ubiquiti migration). **Scope - out** - Mutual TLS / per-service auth uplift. Tailnet identity is the auth layer for now; service-level auth is a later concern. - Anything requiring router VLAN support before the Ubiquiti migration. **Why now** Posture work that's cheap to start and compounds. Doesn't block on hardware. **Filed by Claude.**

coilysiren added the

priority

label

2026-06-04 08:16:54 +00:00

coilysiren added

priority

and removed

priority

labels

2026-06-17 08:40:26 +00:00