azcomputerguru/claudetools
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

sync: auto-sync from HOWARD-HOME at 2026-07-10 17:20:37

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-10 17:20:37
This commit is contained in:
Howard Enos
2026-07-10 17:21:06 -07:00
parent d1da1e5857
commit 273eb150c8
1 changed files with 175 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

175
clients/goldstein/session-logs/2026-07/2026-07-10-howard-openvpn-remote-access-sitemagic.md Normal file
View File

@@ -0,0 +1,175 @@
# Session Log — Goldstein: OpenVPN remote access + full network topology mapping
## User
- **User:** Howard Enos (howard)
- **Machine:** Howard-Home
- **Role:** tech
## Session Summary
Resumed remote-access work for Goldstein under Syncro ticket #32384 ("Remote - Issues with remote
access"). The stated goal firmed up over the session: the roaming laptop **ASUS-2024** (Michelle,
user `miche`) must be able to RDP into two machines from anywhere — **DALLAS** (192.168.1.226,
Dallas office) and **DalRes10** (10.1.10.170, Tucson office). Began by loading prior context
(#32490 Dallas RDP enablement, the June #32384 attempt) and confirming machine identities.
Mapped the entire Goldstein network from the UniFi Site Manager cloud API + connector proxy: both
sites run a UCG-Ultra (UDRULT, Network 10.4.57) that we own in our ui.com account. Established that
the Tucson↔Dallas link is a **UniFi Site Magic auto-mesh** (WireGuard-based, `wgsts1000`) that is
auto-managed/locked (`attr_no_edit`/`attr_no_delete`) and bridges **only the two corporate LANs**
(10.1.10.0/24 ↔ 192.168.1.0/24), verified working both directions. Discovered the June "WireGuard"
was actually Teleport (enabled on both gateways) plus leftover machine-level WireGuard tunnels.
Diagnosed why ASUS couldn't reach the offices: it was on the office's **separate Cox network
(SSID `Gold-Scop`, 192.168.0.0/24)**, which is not the UniFi LAN and not on Site Magic. Mike
directed switching remote access to OpenVPN. Mike disabled Teleport (I confirmed/executed the
Tucson toggle), then set up native UniFi **OpenVPN remote-user servers** on both UCGs (TCP 1194,
RADIUS auth, pool 192.168.2.0/24 on both) and created RADIUS users Michelle + Sheldon on both
gateways. I vaulted the RADIUS secret + both client `.ovpn` profiles + user creds, then deployed a
split-tunnel OpenVPN client to ASUS-2024 (OpenVPN 2.6.14) and proved the tunnel up. Testing showed
the Tucson-anchored connection reached Tucson but not Dallas — the OpenVPN pool doesn't traverse
Site Magic. After pulling the live config (as Mike requested), confirmed this is a hard Site Magic
limitation, so the offsite design landed on **two profiles** (Dallas profile → DALLAS, Tucson
profile → DalRes10), and the office design on **Site Magic with the VPN off (on the UniFi WiFi)**.
DALLAS offsite RDP was confirmed working (Michelle imported the Dallas profile). DalRes10 had been
knocked fully offline earlier in the session when someone activated its machine-level WireGuard
tunnel (full-tunnel captured its own routing; no remote path — required onsite console
deactivation, which happened ~4pm). Closed out by updating the Goldstein wiki with the complete
topology, and adding Defender exclusions for the OpenVPN config folders + confirming Defender
re-enabled on ASUS-2024. Howard is removing the DalRes10 WireGuard himself.
## Key Decisions
- **Switched remote access from Teleport/WireGuard to OpenVPN** (Mike's call). Teleport's June
failures ("steps on routes at home" = subnet overlap; "login credentials incorrect" = Ubiquiti
account / RADIUS) and the machine-level WireGuard tunnels (which took DalRes10 offline) made them
a poor fit for a roaming law-firm laptop.
- **Offsite = two OpenVPN profiles, not one-connection-both.** Pulling the live gateway config
proved UniFi Site Magic is auto-managed/locked and carries only corporate LANs — it will NOT
route the OpenVPN client pool (192.168.2.0/24) across the mesh, and there is no way to add it.
So a single offsite VPN connection cannot reach both sites. Two profiles (connect the one for the
target machine) is the working design; abandoned the earlier "de-conflict pool + advertise across
mesh" idea because Site Magic cannot be extended.
- **Office = Site Magic with VPN off.** A device on the Tucson UniFi LAN (10.1.10.x) already
reaches DalRes10 (local) + DALLAS (mesh). The catch is the laptop must be on the UniFi "Goldstein"
WiFi, not the separate Cox `Gold-Scop` network.
- **Split-tunnel OpenVPN client** (drop `redirect-gateway def1`, `route-nopull` + explicit
`route` lines) so a client can never full-tunnel itself offline the way the WireGuard tunnel did.
- **Used the vault skill for all secrets and referenced vault paths in the log** rather than
committing plaintext (pre-commit guard + vault-skill rule).
- **Did gateway config in the UI (Howard/Mike), not via raw connector writes** — after a
mid-session correction that hand-rolling the UniFi API instead of the skill is wrong; the skill
has no VPN-server command, so the server build was done in the UI.
## Problems Encountered
- **DalRes10 taken fully offline by its own WireGuard tunnel.** Activating the machine-level
`WireGuardServer1-Client1`-style tunnel installed routes that captured its network path (RMM +
ScreenConnect both went dark). WireGuard does not time out; a reboot would re-break it (auto-start
service). No remote recovery possible — required onsite console deactivation (~4pm). Resolved by
onsite visit; Howard removing WireGuard.
- **Cross-site VPN routing dead-end.** ASUS on the Tucson OpenVPN pool (192.168.2.2) reached the
Tucson gateway but not DALLAS. Root cause: Site Magic advertises only the LANs and is locked
(`attr_no_edit`), so the pool can't be carried. Both OpenVPN servers also use the same pool
(192.168.2.0/24). Pivoted to the two-profile design.
- **Corrected hand-rolling the UniFi API.** Was reading (and made one write — Teleport disable) via
raw `curl` to the connector instead of the `unifi-wifi` skill. Logged as a correction; skill's
`gw-sitemanager.sh` is the read path, but its `net … raw` truncates at 5 KB, so full networkconf
legitimately needs a direct connector read.
- **Defender ate the OpenVPN `.ovpn`** (embedded private key). Added Defender exclusions for the
OpenVPN config folders; Defender had already auto-re-enabled (tamper protection), confirmed on.
- **DalRes10 cleanup command timed out** (server-side reaper at 120s; the `wireguard
/uninstalltunnelservice` / manager-stop hung). Backed off to a read-only diagnostic; Howard then
opted to remove WireGuard himself.
- **RADIUS username mismatch** — Howard typed "michell"; the actual RADIUS account is `Michelle`.
Corrected the vaulted username to match the gateway.
- **Local `curl`/jq friction** — a `/tmp` path tripped the block-tmp-path hook; a jq filter with a
raw `C:\Program Files` path failed (invalid JSON escapes) — fixed by passing PowerShell via
`jq --arg`, not inline.
## Configuration Changes
- **ASUS-2024** — installed OpenVPN Community 2.6.14 (service OpenVPNService/Interactive); deployed
then removed a split-tunnel `goldstein.ovpn` (Howard re-imports via GUI); added Defender
ExclusionPath for `C:\Users\miche\OpenVPN`, `C:\Program Files\OpenVPN\config`,
`C:\Program Files\OpenVPN\config-auto`; created `Dallas Computer.rdp` (→192.168.1.226) on
Michelle's OneDrive Desktop + Public Desktop.
- **CGU-Goldstein Tucson (UCG)** — Teleport disabled (setting `teleport` enabled=false) via
connector write; OpenVPN remote-user server (Mike, UI). Site Magic + Dallas mesh unchanged.
- **CGU-Goldstein Dallas (UCG)** — OpenVPN remote-user server (Mike, UI); RADIUS users
Michelle + Sheldon (Mike, UI).
- **DalRes10** — WireGuard tunnel deactivated at console (onsite); Howard removing WireGuard.
- **Vault** — created `clients/goldstein/openvpn-remote-access.sops.yaml`.
- **Wiki** — rewrote `wiki/clients/goldstein.md` with full network + remote-access topology.
- **Repo** — logged one correction to `errorlog.md` (unifi-wifi hand-rolled API).
## Credentials & Secrets
- **All vaulted at `clients/goldstein/openvpn-remote-access.sops.yaml`** (do not duplicate plaintext
here — pre-commit guard + vault rule):
- `credentials.radius_secret` — shared RADIUS secret (same on both UCG built-in RADIUS servers).
- `credentials.tucson_endpoint` = 98.225.73.165:1194 tcp · `credentials.dallas_endpoint` =
99.127.21.4:1194 tcp.
- `credentials.tucson_ovpn_b64` / `credentials.dallas_ovpn_b64` — full client `.ovpn` (base64;
each embeds a client cert + private key).
- `credentials.michelle_vpn_username` = `Michelle` (NOT "michell") + `..._password`;
`credentials.sheldon_vpn_username` = `Sheldon` + `..._password`; `credentials.vpn_username`
/`vpn_password` = the Michelle primary.
- UniFi Site Manager API key: existing vault `services/unifi-site-manager` (`credentials.api_key`).
- No plaintext secrets committed.
## Infrastructure & Servers
- **CGU-Goldstein Tucson** — UCG-Ultra (UDRULT, Net 10.4.57); WAN 98.225.73.165 (Comcast/Pima);
LAN 10.1.10.0/24 (gw 10.1.10.1); dual-WAN (Internet 2 disabled); console id
`0CEA146890BF000000000885E5160000000008FA3AD6000000006741FA51:285001334`. OpenVPN server tcp/1194
pool 192.168.2.0/24; Teleport now disabled.
- **CGU-Goldstein Dallas** — UCG-Ultra; WAN 99.127.21.4 (AT&T); LAN 192.168.1.0/24 (gw 192.168.1.1);
console id `0CEA1456463900000000087729C50000000008EAA14D0000000067282B45:989250246`. OpenVPN
server tcp/1194 pool 192.168.2.0/24.
- **Site Magic** — `magic_site_to_site_vpn` enabled both sides, iface `wgsts1000`; Tucson advertises
192.168.1.0/24, Dallas advertises 10.1.10.0/24; auto-managed/locked; no static routes.
- **DALLAS** — 192.168.1.226 (Wi-Fi); Win 11 Pro for Workstations; RDP host (fDenyTS=0, NLA,
TermService Auto); RMM agent 36c7bbc8-504f-4b4a-8995-3b3e5cdc0f02; SC 29c62473-a5cb-4e94-a190-c91f05031809.
- **DalRes10** — 10.1.10.170 (Wi-Fi; also Ethernet 10.10.1.149 on a different segment); RDP host
(fDenyTS=0, NLA); TermService was **Manual** (won't auto-start after reboot — set Auto pending);
RMM agent 81cde315-013b-4acd-80d7-5ec2b9b5f084; SC a8b53a73-ff0e-42c9-b51f-4ff71aff45f7.
- **ASUS-2024** — roaming laptop (user `miche`); on Cox `Gold-Scop` 192.168.0.200/24 (gw 192.168.0.1)
when in office; RMM agent f50b17c1-a711-4e80-89c2-03cb630f5622; SC cfddaed7-b6b9-463c-b210-384dec88e0f8.
- **GS-Backup** — Tucson; RMM agent 4f52ef22-89ae-4124-a2b4-d339aaf42f53.
## Commands & Outputs
- UniFi connector read (full networkconf, skill `raw` truncates at 5 KB):
`curl -H "X-API-KEY: $KEY" https://api.ui.com/v1/connector/consoles/<ID>/proxy/network/api/s/default/rest/<networkconf|setting/<key>|routing|account>`
- Teleport disable (write via connector): `PUT …/rest/setting/teleport/<_id>` `{... enabled:false}` → `{"rc":"ok"}`.
- OpenVPN client verify on ASUS: `Get-Content 'C:\Program Files\OpenVPN\log\goldstein.log'` →
`Initialization Sequence Completed`; VPN IP 192.168.2.2; routes 10.1.10.0/24 + 192.168.1.0/24 added.
- Reachability from ASUS (Tucson-anchored tunnel): `Test-NetConnection 10.1.10.1` ping True;
`Test-NetConnection 192.168.1.226 -Port 3389` TcpTest **False** (cross-site fails via Site Magic).
- Site Magic reverse: DALLAS `Test-NetConnection 10.1.10.1` ping True (mesh healthy both ways).
- Defender: `Add-MpPreference -ExclusionPath …`; `Get-MpComputerStatus` → RealTime/Antivirus/Tamper all True.
## Pending / Incomplete Tasks
- **DalRes10 WireGuard removal** — Howard doing it manually. When done, set **TermService →
Automatic** so RDP survives a reboot.
- **Tucson OpenVPN profile on ASUS-2024** — import the `98.225.73.165` `.ovpn` (split-tunnel)
alongside the Dallas one so Michelle can RDP DalRes10 offsite (connect the Tucson profile for
DalRes10, the Dallas profile for DALLAS).
- **Office WiFi** — ensure ASUS joins the UniFi "Goldstein" WiFi (10.1.10.x) at the office, not
`Gold-Scop` (Cox), for the VPN-off / Site Magic path. (Confirm exact SSID mapping.)
- **Billing** — #32384 was already Resolved/invoiced in June; new OpenVPN work not yet billed —
confirm with Mike whether to bill.
- **Remove machine-level WireGuard on ASUS-2024** (`WireGuardServer1-Client1`, inactive) for hygiene.
## Reference Information
- Syncro tickets: #32384 (112201728) remote access (Resolved); #32490 (113249206) Dallas RDP
(Invoiced, invoice 1650967814).
- Vault: `clients/goldstein/openvpn-remote-access.sops.yaml`; `services/unifi-site-manager`.
- Wiki: `wiki/clients/goldstein.md` (updated this session).
- UniFi consoles (ui.com): CGU-Goldstein Tucson / Dallas (owner). API key `services/unifi-site-manager`.
- OpenVPN Community MSI used: https://swupdate.openvpn.net/community/releases/OpenVPN-2.6.14-I001-amd64.msi
- Prior logs: `clients/goldstein/session-logs/2026-07/2026-07-06-…` + `…-07-07-…`.