Setup VLANs (vor allem für 2 WLANs)?

[besterino]

Irgendwie fehlt mir hier ein "Laber-Thread", wo man mal relativ unauffällig dumme Fragen stellen kann...

Gibt's aber nicht, also muss ich mich outen und meine dumme Fragen in einem eigenen Thread stellen. Ich habe bisher um VLANs einen weiten Bogen gemacht, vor allem, weil ich sie - zumindest meiner Meinung nach - nicht brauchte. Nun bin ich aber dem Smart Home Wahn verfallen und habe diverse Geräte, die jetzt in meinem ganz normalen 08/15 WLAN hängen. Nun würde ich aber diese Geräte bzw. mein ganzes Smart Home Geraffel gerne in ein eigenes, separates Netz bringen. (Bonus-Überlegung: Wenn ich schon dabei bin, kann ich bei der Gelegenheit eigentlich auch (endlich) ein eigenes Management Netz aufziehen - ist aber Prio 2b).

Ich kann gerade irgendwie mein Ei nicht legen.

Zum einen stelle ich mir die Frage, wie ich am einfachsten ein separates WLAN fürs Smart Home aufziehe, nennen wir es mal "IoT-Netz". Aktuell wird das WLAN stumpf von einer Fritzbox gesteuert. Daran hängen zwei Fritz-"APs" (1750E) und zwei Ubiquity UAP-AC-Pro, die halt zusammen das heutige WLAN aufspannen.

