1.5 KiB
name, description, metadata
| name | description | metadata | ||
|---|---|---|---|---|
| howard-home-lan-shadow | Howard-Home LAN is 192.168.0.0/24 (UniFi gateway), collides with Cascades pfSense — blocks VPN access to Cascades .0.x |
|
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.)
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.
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).
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.