Firewall und Netztrennung

Update 6.8. (Netze, Portdefinition, Migrationsplanung)
Update 9.8. (Mesh)
Update 12.8. (Netzwerk)
Update 13.8. (Migration sichere Geräte)
Update 17.8. (Migration IoT)
Update 21.8. (Migration Home Assistant)
Update 29.8. (MariaDB)

Bisher habe ich zuhause ein Class C Netz mit einer Fritz!Box, einem Switch und mehreren Fritz!Repeater genutzt. Darin tummeln sich mittlerweile über 70 Geräte, die prinzipiell alle Unfug anrichten könnten. Um das Netzwerk etwas zu professionalisieren und sicherer zu machen (bzw. um mal wieder zu basteln), sollten nun mehrere, per Firewall getrennte Netze aufgespannt werden. Da das mit AVM Produkten nicht möglich ist (lediglich ein Gast WLAN ohne Verbindung zum privaten LAN/WLAN), musste zuerst neue Hardware und Software her.

Hardware

Die Wahl fiel auf

einen Topton Mini PC mit N150 CPU und 4 2.5Gb LAN Ports vom Ali plus 8GB DDR5 Memory sowie 128GB NVMe aus der Bucht. Der hat etwas bessere Specs als ein Netgate 4200 zu 599$ mit 9.28Gbps Routing und 8.61Gbps Firewall und kostet weniger als die Hälfte

einen Ubiquiti U7 Pro Access Point, versorgt von einem Ubiquiti PoE+ 2.5Gb Injector zu insgesamt 195€ vom günstigsten Versender hierzulande. Das Ding soll für 140m² und 300+ User reichen, hat außerdem schon WiFi 7, für das ich noch kein einziges Endgerät habe. Die Hoffnung ist, daß ich damit auch alle Repeater loswerden kann.

pfsense

Die Erstinstallation von der pfsense Firewall Software auf dem Topton war recht einfach, erfordert aber eingesteckte Tastatur und Monitor. Der erste Netzwerkport geht auf die Fritz!Box als WAN Interface und bekommt von dort erstmal eine DHCP Adresse. Der zweite Netzwerkport wird als LAN konfiguriert. Hier muss man ein neues Netzwerk einrichten, am besten gleich mit DHCP Server. In diesem Netzwerk läuft dann nämlich die WebGUI vom pfsense, über die man dann die weitere Konfiguration machen kann.

Ubiquiti Unifi

Die Erstinstallation des U7 war schwieriger. Zunächst habe ich die UniFi Software auf meinem iPad installiert und dann versucht, mich auf das vom AP aufgespannte WLAN zu verbinden. Leider schlug das fehl, warum auch immer. Am Ende habe ich den U7 eine DHCP Adresse im LAN ziehen lassen, dann hat UniFi den U7 auch gefunden und konnte nach einem Update konfiguriert werden. Dann musste ich feststellen, daß die UniFi App nur sehr begrenzte Konfigurationsmöglichkeiten hat. Nicht ungeschickt bietet Ubiquiti erstmal einen kostenpflichtigen Cloud Dienst oder zusätzliche Management Devices an. Tatsächlich gibt es aber auch einen kostenlosen UniFi Network Server für Windows/Linux/MacOS(nur Rosetta), der wiederum ein Webinterface hat, auf das auch die App zugreifen kann. Den Server habe ich erstmal unter Windows installiert und dann im Browser weitergemacht. Den U7 musste ich dann resetten und in den UniFi Server aufnehmen. Nun stehen lokal alle Konfigurations- und Überwachungstools zur Verfügung. In einem zweiten Schritt habe ich den Unifi Server auf einer Ubuntu VM installiert, die ständig läuft. Die Konfiguration kann man sichern und wiederherstellen, was einwandfrei geklappt hat. Nun kann ich den U7 (und bald einen weiteren Ubiqiti Switch) verwalten (schon geil, für ein Heimnetz professionelle Tools zu nutzen).

LANs/WLANs

Nach diesen beiden Vorbereitungen kam die Planung der LANs/WLANs. Davon gibt es jetzt 4 Stück:

1. sicher LAN/WLAN: LAN Switches, WLAN APs, vertrauenswürdige Server, PCs, Laptops, Telefone und Tablets
2. IoT: das ganze Zeug für die Automatisierung (Sensoren, Steckdosen, Lampen, etc.) inklusive Home Assistant
3. Audio/Video: TVs, Spielkonsolen, Receiver
4. Gast: Gästehardware

Damit sind die Netze getrennt und man kann gezielt einzelne IPs/Ports für andere Netzwerke freigeben (z.B. kann die Plex App auf dem TV vom sicheren Server streamen oder die PCs auf Home Assistant zugreifen).

