Kommunikations- und Flow-Refresh¶

Stand: 2026-05-25

Quelle: Read-only UniFi API, Proxmox/LXC ss-Auszug und bestehende App-Level-Discovery. Rohdaten liegen lokal unter .backups/full_dependency_refresh_20260525_191626 und werden nicht committed.

UniFi API Sichtbarkeit¶

Bereich	Ergebnis
UniFi Classic API	Netze, WLANs, Portprofile, Portforwards, Clients, Geräte und Site-Reports lesbar
UniFi Firewall-Regeln	Classic `rest/firewallrule` und `rest/firewallgroup` liefern aktuell keine klassischen Regeln
UniFi Flow-/Firewalllogs	getestete Endpunkte fuer `firewalllog`, `fwlog`, `ips/event`, `event` und `vpn` liefern keine verwertbaren Flowlogs
UniFi Sessions	`stat/session` liefert Client-/Association-Sessions, keine 5-Tuple-Verbindungsfluesse
Verwertbare Extern-nach-Intern-Sicht	Portforward-/UPnP-Tabelle mit Paket-/Bytezaehlern
Temporaeres Logging	Portforward-Logging wurde am 2026-05-25 nach Freigabe fuer alle validen direkten Portforwards aktiviert

Konsequenz: Externe Zugriffe sind ueber NAT/Portforward-Ziele sichtbar. Echte VPN-/Inter-VLAN-Flows muessen entweder ueber Gateway-Logging/Syslog, Traffic Identification/IDS-Exports oder temporaere Firewall-Log-Regeln erfasst werden.

Temporaere Logging-Aenderung 2026-05-25¶

Backup-/Rollback-Ablage: .backups/unifi_temp_logging_20260525_193154

Geaendert wurde ausschliesslich das Feld log an bestehenden Portforward-Objekten. Es wurden keine Ziel-IPs, Ports, Interfaces, VLANs, Firewall-Regeln oder Portprofile geaendert.

Portforward	Internes Ziel	Vorher	Nachher
NGINX Reverse Proxy WAN	`10.0.0.5:80,443`	`false`	`true`
NGINX Reverse Proxy WAN2	`10.0.0.5:80,443`	`false`	`true`
NGINX Reverse Proxy WAN3	`10.0.0.5:80,443`	`false`	`true`
Plex manuell	`10.0.0.30:32400`	`false`	`true`
KevConaxExile	`10.244.0.2`	`true`	`true`
KevPleskDedi	`10.244.0.15`	`false`	`true`
Radius_Lanstyle	`10.0.0.251:2083`	`false`	`true`
Hardcoreracers	`10.254.0.2`	`false`	`true`
Lanstyle-HR-SSH	`10.252.0.134:22`	`false`	`true`
Lanstyle-HR-Webinterface	`10.252.0.134:3000`	`false`	`true`

Ein unvollstaendiger/ungenannter API-Datensatz ohne name, fwd und dst_port wurde bewusst nicht veraendert.

Rsyslog war bereits aktiv und zeigt auf Wazuh 10.0.0.7:514 mit log_all_contents=true. Wazuh lauscht auf UDP 514; direkt nach Aktivierung wurden in den geprueften Wazuh-Dateien noch keine UniFi-Firewall-/Portforward-Logzeilen gesehen. Fuer belastbare Treffer muessen nun externe Zugriffe beobachtet oder gezielt getestet werden.

Rollback: Die urspruenglichen Objekte liegen je Portforward unter .backups/unifi_temp_logging_20260525_193154/rollback/portforward_<id>_before.json und koennen per UniFi API wieder auf den vorherigen Zustand gesetzt werden.

Beobachtungs-Collector¶

Das Skript scripts/unifi-flow-observe.sh sammelt reproduzierbar:

UniFi Portforward-/UPnP-Zaehler,
UniFi Syslog-/Health-/Endpoint-Status,
getestete Firewall-/Event-Endpunkte,
Wazuh Archive-/Firewall-Tail mit UniFi-relevanter Filterung.