Zum anderen habe ich hinten am Backbone diverse Geräte, die zum einen mit dem Smart Home Geraffel kommunizieren müssen, zum anderen aber auch von meinem normalen Netz (nennen wir es "Heimnetz" aus zugänglich sein müssen. Bestes Beispiel wäre vermutlich die Home Assistant VM, die eben über das IoT-Netz die ganzen Geräte steuern muss, auf die aber andererseit auch für die Clients erreichbar sein muss.

Zentraler Switch ist ein Aruba 1930, der auch VLANs kann. Alle APs (Fritz wie Ubiquity) hängen entweder direkt an diesem Switch oder könnte ich direkt dran hängen. Die sonstigen Geräte hängen allerdings zum Teil auch an dummen "nicht-VLAN fähigen" Switches.

Was mach ich am besten & geht das idealerweise, ohne neue Hardware anzuschaffen bzw. zusätzliche Stromverbraucher?

 

[underclocker2k4]

VLANs ohne Routing dazwischen bringt nix. (dann hast du mehrere Netz, die aber nicht miteinander sprechen können, maximal Security, keine Funktion)
VLANs mit Routing sind einfach nur frei mit einander verbundene Netzbereiche (Netze) die frei miteinander kommunizieren können, zumindest alles was auf >=L3 arbeitet.
VLANs mit Abkapselung brauchen eine Komponente, die in der Lage ist, die Kommunikation auf dem ein oder anderen Weg zu reglementieren.
ACLs auf IP-Basis können eben nur IP1<->IP2 ja oder nein, unabhängig des genutzten Dienstes (SMB, HTTP...)
ACLs auf Port Basis können zumindest gewisse Dienste voneinander Unterscheiden und somit reglementieren.
Eine Firewall kann von L2-L7 (je nachdem) reglementieren.

Sprich VLANs alleine bringen nur ein andere Netzstruktur, aber sonst erstmal garnix.

 

[IronAge]

Mehrere SSID/WLAN, Layer 2 Isolation & Whitelist mit den Ubiquiti, Fritzbox und sowieso AVM AP sind nicht so wirklich das passende Equipment.

 

[Eye-Q]

Ohne zusätzlich Hardware anzuschaffen wird das nichts, Du brauchst mindestens einen Router, der VLAN kann und auch eine eingebaute Firewall hat, das haben aber VLAN-fähige Router für den Heimgebrauch in der Regel. Da Du schon Ubiquiti-APs hast, wäre es meines Erachtens nach sinnvoll, auch einen Ubiquiti-Router einzusetzen, dann hast Du zumindest alle Ubiquiti-Geräte in einer Weboberfläche vereint und brauchst nicht auf fünf Weboberflächen, um ein weiteres VLAN hinzuzufügen oder die vorhandenen VLANs anzupassen.

Nun ist eben die Frage, wie viel zukünftig noch geplant ist bzw. sein könnte, denn z.B. jetzt einen Router anzuschaffen, der nur 1 Gbit/s-Anschlüsse hat, obwohl ggf. ein NAS, was mehr als 1 Gbit/s kann, in ein eigenes VLAN/Netzsegment gepackt werden soll, wäre dementsprechend kurzsichtig. Die Aruba 1930 gibt es mit und ohne SFP+-Ports, welchen hast Du da genau? Wenn der mit SFP+-Ports sein sollte, könnte zumindest der Router mit mehr als 1 Gbit/s am Switch angeschlossen werden, so dass auch mehrere 1 Gbit/s-Übertragungen unter den VLANs untereinander nicht vom Router ausgebremst werden.

P.S.: dieses Thema ist besser im Netzwerk-Unterforum aufgehoben.

 

[Supaman]

Du brauchst zu allererst eine Router Instanz, die regelt welche VLAN von wo nach wo darf oder nicht darf. Das kannst Du als VM z.B. mit PFsense oder OPNsense machen. Die benutzerfreundlicheste Variante wäre ein Unifi Router, u.a. da Du schon Unifi einsetzt. Ein Unifi Cloud Gateway Ultra kostet ~100 Euro.

 

[besterino]

Wenn dann nur was ohne Cloud. Wäre ne VM denn dafür denkbar? Und sinnvoll? Wie funktioniert da die Logik: eine NIC mit allen VLANs zur VM und die routed dann zwischen den VLANs?

@Eye-Q: die Zukunft ist jetzt. Aber mein 100Gbit-LAN bleibt physisch getrennt… das

 

[Eye-Q]

Wenn dann nur was ohne Cloud. Wäre ne VM denn dafür denkbar?

Ja, prinzipiell schon. Es gibt von Ubiquiti sogar einen Unifi OS Server, der natürlich auch in einer VM installiert werden kann. Inwiefern der dann mit VLANs umgehen kann, konnte ich aber auf die Schnelle nicht sehen, das wäre aber mein erster Lösungsansatz mit den Ubiquiti-APs. Da musst Du dann aber schauen, wie das in der Virtualisierungssoftware eingestellt werden muss, dass auch alle VLANs an die VM durchgereicht werden, außer Du reichst eine physische NIC direkt ohne Virtualisierungsschicht an die VM weiter.

Und sinnvoll?

Wenn Du keine neue Hardware anschaffen möchtest, dann ja.

Wie funktioniert da die Logik: eine NIC mit allen VLANs zur VM und die routed dann zwischen den VLANs?

Ja, ich würde da aber zwei NICs verwenden: eine für eine dedizierte Verbindung zur Fritzbox (dann kann definitiv nichts auch nur versehentlich direkt über die Fritzbox ins Internet) und die andere für das Routing und Firewalling zwischen den internen VLANs.

 

[besterino]

Ich fange mal an…

 

[AliManali]

Hast/hattest Du nicht diverse dicke Server? Wie bist Du bislang nur um einen VLAN fähigen Router oder gar eine Firewall herum gekommen? Ganz ohne DMZ? Oder waren/sind die nicht von aussen erreichbar?

 

[underclocker2k4]

Nur weil man Server hat, bedeutet das nicht, dass man auch getrennte Netzwerke oder gar ne DMZ braucht.
Da gibt es schon in der Arbeitswelt keine Kausalität zu und im Privaten schon 3x nicht.

Das, was er da hat, ist ziemlich übliche und vor allem auch ausreichend in den meisten Fällen.

 

[AliManali]

Sry, bin da vielleicht etwas vorbelastet und mittlerweile auch verwöhnt. Wenn ich ehrlich bin, hatten wir die ersten Server sogar ganz ohne Router betrieben. Die guten alten Zeiten mit NT 4.0 Backoffice Server, w2k, mit Plesk und allem. Unglaublich was wir uns damals alles eingefangen hatten. War also damals schon ein Honeypot, wenn auch eher unfreiwillig. Aber jedem Tierchen sein Pläsierchen. In meiner "Arbeitswelt" ist das halt nicht weg zu denken, wenn man mit Servern hantiert, die von aussen erreichbar sind.

Mittlerweile traue ich nicht mal mehr meinen Kumpels. Der Copilot Seat hat schon zwei VLANs, je nach dem ob er als Copilot Seat oder Lab Rechner dient. Trau schau wem, hatte schon ganz schlimme Finger aka sogenannte Freunde an meiner IT. Da rüste ich lieber mit zu vielen VLANs auf, als dass ich meinen Minecraft Server direkt ins LAN stelle.

Hatte mir dann mal meine erste Firewall und Switch hin gestellt, und bisschen das LAN gesnifft. Meinte dann zum langjährigem Freund, Du da geht ganz merkwürdiger Verkehr von Deinem Rechner dauernd nach Russland. Er hat sich dann reichlich auffällig benommen, also hab ich dann mal genauer nachgesehen, was der eigentlich so treibt auf meiner (Business-) Leitung. Musste dann kurzerhand mal seinen Rechner auf den Polizeiposten bringen, das war dann sogar mir zu viel. Liegt mir ja fern, irgendwelche Leute auszuspionieren oder gar anzuzeigen, aber der liess mir echt keine andere Wahl. Und nein, das war kein Random Porn von emule. Der hat sich da ganz gezielt eine Sammlung mit Baby Bildern angelegt. Ne echt, ohne Scheiss. Also so Wickeltischfotos. Da steht der voll drauf. Könnte da noch paar lustige Storys dazu erzählen, aba lass mal, ist bald 20 Jahre her...

Und auch sonst hatte ich schon reichlich merkwürdiges Zeugs erlebt. Von daher befasse ich mich halt bisschen mit Security, so gut es geht im Hobbybereich. Bin auch nicht so ein Spacken, der alles und jeden protokolliert. Da läuft der Grossteil im RAM ab, wo ich bisschen ein Auge drauf habe. Bei einigen tausend Nutzern pro Tag, die man zum Teil auch supportet, will man es auch gar nicht zu genau wissen. Solange es mich nicht selber tangiert, bin ich da nicht drauf aus, jemanden auszuspionieren.

Kurz: Server von aussen erreichbar im LAN für mich ein nogo. Aber das muss jeder selber wissen.

 

[Supaman]

Wenn dann nur was ohne Cloud. Wäre ne VM denn dafür denkbar? Und sinnvoll? Wie funktioniert da die Logik: eine NIC mit allen VLANs zur VM und die routed dann zwischen den VLANs?

@Eye-Q: die Zukunft ist jetzt. Aber mein 100Gbit-LAN bleibt physisch getrennt… das

Cloud ist bei Unifi optional - Du kannst das Gerät mit einem Account verknüpfen, und dann von überall administrieren, musst Du aber nicht. Der Unfi UOS Server ist nur die Network Applicationohne Firewall, und kann als VM betrieben werden. Oder halt eine PFsense/OPNsense als VM.

Man kann *alles* über einen LAN Adapter ziehen, schöne finde ich es, wenn man wenigstens 2 physische Interfaces verwendet - LAN und WAN. Dann hat man kalre trennung von in und out, dann vermdeit man "versehentlich" mal alles ins WAN zu hängen.

 

[VirtuGuy]

Was mach ich am besten & geht das idealerweise, ohne neue Hardware anzuschaffen bzw. zusätzliche Stromverbraucher?

du kannst opnsense o.ä. auch als VM laufen lassen und dich damit mal spielen.

 

[sch4kal]

Cloud ist bei Unifi optional - Du kannst das Gerät mit einem Account verknüpfen, und dann von überall administrieren, musst Du aber nicht. Der Unfi UOS Server ist nur die Network Applicationohne Firewall, und kann als VM betrieben werden. Oder halt eine PFsense/OPNsense als VM.

Trotzdem nicht vergessen, wenn man nicht will dass das Ubishitty Zeug nach Hause telefoniert, den Internetzugang für den UServer UND alles andere Zeug davon zu sperren und nur bei Bedarf freizugeben.

 

[besterino]

Ich denk in der Tat, ich fange mal mit einer VM an. Für meine Zwecke sollte das eigentlich locker reichen und die Angriffsvektoren auf mein bzw. in meinem Netzwerk sind überschaubar (keine Zwielichtigen Gestalten, nur ganz wenige Services mit ihren jeweiligen Ports exposed nämlich derzeit nur noch Teamspeak, Nextcloud und VPN). D.h. mein Risiko hängt halt an der Verwundbarkeit dieser Services - ist zwar nicht Null aber wo ist es das schon….

Was wäre denn Eure Empfehlung? opnsense? pfsense? Mikrotik RouterOS? VyOS? IPFire? sophos (scheint es immer noch zu geben)? Ganz was anderes? Hab mal bisserl quergelesen und tendiere aktuell zu opnsense.

wenigstens 2 physische Interfaces

Joah, aber wenn man das verfummelt ist auch alles möglich von Loop bis Split Brain. Been there, done that. Fairerweise aber auch inklusive sich selbst aussperren.

 

[BobbyD]

Nextcloud

Du exposed also deine Nextcloud. Ein Grund mehr, was vernünftiges davor zu setzen. Würde dafür zur OPNsense greifen und Blocklisten einrichten, z.B. firehol. Was Du auch machen kannst, die Fritzbox weiterhin ein LAN aufspannen lassen und dann die OPNsense als Exposed Host konfigurieren, dann haste das Fritz Netz immer noch als Notnagel.

 

[danielmayeragain]

Moinsen, ich müsste einen neuen Benutzernamen ziehen, bin aber der 100/800G-Mensch.

Ich nutze pfsense auf einer virtuellen Maschine, die mit dedizierten LAN -Port (10G SR) an den Switch geht, in dem wiederum direkt der GPON vom Telekom-Anschluss steckt.
Vlans 100,200...600, von dem aktuell IOT-Extern (Internet-only: Radio, Siemens@home etc), IOT-intern (kein Web Zugang: Shelly, HMIP, Entkalker ,etc), Gästenetz, normales Netz.
Bei pfsense Recht simpel, DHCP und Routing halbwegs intuitiv einstellbar.

Nachtrag: ich finde haptisch pfsense besser als opnsense, bei opnsense kann man aber kostenlos die ETPRo-Blocklisten bekommen.

 

[besterino]

Habe nochmal ein zwei Fragen zur Herangehensweise bzw. Setup, vor allem ob mein Verständnis richtig ist - bevor ich wild anfange umzustöpseln, zu konfigurieren und ggf. Unsinn einzukaufen.

Zu den UAP-AC-Pro: Wenn ich das richtig verstehe, fügt der AP (bzw. zusammen mit der Konfiguration entsprechender Netze im Controller) dem Verkehr der verschiedenen Endgeräte automatisch einen VLAN-Tag hinzu, je nachdem in welchem WLAN (SSID) die am AP hängen. Mit anderen Worten, das Endgerät muss gar nicht VLANs können, das macht der AP quasi im Hintergrund, korrekt?

Auch manche „wired“ Geräte, die selbst keine VLANs verwalten können, würde ich gerne in gewisse VLANs stecken. Zum Beispiel ein Smarthome-Hub soll ins IoT VLAN (20), an dem man aber keine VLANs konfigurieren kann. Dann reicht es im Switch dem Port, an dem (nur) das dumme Gerät hängt das VLAN mit der VLAN ID 20 zuzuweisen und der Switch fügt dann für den Traffic des „dummen Geräts“ die Tags hinzu (also quasi wie der AP, nur nicht per SSID sondern eben per physischem Port)?

Bonusfrage: macht der Switch das dann ggf. auch für alle Geräte an dem Port, die z.B. über einen „dummen“ Switch dahinter hängen?

Ich würde also im AP beispielsweise 3 Netze konfigurieren: IoT (VLAN 20), Trusted (VLAN 30) und Guest (VLAN 40).

Für den Port im Switch, an dem der AP hängt, muss ich dann auch VLANs mit den IDs 20, 30 und 40 konfigurieren.

Dann muss ich mir überlegen, an welche weiteren Ports der Traffic dieser VLANs gehen soll bzw. welche Geräte noch ins IoT-VLAN gehören. Die Ports bekommen dann alle (mindestens) auch ID 20. Zum Beispiel der oben genannte Smarthomehub.

Der Port im Switch, an dem meine Hyper-V mit der Firewall/Router-VM hängen wird, bekommt dann alle VLANs (Trunk). Im Hyper-V baue ich dann virtuelle Switches für jedes VLAN und kann damit dann steuern, welche VM an welches VLAN angebunden wird. Also z.B. Router-VM an alle VLANs, Home Assistant z.B. nur an IoT VLAN 20.

Die Router-VM macht dann vermutlich am besten auch gleich den bzw. die DHCP-Server für alle VLANs (jedes braucht ja grds. seinen eigenen, korrekt?)?

Ich hätte als Endausbau gerne neben den verschiedenen VLANs für Management, Server, IoT, Gäste usw. ein Standard-Netz, in dem alle Geräte ohne spezifische VLAN-Zuweisung standardmäßig landen und darüber eine Grundanbindung ans Internet haben. Damit deren Traffic durchkommt, muss ich an den Ports, an denen solche Geräte irgendwo direkt oder indirekt hängen können, das „untagged“ VLAN aktiv lassen, richtig? Damit aber das Ganze noch Sinn macht, sollten nur Geräte gleicher „Sicherheitsstufe“ an einem gemeinsamen physischen Port hängen, oder?

Die genauen Regeln, wer aus welchem VLAN oder dem „Untagged“ Bereich wie ins Internet darf, kann ich dann in der Firewall festlegen, indem ich die Firewall-VM über zwei physische NICs zwischen Internet (=direkt an die FRITZ!Box) und „Rest“ (=Core Switch) hänge. Ohne das Routing der Firewall-VM gibts dann nämlich grds. keinen Weg nach draußen. Umgekehrt könnte ich bei einem Ausfall der Firewall-VM schnell mal schmutzig überbrücken, indem ich die FRITZ!Box direkt in einen Port am Switch stecke, der für alle VLANs konfiguriert ist… müsste ich dann halt mal ausprobieren, was dann noch funktioniert.

Wenn ich das richtig sehe, wird die Netz-Konfiguration mit VLANs aber deutlich Fehleranfälliger, weil auf einmal der physische Port am Switch entscheidet oder zumindest entscheiden kann, in welchem (logischen) Netz man landet. Mal schnell umstecken kann dann zu lustigen Ärgernissen führen. Doku wird noch ein Stück wichtiger. Habt Ihr irgendwelche Tipps, wie man den Überblick behält und/oder das Risiko von Fehlkonfigurationen verringert?

Ich glaub, ich bau mir erstmal nen kleines Test-Lab zum Rumspielen auf, bevor ich hier an der Hauptschlagader das völlige Chaos anrichte… Ein paar Endgeräte und Switches dafür sollte ich noch über haben…

 

[danielmayeragain]

Offtopic @VL125 : Ich kann auf PN noch nicht antworten. Warte bitte die zwei Tage auf Antwort.

 

[danielmayeragain]

Langer Post, besterino
Es ist recht einfach, wenn man die eigene Technik - meist eine heterogene Mischung an Herstellern - im Griff hat.
Wenn es nicht Cisco ist, ist es in der Regel webbasiert und etwas einfacher.

In den Switchen werden alle VLANs hinterlegt und ggf den Ports zugewiesen. Wichtig ist, das Switch-2-Switch als sogenannte "Trunkports" eingestellt werden, also alle VLANs dürfen.
WLAN-APs sind in dem Sinne Switchen, so dass der Anschlussport des AP auch auf Trunk bzw alle VLAN gestellt wird.
Im Ubi-AP definierst Du ein Netz je VLAN und weist es den SSIDs jeweils zu. Die Anmeldung an die SSID führt dann automatisch zum VLAN-Tag, in den Geräten muss man nichts einstellen, richtig.

Wenn du an den Switchen Ports auf bestimmte VLAN setzt, sind die port-based tagged. Ja, alles dahinter läuft für den Switch dann auch dem gleichen VLAN, es kommt also auch nur Traffic an den Port, der dieses VLAN zulässt. Eine gerne gesehene Fehlerquelle. Ein passiver Switch hinter port-tagged hat also alle dortige Geräte in der VLAN. Ich habe das z.B. für den E-Schrank mit den Shellys: Ein Port mit VLAN in den Schrank, dort 8er Switch für Shelly Pro.

Im Router bzw Pfsense klärst Du, was welches Netz darf, über die Regeln und NAT. Wichtig aber auch bekannt: ein VLAN = ein IP-Netz. Also z.b. 192.168.10.x, 20.x, etc
Der erste Schritt ist, alle Geräte in der pfsense erkannt zu haben und im richtigen VLAN=Netz zu sehen. Das VLAN1 entspricht häufig untagged und sollte überhaupt nicht definiert werden. Solange du keine VLAN vergibst, laufen die Geräte immer im untagged Netz auf und erhalten die standard-IPs. Man kann daran wirklich schön sehen, ob Switchen und Geräte richtig ankommen.

Wenn am Switch untagged oder Trunk eingestellt ist, kannst du im z.B. Linux-System eine VLAN-Bridge frei nutzen, wenn VMs unterschiedlichen Netzen zugewiesen werden sollen.

In der pfsense wird geroutet. Dort wird für jedes VLAN eine Schnittstelle erstellt und zugewiesen. Wenn du nur eine interne hast - häufigster Fall - läuft das auf tagged subdevices, also ix0.10, ix0.20, etc zur Schnittstelle "gast", "iot_web" "iot_intern" wie auch immer. Wenn physische dazu kommen, z.B. ominöse 100G-Karten, die außerhalb der Switchstruktur laufen/Direktverbindung, wird auch das hier konfiguriert, ggf mit VLAN versehen. Auf jeder Schnittstelle kann man mit nem Häkchen und der IP-Range-Angabe den DHCP definieren. Die pfsense braucht eigentlich keinen Neustart bei diesen Arbeiten, ich hatte aber sicherheitshalber bei der Neuanlage von Schnittstellen einen reboot durchgeführt.

Meine pfsense läuft als VM, 1x10G-T onboard physisch übergeben als WAN, 1x100G physisch übergeben als Switch-Ersatz, 1x10G ist vom ubuntuserver als Bridge zugewiesen. Auf letzterem laufen alle internen VLAN zum Hauptswitch, in der pfsense sind sechs VLAN draufgelegt und in den Switchen gespiegelt natürlich. Die 100G ist direkt zur Workstation verbunden.

Unfachliche Erläuterungen, aber die Fragen sind hoffentlich beantwortet?

Um halbwegs klar zu kommen, sollten die Geräte DHCP-konfiguriert sein. Dadurch siehst du in der pfsense auf der DHCP-Statusseite alle. Wenn was fehlt, stimmt dessen Verkabelung oder Config noch nicht zur Zentrale. Man kann dann Geräte-spezifisch auf Suche gehen. Ich habe nur den BMC der Server feste IP zugewiesen, da eine nicht funktionierende pfsense mangels DHCP die sonst unauffindbar macht..

Ich hatte einige Tage ziemlich geflucht, weil drei verschiedene Switche und darunter Cisco nicht einfach waren.

 

[besterino]

Vielen Dank @danielmayeragain, vor allem fürs Durchkämpfen durch meinen Post , das bestätigt meine Überlegungen.

Ich glaub, ich hätte auch gerne bei allen mit Home-Assistant verbundenen Devices feste IPs… am elegantesten wäre wohl, wenn die pfsense denen immer die gleiche IP per DHCP zuweist, dann sind die Dinger wenigstens auch erreichbar, wenn ich sie mal aus Gründen in ein anderes Netz hänge (und sie dann halt ne andere IP bekommen). Gleiches für Server, Switches, APs und sonstige Infrastruktur… aber dafür konfiguriere ich mich ja mit den MACs zu Tode…

Kann mir eigentlich die pfsense ne Warnung ausspucken, wenn eine bekannte MAC im falschen VLAN rumgeistert?

 

[Supaman]

Zu den UAP-AC-Pro: Wenn ich das richtig verstehe, fügt der AP (bzw. zusammen mit der Konfiguration entsprechender Netze im Controller) dem Verkehr der verschiedenen Endgeräte automatisch einen VLAN-Tag hinzu, je nachdem in welchem WLAN (SSID) die am AP hängen. Mit anderen Worten, das Endgerät muss gar nicht VLANs können, das macht der AP quasi im Hintergrund, korrekt

Der WLAN Client verbindet sich mit der jeweiligen WLAN=SSID, welche ein spezifisches VLAN zugewiesen hat, und befindet sich damit in dem Netzwerksegement. Der Client weis nichts von VLANs und braucht auch keine konfig.

Auch manche „wired“ Geräte, die selbst keine VLANs verwalten können, würde ich gerne in gewisse VLANs stecken. Zum Beispiel ein Smarthome-Hub soll ins IoT VLAN (20), an dem man aber keine VLANs konfigurieren kann. Dann reicht es im Switch dem Port, an dem (nur) das dumme Gerät hängt das VLAN mit der VLAN ID 20 zuzuweisen und der Switch fügt dann für den Traffic des „dummen Geräts“ die Tags hinzu (also quasi wie der AP, nur nicht per SSID sondern eben per physischem Port)?

Es gibt keine "dummen" Geräte, es gibt nur untagged und tagged Datenpakete. VLAN Traffic bedeutet: die Datenpakete sind mit dem jeweiligen VLAN Tag (z.B. 20) markiert.
Es gibt 2 Möglichkeiten für das VLAN Tag:
1) das Endgerät schickt die Datenpakete tagged auf die Reise
2) der Switch Port erledigt das tagging: eingehende Datenpakete am Port des Switches werden mit dem Tag angereichert, für ausgehende wird das Tag entfernt