Konfiguration

Vorher habe ich ein Buch über pfsense gelesen und ein WBT absolviert.

Im ersten Schritt habe ich geschaut, daß das WAN Netzwerk über die Fritz!Box ins Internet kommt. pfsense hat natürlich eine feste IP Adresse auf der WAN Seite bekommen, DHCP und WLAN auf der Fritz!Box wird am Ende abgeschaltet.

Im zweiten Schritt habe ich einen Laptop an das LAN Netzwerk angeschlossen und ebenfalls sichergestellt, daß hier Internet Zugriff möglich ist. An diesen Port kommt dann der bisherige nicht managebare D-Link Switch mit PCs und Server, der später von einem managebaren Ubiquiti Switch ersetzt wird.

Am dritten Netzwerkport des Topton habe ich den U7 angeschlossen. Dieser soll ja vier verschiedene WLAN mit unterschiedlichen Netzen (VLAN) aufspannen und von pfsense entsprechend gerouted werden. Das war aber nicht so einfach. Normalerweise ist am LAN Port ein Switch dran, so dass sich alle Geräte sehen können. Da ich aber keinen freien Switch habe und die beiden übrigen Topton Ports auch gerne nutzen würde, habe ich den LAN Port und die beiden übrigen als Bridge konfiguriert. Das soll man zwar nicht machen, weil dann ein paar Funktionen von pfsense nicht gehen, aber darauf verzichte ich erstmal. Die Bridge hat nach ein paar Versuchen tatsächlich funktioniert (einmal habe ich mich komplett ausgesperrt und musste über die Konsole den LAN Port resetten) und wird zu dem sicheren Netzwerk. Nachdem der Laptop im sicheren Netzwerk und der Ubiquiti Server gestartet war, habe ich den AP in den dritten Port eingesteckt und zurückgesetzt. Nach ein paar Minuten hat er sich im Ubiquiti Server gemeldet und konnte konfiguriert werden. Das erste WLAN (sichere Geräte) wurde nativ eingerichtet, hat sofort funktioniert und Internetzugang gehabt. Damit sind die sicheren Geräte im LAN und WLAN im selben Netz, praktisch wie bisher auch. Dann mussten auf dem AP drei virtuelle Netze eingerichtet werden, die dann als WLAN mit VLAN Tagging laufen für sichere Geräte, IoT und Gäste. Das ging erfreulicherweise auf Anhieb (VLANs und DHCP Server wurden vorher auf pfsense eingerichtet). Damit die Clients in den VLANs keinen Unfug anrichten können und ins Internet kommen, mussten noch ein paar Firewall Regeln definiert werden. Das war recht einfach.

Nach diesen drei Schritten (2 Tage Bastelei) und einem pfsense Update war die Vorbereitung beendet und ich konnte zur Migrationsplanung übergehen.

Die Bridge habe ich wieder gelöscht, weil sie praktisch keinen Vorteil bietet. Über Firewall Regeln kann man ohne Probleme auch einen einzelnen Port des Topton nutzen. Solange ich den unmanaged D-Link Switch nutze, gehen die Geräte über das LAN Interface, LAN2 Interface ist aktuell frei und den dritten Port habe ich WLAN genannt und dort den AP angeschlossen, der die VLANs über WLAN anbietet.

Die Firewall Regeln habe ich auch überarbeitet. Sicherer ist es, allen Traffic zu verbieten und für das erlaubte Regeln zu machen. Damit sieht man auch, wo der Verkehr langläuft. IoT und Gast waren am einfachsten, alles ist erlaubt, was nicht interne Netze sind. Für AV genauso, nur daß hier noch der Zugriff auf den internen Plexserver:Port, Roonserver:Port erlaubt ist. Zu beachten ist, daß man keinen internen DNS verwendet (lokaler pi-hole) oder den Zugriff darauf explizit freigibt. Intern interessiert mich Gast nicht, die Geräte können ruhig Werbung anzeigen.

Für Gast habe ich eine Weile vergeblich versucht, das pfsense Captive Portal zu nutzen. Da muß ich noch etwas dran arbeiten. Das ist nämlich eine schicke Lösung, um statt ein WLAN Kennwort zu verraten, einen Login Screen zu haben und später die Zugriffe protokollieren.

Ausserdem habe ich den fliegenden Testaufbau der beteiligten Geräte (keines rackmountable) in eine aufgeräumte Tafel überführt (ein Hager Multimediaschrank wäre das Optimum, dafür habe ich aber weder Geld noch Platz. Ein 10″ Netzwerkschrank käme günstiger, dort wären die Geräte aber übereinander auf Einschubböden und 30cm Tiefe stört in der Wohnung).

Migrationsplanung