Aufruf nur mit temporaerem API-Key aus Vaultwarden/Session-Umgebung:

UNIFI_API_KEY=... scripts/unifi-flow-observe.sh

Der API-Key wird nicht in Dateien geschrieben. Ergebnisse landen unter .backups/unifi_flow_observe_<timestamp> und werden nicht committed.

Syslog-Pfadtest 2026-05-25: Ein Test-Syslog-Paket von Proxmox an Wazuh 10.0.0.7:514 wurde in /var/ossec/logs/archives/archives.log gesehen. Damit ist Wazuh-Syslog-Empfang grundsaetzlich funktionsfaehig; fehlende UniFi-Zeilen liegen nicht am UDP-514-Empfang selbst.

Collector-Test 2026-05-25: Portforward-Zaehler steigen nach externen Zugriffen sichtbar an, aber der Wazuh-UniFi-Filter blieb leer. Damit sind Portforward-Zaehler aktuell die verlaesslichste API-Sicht fuer Extern-nach-Intern; echte Firewall-Logzeilen muessen weiter ueber UniFi-/Gateway-Logpfade geklaert werden.

UDM Shell Read-only 2026-05-25¶

Zugriff: SSH auf UDM 10.0.0.1 funktioniert mit root; admin wurde getestet und war nicht erfolgreich. Es wurden ausschliesslich lesende Befehle ausgefuehrt (ip, ss, conntrack, iptables-save). Das Passwort wird nicht gespeichert und nicht dokumentiert.

Rohdaten liegen lokal unter .backups/udm_shell_readonly_20260525_195607 und werden nicht committed.

Bestaetigte Gateway-/Routing-Sicht¶

Bereich	Befund
Alt-LAN	`br0 10.0.0.1/20`
IoT alt	`br4 10.0.102.1/24`
Hauck alt	`br5 10.99.0.1/24`
Ziel-VLANs	`br10`, `br20`, `br30`, `br40`, `br50`, `br60`, `br70`, `br100`, `br110`, `br120`, `br130`, `br140`, `br150`, `br160`, `br170`, `br180`, `br220`, `br230-239`, `br250` mit jeweiligem `10.222.x.1/24` aktiv
AI-VLAN	`br70 10.222.70.1/24` ist auf dem Gateway aktiv; fruehere ICMP-Unsicherheit aus Alt-/PVE-Pfad ist damit nicht mehr als VLAN-Anlage-Blocker zu werten
Starlink/Backup-Pfad	`br301` link-local, Teltonika/5G-Netz `eth1 10.255.3.2/29`, Teltonika-Gateway `10.255.3.1`
OpenVPN	`tun1 10.10.10.1/24`
Site-Magic/WireGuard	`wgsrv1 10.245.0.1/29`, mehrere `wgsts*` Interfaces im Bereich `192.168.7.x`, `wgclt1 10.71.201.94/32`
Zusaetzlicher VPN Client	`tunovpnc1 10.100.0.2/20`

Gelernte Remote-/VPN-Routen¶

Diese Routen muessen vor jeder Default-Deny-Firewall-Umstellung in die Projekt-/Kundenmatrix:

10.1.0.0/24, 10.1.1.0/24, 10.2.0.0/20, 10.3.0.0/22, 10.4.0.0/24, 10.5.0.0/24, 10.6.0.0/24, 10.7.0.0/24, 10.27.0.0/24, 10.64.0.0/22, 10.64.2.254/32, 10.64.4.0/22, 10.64.8.0/22, 10.64.12.0/24, 10.64.16.0/24, 10.128.0.0/24, 10.128.8.0/24, 10.128.16.0/24, 10.255.6.0/24.

Conntrack-Snapshot¶