Bonusfrage: macht der Switch das dann ggf. auch für alle Geräte an dem Port, die z.B. über einen „dummen“ Switch dahinter hängen?

Für einen Switch Port konfiguriert man das native Netz = welches VLAN Tag soll für untagged vergeben werden, und ggf. VLANS die anliegen. Man kann auch native = none setzen und nur VLAN Tags setzen.

Ich würde also im AP beispielsweise 3 Netze konfigurieren: IoT (VLAN 20), Trusted (VLAN 30) und Guest (VLAN 40).
Für den Port im Switch, an dem der AP hängt, muss ich dann auch VLANs mit den IDs 20, 30 und 40 konfigurieren.
Dann muss ich mir überlegen, an welche weiteren Ports der Traffic dieser VLANs gehen soll bzw. welche Geräte noch ins IoT-VLAN gehören. Die Ports bekommen dann alle (mindestens) auch ID 20. Zum Beispiel der oben genannte Smarthomehub.

Korrekt.

Der Port im Switch, an dem meine Hyper-V mit der Firewall/Router-VM hängen wird, bekommt dann alle VLANs (Trunk). Im Hyper-V baue ich dann virtuelle Switches für jedes VLAN und kann damit dann steuern, welche VM an welches VLAN angebunden wird. Also z.B. Router-VM an alle VLANs, Home Assistant z.B. nur an IoT VLAN 20.

