viktor/infra
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 1

ADR-0017: document trunk traffic semantics + ASCII topology

Browse source 
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 <noreply@anthropic.com>
This commit is contained in:
Viktor Barzin 2026-07-03 12:31:48 +00:00
parent be80ef23bb
commit 5d16a18cf4
1 changed files with 46 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

46
docs/adr/0017-cctv-segment-dedicated-pfsense-leg.md
View file

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