Der UDM-Conntrack-Snapshot liefert jetzt echte 5-Tuple-Sicht. Erste auffaellige Verbindungen:

Flow	Bedeutung
`10.0.0.52 -> 10.0.102.150:80`	LAN zu Go-e Charger/Wallbox; bei Ziel-VLAN `170` fuer Gebaeudetechnik einplanen
`10.64.0.16/18/210 -> 10.0.0.187:443`	Remote-/Site-to-Site-Zugriffe auf zentrale Standort-/VPN-Verwaltung; Ziel eher Server/Management statt lokales Aruba-Thema
`10.27.0.1 -> 10.0.12.85:7442`	Remote-Standort zu lokalem UniFi/Protect-/Geraetepfad; vor Client-/Kamera-Trennung klaeren
`10.0.0.74 -> 10.254.0.1:7442`	Alt-LAN zu Legacy-Projektsegment; projektweise pruefen
`10.255.3.2 -> 1.1.1.1/8.8.8.8`	Teltonika/5G-Backup-WAN Health/DNS/ICMP bestaetigt
viele `10.222.x.1 -> 233.89.188.1/255.255.255.255:10001`	UniFi-Gateway-Discovery/Broadcasts aus neuen Ziel-VLANs, nicht als produktiver Client-Flow werten

iptables-save zeigt, dass fuer Portforward-Logging NFLOG-Regeln vorhanden sind. Da Wazuh trotzdem keine passenden UniFi-Zeilen sieht, ist der naechste Beobachtungspfad UDM-Shell/Conntrack statt Wazuh-Syslog.

Zweiter Conntrack-Snapshot 2026-05-25 20:15¶

Quelle: scripts/udm-flow-snapshot.sh, Rohdaten lokal unter .backups/udm_flow_snapshot_20260525_201503.

Der zweite Snapshot bestaetigt die kritischen Linien aus dem ersten Lauf und ergaenzt weitere konkrete Abhaengigkeiten:

Flow	Einordnung	Migrationswirkung
`10.64.0.x -> 10.0.0.187:443`	mehrere Site-to-Site-/Remote-Clients zu Aruba NetEdit	`Aruba-NetEdit` bleibt Management/Remote-Service; Ziel-Firewall aus Remote-Netzen explizit erlauben
`10.27.0.1 <-> 10.0.12.85:7442/7447`	sehr aktiver Pfad zu `UP AI Port`	AI-Hardware nicht migrieren, bevor Remote-/UniFi-/Geraetepfad geklaert ist
`10.0.0.52 -> 10.0.102.150:80`	wiederholt bestaetigt, LAN/SolarManager zu Go-e Charger	Ziel: SolarManager/Steuerlogik zu Gebaeudetechnik `170` erlauben und Ziel-IP im SolarManager nachziehen
`10.0.10.128 -> 192.168.1.217:502`	HAxStein zu Modbus/TCP-Ziel	HAxStein-Migration braucht Freigabe SmartHome `160` zu diesem Modbus-Ziel
`10.0.10.128 -> 192.168.1.162:502/udp`	HAxStein zu weiterem Modbus-Ziel	Ziel/Route klaeren, vermutlich Solar/Wechselrichter/Zaehler
`10.0.0.105 -> 10.0.102.149:52432`	AppleTV Wohnzimmer zu Meross-Steckdose	HomeKit-/mDNS-/IoT-Pfad zwischen Medien `150`, SmartHome `160` und IoT `130` testen
`10.0.10.12 -> 192.168.111.7:135/445/49678`	SMS-MGMT zu Windows/SMB/RPC-Ziel	bleibt Lab/Test/Management-Sonderfall, nicht in Phase 3 produktiv uebernehmen
`10.0.10.12 -> 10.239.40.180/192.168.113.59:7680`	SMS-MGMT zu privaten Remote-Zielen	Lab/Test, vor Segmentierung isolieren oder bewusst routen
`10.0.0.73/74 -> 10.254.0.1:7442`	Alt-LAN zu Legacy-Projektsegment	Projektsegment `254` separat behandeln
`10.0.0.9 -> 1.1.1.1:53`, `10.0.0.9 -> public:8883`	UNAS Pro DNS/Cloud/MQTT	Storage-Migration braucht DNS/HTTPS/MQTT-Outbound