Du kannst das VLAN Tag direkt in der jeweiligen VM in der Konfiguration der Netzwerkkarte setzen. Das bei Hypervisorn Standard, bei den Netzwerkkarten Treibern von Windows nicht.

Die Router-VM macht dann vermutlich am besten auch gleich den bzw. die DHCP-Server für alle VLANs (jedes braucht ja grds. seinen eigenen, korrekt?)?

Ja.

Ich hätte als Endausbau gerne neben den verschiedenen VLANs für Management, Server, IoT, Gäste usw. ein Standard-Netz, in dem alle Geräte ohne spezifische VLAN-Zuweisung standardmäßig landen und darüber eine Grundanbindung ans Internet haben. Damit deren Traffic durchkommt, muss ich an den Ports, an denen solche Geräte irgendwo direkt oder indirekt hängen können, das „untagged“ VLAN aktiv lassen, richtig? Damit aber das Ganze noch Sinn macht, sollten nur Geräte gleicher „Sicherheitsstufe“ an einem gemeinsamen physischen Port hängen, oder?

Etwas anders: VLANs werden nur dort aktiviert oder durcgereicht, wo sie benötigt werden. Untagged schaltet man nach möglichkeit ab, und wenn Untagged, dann leitet man das in die dafür vorgesehenen Netze.

