From 5d16a18cf4f72e8682e5387d31fbb6b9956db0cb Mon Sep 17 00:00:00 2001 From: Viktor Barzin Date: Fri, 3 Jul 2026 12:31:48 +0000 Subject: [PATCH] ADR-0017: document trunk traffic semantics + ASCII topology While reviewing the single-switch design Viktor asked whether both the home LAN and the camera VLAN 'go via pfSense which forwards upstream' - a natural misreading a future reader would repeat. Added a section spelling out the vmbr0 fork: untagged home LAN is L2-bridged past pfSense (gateway stays the AX6000, rack outage does not affect it, OOB via 4G survives), while tagged-30 can only land on the dCCTV interface, making a pfSense bypass impossible by construction. Includes a compact ASCII topology for terminal readers alongside the SVG. Co-Authored-By: Claude Fable 5 --- ...0017-cctv-segment-dedicated-pfsense-leg.md | 46 +++++++++++++++++++ 1 file changed, 46 insertions(+) diff --git a/docs/adr/0017-cctv-segment-dedicated-pfsense-leg.md b/docs/adr/0017-cctv-segment-dedicated-pfsense-leg.md index 7b06f0e4..3936d505 100644 --- a/docs/adr/0017-cctv-segment-dedicated-pfsense-leg.md +++ b/docs/adr/0017-cctv-segment-dedicated-pfsense-leg.md @@ -35,6 +35,52 @@ may reach ISAPI/RTSP directly; home-LAN clients route in via an AX6000 static route (10.0.30.0/24 via 192.168.1.2). 10.0.30.0/24 is deliberately NOT in the 10.0.20.0/22 trusted source-IP allowlist. +## Traffic on the trunk — how one cable carries two networks + +The LAN1 cable is shared, but the two networks on it diverge at `vmbr0` +(the vlan-aware bridge on the PVE host), and only ONE of them ever touches +pfSense: + +- **Untagged (VLAN 1, home LAN)** is plain L2 bridging: vmbr0 switches it + between the trunk, the host's own IP (192.168.1.127) and pfSense `net0` — + where pfSense sits as an ordinary LAN *client* (WAN 192.168.1.2). The home + LAN's gateway is and remains the AX6000; home-LAN traffic never transits + pfSense. Consequently a pfSense (or R730 VM-level) outage does not affect + the home LAN, and the apartment ↔ 4G-router ↔ UPS paths don't even leave + the switch (P1/P2/P3 bridge internally), so out-of-band recovery via the + 4G router survives the whole rack being down. +- **Tagged 30 (CCTV)** has exactly one possible landing: vmbr0 delivers + VID 30 only to pfSense `net3` (dCCTV, 10.0.30.1), which is the camera + segment's gateway, firewall and sole exit. "Camera → AX6000 → internet" + is impossible by construction, not merely by firewall rule. +- pfSense forwards *upstream* only its own segments (10.0.10/20/30), NATed + out of its WAN toward the AX6000. Load-wise the trunk gained only the + camera's ~8 Mbps — it already carried all rack-bound home-LAN traffic. + +```text + INTERNET ── AX6000 192.168.1.1 (home GW; camera-day route 10.0.30.0/24 → .2) + │ + │ apartment uplink · V1 untagged + ┌──────────────┴───────────────────────────────┐ ┌────────────────────┐ + │ TL-SG105PE (mgmt 192.168.1.6) │ │ vermont-garage │ + │ P1 apartment · P2 4G .7 · P3 UPS [VLAN 1] │◄───┤ HiLook, pure IR │ + │ P4 camera PoE [VLAN 30] │cat6│ 10.0.30.70 (Kea) │ + │ P5 TRUNK: V1 untagged + V30 tagged │ └────────────────────┘ + └──────────────┬───────────────────────────────┘ + │ ONE cable (existing LAN1 run) + ┌──────────────┴───────────────────────────────────────────────┐ + │ R730 · eno1 → vmbr0 (vlan-aware) │ + │ ├─ untagged → host .127 + pfSense net0 WAN 192.168.1.2 │ + │ └─ tag 30 → pfSense net3 dCCTV 10.0.30.1/24 (camera GW) │ + │ eno2 → vmbr2: dormant fallback leg │ + │ vmbr1: tag 10 → dManagementsVms · tag 20 → dKubernetes (k8s, │ + │ Frigate on node1, go2rtc LB 10.0.20.204 → HA live) │ + └───────────────────────────────────────────────────────────────┘ + + Frigate 10.0.20.x ─RTSP :554─► camera · ha-sofia .8 ─:80+:554─► camera + camera ─NTP :123─► 10.0.30.1 · camera → anything else = DENY +``` + ## Considered options - **802.1Q over the LAN path behind an UNMANAGED switch** (the original plan