Bewertung fuer Phase 3: Diese neuen Flows betreffen vor allem SmartHome, AI-Hardware, Remote-/Projektsegmente und Lab. Sie blockieren die Monitoring-Vorbereitung nicht, erhoehen aber die Stop-Kriterien fuer AI-/SmartHome-/Endgeraete-Migrationen.

UDM Beobachtungs-Snapshot¶

Das Skript scripts/udm-flow-snapshot.sh sammelt die UDM-Sicht reproduzierbar read-only:

Interfaces, Routen und Policy-Rules,
Listener,
iptables-save fuer NAT/Filter,
conntrack -L -o extended,
aggregierte Flow-Klassen und interessante Inter-Segment-Flows.

Aufruf nur mit temporaerem Passwort aus Vaultwarden/Session-Umgebung:

UDM_PASSWORD=... scripts/udm-flow-snapshot.sh

Das Passwort wird nicht in Dateien geschrieben. Ergebnisse landen unter .backups/udm_flow_snapshot_<timestamp> und werden nicht committed.

Aktuelle Extern-nach-Intern-Freigaben¶

Name	WAN/Ziel-IP	Ports	Ziel intern	Beobachtung
NGINX Reverse Proxy	WAN/WAN2/WAN3, `any`	`80,443` TCP/UDP	`10.0.0.5`	aktiv, Hauptpfad fuer veroeffentlichte Dienste
Plex	WAN `any`	`32400` TCP/UDP	`10.0.0.30`	manuelle Freigabe zeigt nur geringe Zaehler; Ziel pruefen, da Plex selbst auf `10.0.0.190` laeuft
UPnP Plex	dynamisch	`13612-13614` TCP	`10.0.0.190:32400`	Plex UPnP aktiv
UPnP Plex	dynamisch	`17633` TCP	`10.0.12.206:32400`	unklarer WLAN-Client mit Plex-UPnP, klaeren
KevConaxExile	`80.155.133.62`	`27015,7777,7778` TCP/UDP	`10.244.0.2`	Projekt-/Legacy-Segment, aktiv mit hohen Zaehlern
KevPleskDedi	`80.155.133.61`	`1-21,23-1192,1195-64999` TCP/UDP	`10.244.0.15`	sehr breite Freigabe, separat behandeln
Radius_Lanstyle	WAN `any`	`2083` TCP	`10.0.0.251`	aktiv mit hohen Zaehlern; gehoert in Core/Radius-Plan
Hardcoreracers	`80.155.133.60`	`8766,27015,27016` UDP	`10.254.0.2`	Projekt-/Legacy-Segment
Lanstyle-HR-SSH	`91.24.108.62`	`22` TCP/UDP	`10.252.0.134`	Projekt-/Legacy-Segment, aktiv
Lanstyle-HR-Webinterface	`91.24.108.62`	`3000` TCP/UDP	`10.252.0.134`	Projekt-/Legacy-Segment, aktiv

Aktive LXC-Verbindungen¶