Die genauen Regeln, wer aus welchem VLAN oder dem „Untagged“ Bereich wie ins Internet darf, kann ich dann in der Firewall festlegen, indem ich die Firewall-VM über zwei physische NICs zwischen Internet (=direkt an die FRITZ!Box) und „Rest“ (=Core Switch) hänge. Ohne das Routing der Firewall-VM gibts dann nämlich grds. keinen Weg nach draußen.

Korrekt - die Firewall bestimmt, wer von wo nach wo darf, und was rein oder rais darf - inklusive Traffic zwischen den VLANs.

Umgekehrt könnte ich bei einem Ausfall der Firewall-VM schnell mal schmutzig überbrücken, indem ich die FRITZ!Box direkt in einen Port am Switch stecke, der für alle VLANs konfiguriert ist… müsste ich dann halt mal ausprobieren, was dann noch funktioniert.

Das wird so einfach nicht funktionieren, weil die "Übersetzung" zwischen VLAN und Internet fehlt. Du hast dann nur Internet im jeweils als untagged konfigurierten LAN. Das Risiko von Ausfall kann man aber minimieren, wenn man die *sense z.B. als HA konfiguriert, dann ist eine aktive und eine in Bereitschaft. Oder das geht auch in Hardware: die Unifi Dream Machine Router haben einen Shadow Mode, das ist sowas wie RAID-1 für Router, die spiegeln sich dann, die Technik dahinter heisst VRRP.

