VR1 Office1 -- as-built inventory and connection reference

Purpose. The single operational answer to "what is running, where, on what address, and how do I reach it." Every value here was MEASURED on the live system, not planned or inferred. Update it in the SAME change that brings a host or service online -- a stale connection table is worse than none.

Scope. VR1 Office1 only (the site headend). DC1/DC2 get their own sections when they exist.

Authority note. NetBox is the IPAM apex -- this table is an OPERATIONAL reference (how to reach things, where credentials live), NOT the address authority. Where the two ever disagree, NetBox wins and the divergence gets fixed here. The D-115 carve IS now imported into the Office1 sandbox NetBox (2026-07-13) -- site vr1-off1, roles office + edge, and every prefix below. It has NOT yet been fed back upstream to netbox.baldurkeep.com; that is an operator-gated step.

Last measured: 2026-07-13.

1. Networks

The DHCP split is structural. Two authorities, two physically separate L2s. lxdbr0 is NEVER bridged onto office1-local, so Kea and MAAS cannot see each other. LXD's own dnsmasq is disabled (ipv4.dhcp=false, dns.mode=none, raw.dnsmasq=port=0) and binds no :53 and no :67.

IPv6: Office1's carve is 2602:f3e2:f01:100::/56 with office subnet 2602:f3e2:f01:100::/64 (D-115). NOT YET DEPLOYED -- pinned as the next step. Note IPv6 does NOT egress the lab (measured: v6 gateway reachable, v6 internet 100% loss), so v6 here will be LAN-local only.

2. Hosts and services

office1-netbox and office1-tailscale are MAAS-composed LXD VMs (D-114) -- MAAS enlisted, commissioned, deployed and powers them. The voffice1 LXD host is office1-lxd (vm-host id 1).

3. How to reach each thing

All access is via the Office1 service SSH key: ~/vr1-office1-creds/office1_svc_ed25519 on vcloud (private half NEVER read; SEC-007 tracks its rotation).

office1-local (10.10.0.0/24) and lxdbr0 (10.10.1.0/24) are host-local to vcloud -- not routable from a workstation. Everything below therefore tunnels through vcloud.

Routing to the compose net. The OPNsense edge has a static route 10.10.1.0/24 -> 10.10.0.20 (gateway object OFFICE1_LXD_GW, priority 255, NOT the default gateway). So any office1-local client using the edge as its gateway reaches the compose net. vcloud itself does NOT -- its default route is the lab, so it needs an explicit route (operator sudo): sudo ip route replace 10.10.1.0/24 via 10.10.0.20 dev virbr2

Tailscale front door (D-107: Office1 ONLY). office1-tailscale is a subnet router on the operator's SELF-HOSTED control plane (https://tailscale.baldurkeep.com:443 -- NOT Tailscale's public one). It is UP and online as 100.64.0.53, advertising 10.10.0.0/22 -- exactly the D-115 Office1 carve, so "Office1 only" is enforced by the CARVE, not by policy alone.

• Brought up with: --login-server=https://tailscale.baldurkeep.com:443 --authkey=<file> --advertise-routes=10.10.0.0/22 --accept-routes --accept-dns=false --hostname=office1-tailscale
• --accept-dns=false is DELIBERATE (a deviation from the operator's usual command): this is a MAAS-managed machine and MAAS's bind9 serves its internal names. Letting the tailnet take over DNS would break that resolution. Flip it if MagicDNS is wanted here.
• ROUTE IS ENABLED (operator, 2026-07-13). The 10.10.0.0/22 subnet route is live on the self-hosted control server and verified from the workstation -- the OPNsense GUI answers directly at https://10.10.0.1 with no SSH tunnel. This SUPERSEDES the tunnel commands in the table above: from a tailnet-joined workstation, every Office1 address in the /22 is reachable directly. The tunnels remain valid as a fallback when off-tailnet.
• The auth key was consumed by path from a 0600 file and shredded from the node after use -- tailscaled holds its own node key now. It never entered an operator session or the repo.

Once the route is enabled, the whole Office1 carve -- edge GUI, MAAS UI, NetBox -- is reachable from the tailnet with no SSH tunnels at all, which supersedes most of the tunnel commands above.

4. Where the credentials live (NEVER commit; never print)

NetBox API token format (4.6): the wire form is nbt_<key>.<plaintext>. The API's token field alone is NOT usable -- present it raw and you get 403 Invalid v1 token. See docs/changelog-20260713-office1-netbox-deployed.md.

5. Standing traps for this site (the short list)

1. DHCP on the edge is API-MANAGED. A rendered config.xml push would CLOBBER it. That path is DELETED (D-113(a2)); configure via scripts/opnsense-api.sh.
2. OPNsense gateways: defaultgw in the API output is DERIVED FROM priority (lower = more preferred), not from what you send. Adding a LAN gateway with a lower priority than WAN_GW SILENTLY STEALS THE DEFAULT ROUTE and kills site egress -- this happened on 2026-07-13. Always add the gateway, READ THE CONFIG BACK, confirm WAN_GW is still default, and only THEN reconfigure. WAN_GW is now priority 1; OFFICE1_LXD_GW is 255.
3. root's shell on the edge is tcsh -- $(...) and 2>&1 fail (quietly, or with "Ambiguous output redirect"). Feed remote commands to sh -s.
4. lxc reads config from stdin -- in a piped script every lxc call needs </dev/null or it eats the rest of the script.
5. MAAS's bind9 intermittently SERVFAILs a first-time external lookup and succeeds on retry (seen twice: docker registry, tailscale.com). Retry before diagnosing.
6. A tofu apply touching a libvirt_domain's devices BOUNCES THE GUEST, even when the plan says "updated in-place". Schedule it as an outage.

6. IPAM -- what NetBox now says about this site (D-115 carve, imported 2026-07-13)

The Office1 sandbox NetBox (10.10.1.201:8000) was seeded from the upstream draft (129 objects: 1 RIR, 23 roles, 5 regions, 10 sites, 90 prefixes) and then had the D-115 carve applied on top. Site vr1-off1 ("VR1 Off1"), region VR1.

Every one of these addresses was already running. D-115 blesses what is deployed rather than renumbering it -- the carve cost ZERO renumber. What it fixed is that 10.10.0.0/24, 10.10.1.0/24 and 172.30.1.0/24 were SQUAT: on the wire with no allocation behind them.

Naming (D-117): VR1's datacenters are DC0/DC1 (matching the apex, which already held both sites) but the office keeps its number -- it is Off1. VR1 therefore reads DC0/DC1/Off1 while VR0 reads DC0/DC1/Off0. Accepted cosmetic asymmetry; the site is NEW upstream so nothing was renamed and no deployed object changed.

Not yet upstream. The sandbox is a simulation. Feeding this carve back to netbox.baldurkeep.com is a separate, operator-gated write (netbox/d115-office-carve.py refuses a non-sandbox target unless given --yes-write-upstream).

Reproduce the sandbox from scratch:

python3 netbox/prod-draft-dump.py --out netbox/draft/vr1-draft.json     # on vcloud, READ-ONLY
# then on office1-netbox, with the sandbox token:
python3 sandbox-seed.py --draft draft/vr1-draft.json --commit
python3 d115-office-carve.py --commit