Quelle	Ziel	Bedeutung fuer Migration
Prometheus `10.0.0.137`	`10.0.0.200:9130`	Docker-Lanstyle/unpoller wird gescraped; Ziel-FQDN fuer Monitoring vorbereiten
Prometheus	PVE Exporter `10.0.0.138:9221`	bekannte Monitoring-Abhaengigkeit; zusammen migrieren
NPM `10.0.0.5`	Gitea `10.0.1.251:3000`	NPM-Backend aktiv; vor Gitea-Migration umstellen
HKKNX `10.0.0.231`	Busch Control Touch `10.0.0.59:3671`	KNX/IP-Freigabe SmartHome zu Gebaeudetechnik/KNX einplanen
HKKNX `10.0.0.231`	`172.104.224.45:8092`	externe/Cloud- oder Relay-Verbindung; fachlich klaeren
Tautulli `10.0.0.181`	Plex `10.0.0.190:32400`	Mediengruppe gemeinsam behandeln
Plex `10.0.0.190`	Synology `10.0.0.30:5000`	Storage/NAS-Abhaengigkeit bestaetigt
Plex `10.0.0.190`	Wallboxen `10.0.0.65/66:8888`	ungewoehnlich; vor Medien-/Gebaeudetechnik-Trennung klaeren
Plex `10.0.0.190`	iLO HPE `10.0.0.210:80`	ungewoehnlich; vor Medien-/Management-Trennung klaeren
Plex `10.0.0.190`	externe Plex-Clients/Cloud	Remote-Streaming/Relay-Verhalten beachten
Paperless-Instanzen	localhost Redis/Postgres	lokal gekoppelt; VLAN-Wechsel betrifft vor allem NPM/SMTP/DNS
Wazuh	localhost OpenSearch `9200`	lokal gekoppelt; Agenten/Enrollment bleiben separat offen
Umlautadaptarr	externe HTTPS-Ziele	Internet/HTTPS erlauben, keine interne VLAN-Abhaengigkeit gesehen

Geräte und Dienste mit Restunklarheit¶

Objekt	Befund	Naechster Schritt
`10.0.12.206`	WLAN-Client mit UPnP Plex `32400` auf externem Port `17633`	Besitzer/Geraet klaeren; UPnP-Regel vor Migration bewerten
`10.0.0.232`	Proxmox-MAC, sehr wenig Traffic; weiterhin in DHCP/PXE-Optionen als FOG/iPXE-Ziel sichtbar	wenn FOG/iVentoy ausgemustert wird, DHCP-Bootoptionen gezielt entfernen
`10.0.0.16`	Wazuh-Kurzscan zeigte harte Referenz	Wazuh-Konfiguration/Agentenliste gezielt pruefen
`10.0.0.238`	Paperless-AI bis2024 laeuft, aber Export zeigte leere `PAPERLESS_API_URL`	am Ende separat klaeren
`10.0.0.210`	iLO HPE, Plex-Verbindung auf HTTP `80` sichtbar	klaeren, ob Plex/Scan/Fehlerkennung oder echter Zugriff
`10.0.0.65/66`	Juice Charger, Plex-Verbindungen auf `8888` sichtbar	klaeren; SolarManager-Zielanpassung bleibt Pflicht
Projektsegmente `10.244/10.252/10.254`	aktive Portforwards von extern	nicht automatisch migrieren; projektweise Firewall/NAT pruefen

Sofortige Planungsauswirkung¶

UPnP ist fuer die Migration ein Risiko, weil dynamische externe Freigaben Ziel-IPs umgehen koennen. Vor Segmentumstellung sollte entschieden werden, ob UPnP deaktiviert oder streng auf Mediengeraete begrenzt wird.
NPM bleibt der zentrale kontrollierte Publikationspfad; direkte WAN-Forwardings zu Projekt-/Legacy-Segmenten werden separat behandelt.
Monitoring darf erst migriert werden, wenn 10.0.0.200:9130 als Ziel fuer Prometheus eingeplant ist.
SmartHome/Gebaeudetechnik braucht zusaetzlich zu mDNS gezielte KNX/IP- und Hersteller-/Cloud-Freigaben.
Fuer echte VPN-/Inter-VLAN-Flowanalyse reicht Portforward-Logging nicht aus. Dafuer waeren Gateway-seitige Firewall-Log-Regeln, Syslog-Auswertung oder Traffic-/IDS-Exports noetig; das muss separat und mit Rollback geplant werden.