From 8f0e576c49ad0c40e3d7b914566ceb09b0de2fd8 Mon Sep 17 00:00:00 2001 From: Mike Swanson Date: Wed, 17 Jun 2026 09:22:05 -0700 Subject: [PATCH] unifi-wifi: correct the Teleport finding - config API IS reachable via the connector Earlier "no usable Teleport API" was wrong (probed /rest/teleport, /stat/teleport, /v1/teleport). Gemini research + live verification: Teleport config lives at /api/s//rest/setting/teleport (GET/PUT, also under /get/setting key 'teleport') - reachable via the connector. Brooklyn confirmed enabled, subnet 192.168.1.1/24. Invite generate/revoke is reportedly POST /api/s//cmd/teleport {"cmd":"generate-invite"|"revoke-invite"} (untested - it creates a live VPN access link; gate as a write). Invites are WiFiman-app-only. Proxy path is /v1/connector/consoles/{id}/proxy/... (Gemini's /v1/hosts/{id}/proxy form 404s). Doc updated. Co-Authored-By: Claude Opus 4.8 (1M context) --- .../unifi-wifi/references/site-manager-api.md | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) diff --git a/.claude/skills/unifi-wifi/references/site-manager-api.md b/.claude/skills/unifi-wifi/references/site-manager-api.md index 4eeb0f58..ee86256b 100644 --- a/.claude/skills/unifi-wifi/references/site-manager-api.md +++ b/.claude/skills/unifi-wifi/references/site-manager-api.md @@ -115,9 +115,16 @@ The connector reaches the gateway config surface - `GET/PUT /rest/networkconf`, (`purpose=remote-user-vpn`, `vpn_type=wireguard-server|openvpn-server`; site-to-site as `*-vpn`). So VPN configs are READABLE now and WRITABLE in principle (PUT/POST) - but writes are high-stakes (lockout risk) and must be DRY-RUN + confirm gated like gw-control.sh; not wired in yet. -**Teleport: no usable API found** - `/v1/teleport`, `/ea/teleport` -> 404; per-console `/teleport` -> 403; -no teleport-tagged networks. It's the ui.com-brokered zero-config overlay, managed via the account/app; -needs deeper research before claiming any programmatic path. +**Teleport: config IS reachable** (corrected 2026-06-17 - the first probes used the wrong paths +`/rest/teleport`/`/stat/teleport`/`/v1/teleport`). The real surface: +- `GET/PUT /api/s//rest/setting/teleport` (also under `/get/setting`, key `teleport`) -> reads/writes + `{enabled, subnet_cidr}`. Confirmed via connector: Brooklyn Teleport `{enabled:true, subnet_cidr:'192.168.1.1/24'}`. +- Invite generate/revoke is reportedly `POST /api/s//cmd/teleport {"cmd":"generate-invite"|"revoke-invite"}` + (Gemini + community + pulumiverse-unifi `setting.Teleport`) - NOT tested here; it creates a live VPN access + link, so gate it as a write. Caveat: Teleport invites are consumable only by the WiFiman app (no native + WireGuard `.conf` export). +- Reach it via the connector `/v1/connector/consoles/{id}/proxy/network/api/s//...` (Gemini's + `/v1/hosts/{id}/proxy` form 404s; grok xsearch returned empty twice on this query - gemini + live probe settled it). ## Gotchas - Direct WAN SSH/HTTPS to a standalone UDM is usually firewalled (Brooklyn 67.1.139.219: