azcomputerguru/claudetools
1
0
Fork 0
Code Issues 58 Pull Requests Actions Packages Projects Releases Wiki Activity
Files
cda32b53bbe3604b2dee39b151e7f207db2345e5
claudetools/clients/goldstein/session-logs/2026-07/2026-07-10-howard-openvpn-remote-access-sitemagic.md
Howard Enos 273eb150c8 sync: auto-sync from HOWARD-HOME at 2026-07-10 17:20:37 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-10 17:20:37
2026-07-10 17:21:06 -07:00

12 KiB
Raw Blame History

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-….
Reference in New Issue View Git Blame Copy Permalink