Wenn ich das richtig sehe, wird die Netz-Konfiguration mit VLANs aber deutlich Fehleranfälliger, weil auf einmal der physische Port am Switch entscheidet oder zumindest entscheiden kann, in welchem (logischen) Netz man landet. Mal schnell umstecken kann dann zu lustigen Ärgernissen führen. Doku wird noch ein Stück wichtiger. Habt Ihr irgendwelche Tipps, wie man den Überblick behält und/oder das Risiko von Fehlkonfigurationen verringert?

Auf einer Strecke von A nach D, über Station B und C müssen auf der gesamten Datenstrecke die Uplinks der Switche etc. alle benötigten VLAN Tags durchlassen. Dadurch hat man auch u.a. die latente Fehlerquelle, das man sich selbst aussperrt. Man muss also über das gesamte Konstrukt den Überblick behalten, wo welche VLANs mit und ohne Tag anliegen, und die Datenstrecken über mehrere Hops richtig konfiogurieren. Wenn man dazu einzeln auf die Geräte drauf muss, kann es schonmal dauern bis man einen Fehler findet, weil es nicht funktioiniert.

Und das ist halt der große Vorteil, wenn man die gesamte Struktur von Unifi hat: da hat man alle Switche, APs etc in *einer* Oberfläche, und kann auch Profile (z.B. vLAN 10,20, 50) für die Uplinks zwischen den Switchen und APs anlegen, und das Profil dann in den Ports eintragen. Und wenn man später VLAN 66 zufügen will, ändert man das im Profil und alle beteiligten Geräte sind autoamtisch aktualisiert.

 

