diff --git a/.claude/memory/MEMORY.md b/.claude/memory/MEMORY.md index aabb68e..fca1f19 100644 --- a/.claude/memory/MEMORY.md +++ b/.claude/memory/MEMORY.md @@ -113,7 +113,7 @@ - [Apple MDM + Developer certs (GuruRMM mobile)](project_apple_mdm_certs.md) — ACG holds Apple Developer+signing and Apple MDM Push certs (acquired 2026-05-29) for SPEC-017. MDM push cert RENEWS ANNUALLY on the same Apple ID or all enrolled iOS devices break. - [Only RMM & GC are versionable products](project_versionable_products.md) — GuruRMM + GuruConnect are the only products with own repos/submodules; everything else stays in the claudetools monorepo. Split only for independent pipeline OR versioned external consumer. - [Quantum GoDaddy M365 tenant](project_quantum_godaddy_m365_tenant.md) — quantumwms.com parked in a GoDaddy-provisioned M365 tenant (id ddf3d2c9-b76c-40d9-a216-9f11a1a26f97, netorg18235235.onmicrosoft.com); blocks Pax8 migration until GoDaddy removed. -- [Howard-Home LAN shadow](howard-home-lan-shadow.md) — Howard-Home is 192.168.0.0/24 w/ a UniFi gateway (.0.1, cert unifi.local — NOT pfSense); collides with Cascades pfSense .0.1 so VPN can't reach Cascades .0.x. Fix: renumber home off 192.168.0.0/24 (e.g. .88/.137). /32 route can't fix (.0.1 IS home gw). +- [Howard-Home LAN shadow (RESOLVED)](howard-home-lan-shadow.md) — Howard-Home renumbered 2026-06-16 to **10.137.42.0/24** (gw 10.137.42.1, UniFi — NOT pfSense), off the old 192.168.0.0/24 that shadowed Cascades pfSense .0.x over the VPN. Cascades .0.x should now route via the tunnel; this machine is 10.137.42.x now (not 192.168.0.x). - [Cascades](project_cascades.md) — Active state: Syncro ticket #110680053 + plan file (machine-specific path on Howard's box), admin accounts (sysadmin@=Howard, admin@=Mike — daily-driver, NOT break-glass), Phase-B caregiver CA pilot (SG-Caregivers-Pilot, group-scoped never tenant-wide), prepaid block ~37.5h (rate TBD), pilot cleanup checklist. - [Cascades history](project_cascades_history.md) — fdeploy 502/ACL root cause (Flags=1211→187 fix), 2026-04-29 CA-rescoping decision (Howard pulled the brakes on tenant-wide), 2026-05-14 per-user-security-group decision rationale. - [Sync script bug — untracked files (RESOLVED)](project_sync_script_bug.md) — FIXED 2026-05-21: sync.sh now uses `git status --porcelain` for change detection (repo + vault). diff --git a/.claude/memory/howard-home-lan-shadow.md b/.claude/memory/howard-home-lan-shadow.md index cfe7650..ab56f8a 100644 --- a/.claude/memory/howard-home-lan-shadow.md +++ b/.claude/memory/howard-home-lan-shadow.md @@ -1,24 +1,23 @@ --- name: howard-home-lan-shadow -description: Howard-Home LAN is 192.168.0.0/24 (UniFi gateway), collides with Cascades pfSense — blocks VPN access to Cascades .0.x +description: Howard-Home LAN is now 10.137.42.0/24 (renumbered 2026-06-16 off 192.168.0.0/24) — Cascades .0.x VPN shadow RESOLVED metadata: type: project --- -Howard-Home is on **192.168.0.0/24**, gateway+DNS **192.168.0.1** = a **UniFi OS gateway** -(cert CN=unifi.local, "UniFi OS") — NOT pfSense. (The pfSense boxes are Cascades' and the ACG office's.) +Howard-Home LAN = **10.137.42.0/24**, gateway+DNS **10.137.42.1** (a **UniFi OS gateway**, cert +CN=unifi.local — NOT pfSense). Howard renumbered it on **2026-06-16** (was 192.168.0.0/24). -This **shadows Cascades' 192.168.0.0/24** (Cascades pfSense .0.1, NAS .0.120): when the Cascades VPN -is up (pushes route 192.168.0.0/22), the OS prefers the directly-connected local /24, so traffic to -192.168.0.1/.120 goes to Howard's home UniFi, never across the tunnel. Cascades APs (192.168.2.x/3.x) -are reachable; the .0.x hosts are not. A /32 route can't fix it — .0.1 IS Howard's own home gateway. +**Why it was changed:** the old 192.168.0.0/24 **shadowed Cascades' 192.168.0.0/24** (Cascades pfSense +.0.1, NAS .0.120). With both on the same subnet, the OS preferred the directly-connected local /24, so +Cascades-VPN traffic to 192.168.0.x went to Howard's home UniFi instead of across the tunnel (Cascades +APs on 192.168.2.x/3.x worked; .0.x did not). A /32 route couldn't fix it because .0.1 was Howard's own +home gateway. Renumbering home to 10.137.42.0/24 frees 192.168.0.0/24 to route over the VPN. -**Fix = renumber Howard-Home off 192.168.0.0/24** (UniFi Network > Settings > Networks > Default: -change host address + DHCP to e.g. 192.168.88.0/24 or 192.168.137.0/24 — avoid .0/.1/.2/.3 which ACG -clients + Cascades use). Then 192.168.0.0/24 routes via the tunnel. This unblocks the pfSense compat -layer live validation (see [[MEMORY]] / ROADMAP §E, currently ON HOLD on the pfSense upgrade too). +**Status: RESOLVED.** From Howard-Home, 192.168.0.x (Cascades pfSense/NAS) should now route via the +Cascades VPN (confirm the .ovpn still pushes route 192.168.0.0/22). This removes the home-side blocker on +the pfSense compat-layer live validation — though that work is ALSO separately ON HOLD on the Cascades +pfSense being too old to install the RESTAPI package (see ROADMAP §E / [[MEMORY]]). -**Why:** this shadow has cost time repeatedly; the pfSense work can't be live-tested from Howard-Home -until either the subnet is renumbered or testing runs from/through the Cascades network. -**How to apply:** if asked to reach Cascades .0.x from Howard-Home, expect this collision; recommend the -renumber (or run from a machine on the Cascades LAN) rather than fighting routes. +**How to apply:** Howard-Home is 10.137.42.x now — don't assume 192.168.0.x for this machine. If the +Cascades VPN still can't reach .0.x, check the ovpn route + that no other local interface re-collides.