Skip to main content

LAN reachability

A kixctl-deployed app is internal by default: reachable only through kixctl's own resolver and edge, both on the owned bridge. Nothing on your wider network resolves or routes to it until you choose to expose it — kixctl does not touch your network unasked.

Turn on Allow LAN reachability under Settings → Ingress, and the Updates tab shows the resolver address and the zone. The rest is yours to do, because it lives in equipment kixctl does not own.

Two things must be true​

A name works on your LAN only when both hold, and they are independent:

  1. Resolvable — a client that looks up <app>.<zone> (the default zone is apps.internal) gets an answer. Your device asks whatever DNS server your router handed it; kixctl's resolver is not that server unless you make it so.
  2. Routable — the client can reach the address it gets back. Deployed apps sit on the NAT'd owned bridge, so packets from your LAN need a path into that subnet.

If you run your own resolver​

Add a conditional forwarder: forward only the managed zone (apps.internal) to the resolver address the Updates tab shows, and let everything else resolve as it does now. This exposes only your app zone and leaves the rest of your DNS untouched.

  • Technitium — add a Conditional Forwarder zone for apps.internal pointing at the resolver address.
  • Unbound — a forward-zone: stanza with name: "apps.internal" and forward-addr: set to the resolver address.
  • Pi-hole — a conditional forwarding entry for the zone and the resolver address.
  • OPNsense (Unbound) — Services → Unbound DNS → Query Forwarding, a domain override for the zone.

If you have a stock router​

Most consumer routers cannot do conditional forwarding — they set one DNS server for the whole LAN. Until a primary-resolver mode ships, the supported paths on a stock router are to point a single device's DNS at the resolver address, or to reach the app by IP once the route below is in place.

The route (bolt-on)​

Resolving the name yields an address on the owned bridge, which your LAN cannot reach across the bridge's NAT without a route. Provide it the way that fits your setup — a static route on your router toward the kixctl host, or by placing the app on a LAN-attached network instead of the owned bridge. Moving an app off the owned bridge gives up the isolation and the in-app network control that owning the bridge provides.

The appliance​

None of this is necessary on the kixctl appliance. There kixctl is the host and owns the network path, so LAN reachability is handled rather than left as an operator step. The bolt-on trades that convenience for running on a cluster you already have.