Die AV Geräte waren am einfachsten zu migrieren und sind jetzt getrennt vom sicheren Netz. Die Freigaben für Plex und Roon haben sofort funktioniert, per Alias kann man sofort auf Serveränderungen (bei der anstehenden Migration) reagieren.

Sichere mobile Endgeräte sind genauso einfach zu migrieren und haben vollen Zugriff auf die bestehenden Services.

IoT ist mehr Aufwand, weil ich jedes Gerät einzeln in das neue IoT WLAN bringen muß (Steckdosen und Thermometer per Handy anlernen, ESPs neu flashen, etc.). Das wird vermutlich einen Tag dauern.

Meine Serverinfrastruktur ist ebenfalls ein dicker Brocken. Nicht nur die Server brauchen eine neue IP Adresse, auch die VMs sind anzupassen. Die Container sollten kein Problem sein, da sie die IP Adresse vom Host bekommen. Die PCs gehen auch problemlos, da hat nur einer eine feste IP im LAN. Der Switch ist eh dumm und wird von der Fritz!Box in den Topton umgesteckt. Dann läuft halt kein Internet auf den Geräten, solange die IPs nicht umgestellt sind. Wenn ich nochmal Ports brauche, kommt ein neuer managbarer Switch her, den könnte ich dann für eine Migration (oder parallele Nutzung) auf den freien Topton Port stecken.

Am Ende würde ich DHCP und WLAN auf der Fritz!Box abschalten, genauso wie alle Fritz!Repeater. Der Empfang im Haus ist fast überall deutlich besser (eine Ecke in der Waschküche hat keinen Empfang, da darf man halt keine intelligente Waschmaschine hinstellen). Kritisch ist der Empfang im Gym im Nebengebäude. Da die Fritz!Repeater nur eine SSID weiterleiten, habe ich in der Bucht noch einen gebrauchten Ubiquiti U6 Lite AP für den halben Preis geschossen, der dann alle 4 WLAN dorthin bringt.

Den U6 AP habe ich nur mit einem zusätzlichen Switch ordentlich konfiguriert bekommen. Die Adoption per Mesh ist immer wieder abgebrochen, obwohl ich >10 Minuten gewartet habe. Nachdem er per LAN Kabel im selben Netz wie der U7 AP war, ging es auf Anhieb. Die DHCP Adresse des U6 wurde auf statisch umkonfiguriert und der Haken bei Mesh Master gelöscht. Dann konnte ich das Kabel (und Switch) wieder abziehen und den AP an den Ort des Fritz!Repeaters bringen. Jetzt ist im Gym und Hof ordentlich WLAN mit allen 4 SSIDs.

Den Ubiquiti Flex 2.5G Managed Switch (8×2.5Gb + 1x10Gb Ports) habe ich schneller als erwartet bestellen und in Betrieb nehmen müssen. In meinem Szenario macht es keinen Sinn, mehrere LAN Ports auf der pfsense zu betreiben. Also gehen alle Netze auf den LAN Port und von da auf den 2.5G Switch. Daran hängen der U7 AP und alle 2.5Gb Endgeräte sowie der 10Gb Proxmox VE Server. Der TP-Link TL-SG605E Managed Switch (5x1Gb Ports, wird gegen einen Ubiquiti Flex mini getauscht, wenn ich wieder 30€ übrig habe) ist ebenfalls am 2.5GB Switch angeschlossen. Damit habe ich für Endgeräte noch 5×2.5Gb und 3x1Gb frei, plus 2×2.5Gb auf der pfsense im Notfall. Der U6 AP ist per Mesh verbunden und wird nur bei Bedarf per LAN angeschlossen.

Migrationsbericht

Bei den meisten sicheren Geräte im LAN und WLAN waren nur Kabel umzustecken oder die SSID zu ändern. Am Ende habe ich noch die IP Adresse der Bridge im Proxmox Server geändert und rebootet. Dann wurde das LAN Kabel in den neuen Switch gesteckt und der Zustand überprüft. Dank virtueller Console konnte ich bei den VMs und Containern mit statischen IP Adressen diese ändern, die anderen waren automatisch über DHCP erreichbar. Nur Roon Rock ist im Nirwana, denn dort lässt sich die statische IP Adresse nur über das Webinterface ändern, was nicht mehr erreichbar ist. Den muss ich neu installieren und dann das Backup einspielen (hat tatsächlich funktioniert).

Nach der Proxmox Server Migration konnte ich den alten D-Link Switch abschalten, den gibts demnächst in der Bucht zu ersteigern. Die Frixtender Antennen habe ich auch von der Fritzbox abgebaut, das alte WiFi brauche ich bald nicht mehr. Die haben tatsächlich einiges gebracht, der Empfang über die Fritzbox ist deutlich schlechter (nicht nur, weil auch 2 Repeater bereits deaktiviert wurden).

