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

sync: auto-sync from HOWARD-HOME at 2026-06-16 18:23:40

Browse Source 
Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-06-16 18:23:40
This commit is contained in:
Howard Enos
2026-06-16 18:23:47 -07:00
parent 0fcc270c02
commit a5e851a144
2 changed files with 15 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

29
.claude/memory/howard-home-lan-shadow.md
View File

@@ -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.