[danielmayeragain]

Fein strukturierte Ausführungen. Ergänzend zur Frage: Feste IP-Adressen, egal in welchem Netz, verteilt man über die pfsense durch "pinnen". Endgeräte immer auf DHCP, Du hast sonst latent massive Probleme, wenn Du Netzstrukturen änderst.
Also alle per DHCP anmelden lassen, schauen ob die im "richtigen" Netz gelandet sind. IP-Range in der pfsense so setzen, dass ein Bereich für feste IP ausgenommen ist. Dann neben jedem Gerät auf das "+"-Symbol und dem MAC-basiert eine feste zuweisen.

 

[Supaman]

DHCP für alle Geräte, Server und VMs sehe ich kritisch. Fällt Dir die DHCP Instanz aus, und die Instanz verliert die IP, geht erstmal gar nix. Ich würde für Server und VMs etc statische IPs setzen, DHCP nur für User Clients, da man zur Not auch mal eine IPs temporär manuell setzen kann.

 

[danielmayeragain]

Du kannst aber eben trotzdem ne Fritte anklemmen, wenn die pfsense ausfällt - ein Risiko bei VM-Firewall. Dann gibt es die VLAN-Struktur nicht, aber alles sichtbar. Statische IP wie gesagt bei BMC/IPMI, dann kommst ja überall ran. Idealerweise innerhalb eines eigenen, ggf. portbasierten VLAN. Vermutlich eine Frage der Sichtweise.

 

[BobbyD]

Im Hyper-V baue ich dann virtuelle Switches für jedes VLAN und kann damit dann steuern, welche VM an welches VLAN angebunden wird. Also z.B. Router-VM an alle VLANs, Home Assistant z.B. nur an IoT VLAN 20.

Jein. Insbesondere, wenn Du Win-Server einsetzt, machst Du erst mal pro zu nutzender physischer NIC jeweils einen "externen vSwitch". Die virtuellen NICs der Router-VM fügst Du dann per PowerShell hinzu, damit diese Multi-VLAN-fähig sind (Trunk). Das hat den Vorteil, dass Du die VLANs direkt in der *Sense einrichten kannst, statt da im Kopf irgendwelche Übersetzungen machen zu müssen bzw. Du lernst die Sense damit so einzurichten, wie man es auch an einem physischen Switch tun würde.
Du kannst natürlich auch weitere "interne" oder "private" vSwitche in Hyper-V machen, an denen nur virtuelle Geräte hängen, aber das führt jetzt zu weit.

 

[besterino]

Danke an dieser Stelle schonmal an alle!

Ich male mir nun mal meine Konfig auf.

 

[besterino]

Kleines Statusupdate (und Doku für mich ) mal zwischendurch:

Grund--Setup:
Hyper-V Host (Server 2022)
2 Physische NICs (für diese Zwecke): 1x1Gbit als WAN-Verbindung (derzeit insb. verbunden mit der Fritzbox und mit meinem normalen Netz), 1x10Gbit als LAN (verbunden mit einem vorerst isolierten Port am Core-Switch)
pfsense-VM

Meine bisherigen Schritte:

Gemäß Netgate-HowTo (#1):
1.
in Hyper-V WAN / LAN Hyper-V vSwitches (jeweils als "extern") definieren

2.
in Hyper-V VM für pfsense einrichten mit 2 vNICs an den beiden vSwitches

3.
in Hyper-V pfsense in VM installieren
"Fritzbox-Netz" als WAN
Isolierter Port als LAN (vorübergehend isoliert bis ich meine Netze sauber hab, insbesondere um nicht aus Versehen 2 DHCP-Server im gleichen Segment zu haben)

4.
Dann merken wir uns die MAC-Adressen der beiden vNICs, z.B. sichtbar in Hyper-V):