Der LaserJet hat sich geweigert, sich im WPA2+WPA3 WiFi anzumelden. Also habe ich das IoT Netz auf WPA2 eingestellt (vorher hatte ich es schon auf 2.4GHz beschränkt), dann hat er dort seine neue Heimat gefunden.

Die erste Steckdose ist auch in das IoT Netz verschoben worden, der Rest folgt bald. Immerhin weiß ich schonmal, daß das neue Netz 40W verbrät. Den alten Wert habe ich nie gemessen, weil die Geräte verteilt waren, vermutlich aber nur geringfügig weniger.

Es ist eine mühselige Angelegenheit, jede Steckdose einzeln zu resetten und neu ins WLAN aufzunehmen. Dabei schaltet sich die Dose auch ab, d.h. es gibt Downtime, die eingeplant werden muß. Die Tuya Integration in Home Assistant geht über die Cloud, d.h. hier steht alles wieder zur Verfügung, wenn der Home Assistant Server im alten Netz bleibt. Bei TP-Link redet der HA direkt über WLAN mit der Dose, d.h. er hat im alten Netz keine Verbindung zur Dose. Also musste ich den HA in das neue IoT Netz bringen, damit alle Dosen wieder sichtbar sind. Das hat zwei Stunden gedauert, aber jetzt bin ich mit der Migration durch.

Die Schalttafel war nicht das Optimum, ein selbstgeschnitztes Regal ist praktischer. Dem Topton musste ich noch einen Lüfter spendieren (von 60° auf 40° bei niedrigster Drehzahl), die Kühlrippen allein bringen wenig. Der Switch wird auch ordentlich warm, der sieht aber keine zusätzliche Kühlung vor.

Am Ende der IoT Migration habe ich auch noch den Home Assistant Server auf einer VM neu installiert. Mit dem alten HA hatte ich das Problem, daß ich mit der alten Solarman Integration von Stephen Joubert unterwegs war und das Update auf die neue Integration von David Rapan derart fehlgeschlug, dass ein Wechsel nicht mehr möglich war. Also war Backup und Restore leider keine Option, da ich unbedingt die neue Integration nutzen will (kann nämlich auch Register des Wechselrichters beschreiben, also z.B. Batterie im Winter bei wenig Sonne ein- und ausschalten). Deshalb habe ich die nötigen Integrationen frisch installiert und dann die Geräte vom alten auf den neuen HA verschoben. Das IoT Netz hat noch eine Firewall Regel für MQTT gebraucht, dann konnten diese Geräte auch mit dem HA reden. Danach konnte ich die einzelnen Seiten kopieren, nur beim Wechselrichter musste ich alle Entities umbenennen. Ein paar alte Dinge habe ich gleich aufgehübscht und verschlankt, damit es übersichtlicher wird. Der alte HA Server läuft noch weiter, da erstens dort die Historie noch im Zugriff ist und zweitens der Batteriemonitor und Eastron Stromzähler per Kabel dranhängen. Diese Daten sind momentan nicht wichtig, aber in Zukunft werde ich sie von einem HA auf den anderen HA schicken, sobald ich herausgefunden habe, wie das geht [Nachtrag: ich habe mir die relevanten Sensoren über eine InfluxDB Verbindung eingerichtet. Das geht nur händisch über sensor.yaml und erst nach einem gefühlten Dutzend Reboots waren die gewünschten Batteriemonitor- und Eastrondaten alle da.]. Die Migration hat einen Arbeitstag gekostet, jetzt ist alles hübsch. Jetzt könnte ich natürlich das Backup von der VM auf den Server zurückspielen und die Modbus/Batterie-Integration nachinstallieren, dann wäre die neue Installation auf Hardware und die alten Daten per Restore in einer VM verfügbar. Allerdings ist die VM schneller als der alte Celeron, also lasse ich es erstmal so. Eventuell lege ich auch den Celeron still und nutze einen Raspi für Modbus und Seriell, der dann weniger Strom braucht.
Einige Tage später ist mir aufgefallen, daß die Verbindung zur MariaDB vom PC aus nicht mehr möglich ist, selbst wenn man die IP Adresse zur Datenbank anpasst. Das Internet hat nicht direkt die Lösung parat gehabt, das liegt nämlich nicht an den .cnf Konfigurationsdateien. Bei der Installation von MariaDB wird der User ‚root’@’192.168.1.%‘ angelegt, d.h. der darf sich nur innerhalb des Subnets anmelden. Da sich das Subnet auf 192.168.2.% geändert hat, muß der User entsprechend umbenannt werden (oder einen neuen User mit @’%‘ anlegen, der von überall drauf darf).