Behaupten wir mal, meine WAN-MAC endet auf ...01 und meine LAN-MAC auf 02.

5.
Hyper-V mit Powershell mitteilen, dass alle meine VLANs an die pfsense gehen dürfen:

 PS C:\Users\Administrator> get-vmnetworkadapter -vmname pfsense | where-object {$_.MacAddress -eq '...02'} | Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "10,20,30,40,50,200" -NativeVlanId 1

Anmerkung: Als "NativeVlanID" habe ich mal 1 (Standard wäre wohl 0) genommen, weil mein Core-Switch untagged wohl im VLAN 1 hat.
\\ Bin noch nicht so weit, dass ich testen kann ob das wie gewünscht funktioniert...

Prüfen kann man das dann mit:

 PS C:\Users\Administrator> Get-VMNetworkAdapterVlan

Gemäß Netgate Howto #2:

6.
in der pfsense unter Interfaces --> Interface Assignments --> VLANs
nach Wunsch VLANs anlegen und an die richtige vNIC / Interface (LAN) binden.

7.
in der pfsense unter Interfaces --> Interface Assignments
alle VLANs als neue eigene Ports hinzufügen (mit statischer IP Adresse in unterschiedlichen Subnetzen - Obacht: steht std. auf /32, ich hab /24 genommen)

Tauchen dann als OPT1...n als eigene Interfaces auf.

8.
in der pfsense unter System --> Advanced --> Networking
Bei den DHCP Options das Server Backend auf "Kea DHCP" umstellen (der ISC DHCP wird wohl mittelfristig rausfliegen)

9.
in der pfsense unter Services --> DHCP Server
Für jedes "OPT" den DHCP-Server aktivieren und zumindest die die Address Pool Range definieren.

10.
[OPTIONAL] Zumindest vorübergehend für TESTZWECKE
in der pfsense unter Firewall --> Rules
für alle OPT-Interfaces ICMP Echo Requests erlauben.

11.
in Hyper-V für andere Hyper-V VMs auf dem selben Host nun das gewünschte VLAN festlegen:

PS C:\Users\Administrator> Set-VMNetworkAdapterVlan -vmname "DEINE-VM" -Access -vlanid ###

Alternativ in der GUI per Hyper-V Manager --> VM Settings --> Network Adapter --> Enable virtual LAN identification

Leider kann man die VLAN-ID nicht im laufenden Betrieb der VM wechseln (zumindest nicht mit Windows Server 2022). Also kann man schon, funktioniert aber nicht direkt. Man muss die VM entweder vor der Änderung (egal ob GUI oder Powershell) runterfahren oder danach einmal neu starten.

Wenn man einer VM mehrere VLANs zuweisen will, dann mit dem Befehl aus oben Nr 5.

12.
[OPTIONAL] wenn man es bei der Erstkonfiguration nicht schon richtig gemacht hat (hab ich nicht), pfsense (auch) aus bestimmten VLANs erreichbar machen
in der pfsense unter Firewall --> Rules
für die gewünschten OPTs Port 443 freigeben:

12.
[OPTIONAL] Hyper-V Host selbst in ein (auch) von der pfsense verwaltetetes VLAN (z.B. Management VLAN)1 hängen:
in Hyper-V im Virtual Switch Manager dem Host erlauben, das er den LAN-vSwitch mitbenutzen darf, VLAN-ID aktivieren und das gewünschte VLAN eintragen.

ACHTUNG: Jetzt muss man mal den Hyper-V Host rebooten - sonst funzt die VLAN-Zuweisung nicht (gleichen Phänomen wie bei den VMs oben unter Nr 11!


- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

In meinen Augen ist der Hyper-V Host inkl. pfsense-VM nun quasi "fertig" für alles weitere. Die VLANs sind konfiguriert und funktionieren soweit auch alle für VMs auf dem Host: wenn ich bei einer VM die VLAN-ID ändere, bekommt die VM nach VM-Reboot von dem pfsense DHCP-Server ihre IP im richtigen VLAN.

Als nächstes kommt dann der Anschluss der VLANs an die Außenwelt dran, also die Verbindung(en):
Physischer Client --> Physischer Switch --> Hyper-V --> pfsense-VM

hmmm... wenn ich das mal komplett hingefrickelt habe, wäre das ja schon fast mal wieder ein HowTo für den Hyper-V Sammler...

 

[BobbyD]

Anmerkung: Als "NativeVlanID" habe ich mal 1 (Standard wäre wohl 0) genommen, weil mein Core-Switch untagged wohl im VLAN 1 hat.

Jein. Nimm die Null, weil die Eins i.d.R. nicht nach außen geführt wird.
Set-VMNetworkAdaptervlan -VMName pfSense -VMNetworkAdapterName "hn1" -Trunk -AllowedVlanIdList "1-4094" -NativeVlanId 0

Und änder dir gleich mal den Web-UI TCP Port ab, z.B. auf 8443, weil sich das später gerne mit nem Reverse-Proxy beißt.

 

[Supaman]

Kleiner Tip zu den IPs - bewährte Vorgehensweise ist das VLAN in die IP Adrese einzubauen, also z.B.
192.168.xxx.1 oder 10.xxx.1.1