pfsense, UniFi, und TP-Link: VLAN Setup
-
@bob-dig
Ja, das war die Idee...ist auch lediglich aus theoretischem Interesse gefragt, denn hier sind es mittlerweile die kleinen cisco sg switche, die laufen. Da kann ja eh alles möglich konfiguriert werden.
Und ja, das Native VLAN1 ist leer, dient als reiner Uplinkbereich und Management VLAN ist ausgelagert auf ein anderes VLAN.
Danke für die Rückmeldung...
:) -
Eben kam der Zyxel an, und ich habe versucht, ihn analog zu den Ratschlägen, die ich zum TP-Link bekommen hatte, einzurichten:
Es besteht dasselbe Problem. Schließe ich ein Gerät an Port 2 (VLAN 20) an, bekommt es eine IP aus dem entsprechenden Subnet. Schließe ich weiteres Gerät an Port 3 (ebenfalls VLAN 20) an, bekommt auch dieses eine entsprechende IP zugewiesen. Schließe ich nun ein weiteres Gerät an Port 8 (VLAN 22) an, passiert nichts. Es bekommt überhaupt keine IP zugewiesen, ist nicht in der pfSense zu sehen, und auch nicht anpingbar.
Unter UniFi habe ich dem Zyxel das Profil
All
zugewiesen; so habe ich es auch bei dem UniFi 8er Switch gemacht, der ebenfalls dort angeschlossen ist. Dieser Switch kann mit allen VLANs umgehen.Testweise habe ich dem Zyxel einmal das Profil
LAN
zugewiesen, was aber keinen (für mich erkenntlichen) Unterschied gemacht hat. Der Zyxel Switch selbst bleibt anpingbar und die WebUI erreichbar, die verbundenen Geräte verhalten sich aber weiterhin genau so, wie oben beschrieben.Unter pfSense sind die VLANs folgendermaßen eingerichtet
Unter UniFi sind die Profile folgendermaßen angelegt
Hier habe ich aktuell nicht die Möglichkeit, die Einstellungen zu verändern.
Ist die VLAN-ID 1 ein Default wert, oder kann es sein, dass ich hier einen anderen Port benutzen muss? Ein VLAN1 habe ich zumindest auf der pfSense nicht gefunden.
-
@benjsing Auf deinen Screenshots sieht man nur VLAN 20, aber nicht das VLAN 22 bzw. IOT ist dort 42?
Hab aber keine UniFi, kann also nicht helfen. -
@bob-dig said in pfsense, UniFi, und TP-Link: VLAN Setup:
@benjsing Auf deinen Screenshots sieht man nur VLAN 20, aber nicht das VLAN 22 bzw. IOT ist dort 42?
Oh fuck, das ist jetzt gerade echt peinlich!! Ich habe den Fehler gefunden...... Der Grund ist, dass ich VLAN 22 beim Einrichten damals lediglich vorbereitet hatte, aber noch nicht umgesetzt. Heißt, bislang hätte ich immer VLAN 1 für die Geräte nehmen müssen, die ich aber immer in VLAN 22 zwängen wollte.
-
@benjsing
LOL, ja, das ist peinlich (und hätte mir genau so passieren können).
War vermutlich dann auch das Problem mit dem TP-Link?
Sei's drum, hauptsache es läuft jetzt (es läuft doch?)
:Dps. dann auch gleich noch die Beschreibung ändern...denn im pfsense screenshot hast du pvid 20 für IoT und 22 für restricted, in den folgenden dann aber v_restricted für pvid 20 und IoT für eben 42...
Auch wenn es nur descriptive Beschreibungen sind, vielleicht besser gleich anpassen bevor du später wieder drüber stolperst (weil auch wenn nur deskriptiv wär's ja doof, zu "Tisch" sagst du ja auch nicht "Stuhl"...) -
@the-other genau, jetzt läuft alles =)
Die Bezeichnungen sind etwas irreführend, weil ich sie nicht konstant gehalten habe.
VLAN20 ist IOT, heißt aber auf dem UniFi v_restricted
VLAN42 ist IOT2, welches eingerichtet wurde, als die IP Range im ursprünglichen IOT fast voll war (falsche CIDR(?)). Die können dann in ein VLAN zusammengefasst werden.Ich habe für das Wochenende schon eine schöne Aufgabe, und zwar, alles from scratch auftzsetzen.
VLAN trusted (lokale Endgerätd)
VLAN IOT
VLAN suspicious (muss ins Netz, kann aber nicht mit anderen VLAN aktiv kommunizieren und nicht ins Internet)
VLAN Gäste (nur Ports 80/443 ins Internet, kein Zugriff auf andere VLANs)Diesmal dann konstante Benennung über alle Geräte (pfsense, unifi; der Zyxel erlaubt leider nur die VLAN ID, keine Bezeichnungen), korrekte CIDR (damit beim Testen / Basteln nicht die IOT Adressen ausgehen), und gerenell "saubere" Einrichtung der pfsense.
Das aktuelle Setup besteht seit einigen Jahren und wurde durch learning by doing aufgebaut. Ist dadurch viel zu unübersichtlich geworden, ein frischer Start kann nicht schaden. Davor habe ich mich jetzt lange genug gedrückt, also wird es mal Zeit.
Vorher alles einmal in einer virtuellen Maschine austesten, dann geht die Umsetzung hoffentlich halbwegs problemfrei über die Bühne ^^
Gibt es bei der Vergabe der VLAN IDs irgendwelche Anfängerfehler zu vermeiden? Ich glaube mich zu erinnern, dass bsp. ein bestimmtes Modem nur mit pfsense zusammen arbeiten konnte, wenn es die VLAN ID 50 benutzen konnte. Hätte man diese bereits für etwas anderes vergeben, gäbe es direkt wieder Probleme.
-
Ja Gäste brauche kein NTP, keine Messanger, oder Mailclient oder alternate Ports für http/https...
Wenn du eh alles neu machst, dann kannst du dir auch gleich mal ein passendes Netzkonzept überlegen.
So kann man ein /16 ja in einige /19er Netze aufteilen, dann das 3 Oktet als VLAN ID verwenden und dann siehst man an der IP auch schon das VLAN und umgekehrt.
Muss man mal einen VPN Tunnel im Routing unterbringen, einfach das /19 rein und fertig.
Alles weitere kannst du dann mit indound Rules auf deiner Seite steuern.Und das VLAN 1 ist das an einem Switch immer anliegende Default VLAN. Bei Cisco ist das sogar immer auf jedem Trunk per default untagged drauf. Um das runter zu bekommen wird oft ein dummy VLAN benötigt.
Setzt man z.B. Spanning Tree ein, dann gibt es Protokolle die nutzen das VLAN 1 für die BPDUs, MST ist z.B. so ein Prokoll.
Daher sollte man das auf den Uplinks der Netzwerkkomponenten ruhig drauf lassen, so können sie alle wichtigen Topologieinfos austauschen. Clients sollte man hier jedoch optimalerweise nicht drin einsetzen.Für Management Zwecke ist es aber z.B. gar nicht schlecht, da ein neuer AP per default auch hier einfach ohne VLAN Konfiguration mit dem Controller sprechen kann.
Oder halt ein eigenes Management VLAN einsetzen, wenn man alle Komponenten dahin umbiegen kann, ist halt auch nicht bei jedem Device einfach so möglich. Gerade die günstigen Switche haben hier gern mal Probleme. -
@nocling said in pfsense, UniFi, und TP-Link: VLAN Setup:
Ja Gäste brauche kein NTP, keine Messanger, oder Mailclient oder alternate Ports für http/https...
Das wage ich mal zu bezweifeln. Meine Gäste wären ziemlich sauer, wenn keine Messenger gehen oder die Geräte die falsche Zeit haben... Zumal NTP eh durch die Sense bereitgestellt werden kann/sollte wie DNS auch und somit auch kein Problem wäre.
Ansonsten muss man selbst überlegen was man für Gäste aufmacht. Wie gesagt wenn ich den meisten hier (obwohl ichs gern würde) WhatsApp und Co abdrehen würde, wäre Alarm ;)
Beim Netz bin ich mit bei, da würde ich mir wenn ichs eh neu machen muss einmal die Mühe machen das ordentlich aufzuziehen mit ein paar VLANs mehr (schon gebaut aber ggf. nicht genutzt) damit ich das erweitern kann wenn nötig.
Cheers
-
Das war ironisch gemeint, das was ich für Gäste aufgezählt habe waren so die min Services die man anbieten sollte.
Nur 80/443 kann man machen wenn man die loswerden will… -
@jegr ich habe das noch einmal überarbeitet:
Für
Signal
undTelegram
hätte afaik Port 443 ausgereicht. Ich kenne niemanden, derWhatsApp
verwendet und den ich in mein Netz lassen würde; aber Ausnahmen bestätigen die Regel, also sei's drum.DNS und NTP sind nun erlaubt.
Was ich nicht verstehe: warum sollten die Geräte eine falsche Zeit haben? Nehmen wir an, Gast X loggt sich mit dem Smartphone bei mir ins Gästenetz; das Smartphone hat doch bereits die (vermutlich korrekte) Uhrzeit. Wenn es dann keine NTP Request durchführen kann, sollte es nicht einfach die korrekte Uhrzeit behalten? (nur für mein Verständnis, ich habe den Port ja nun freigegeben)
Meine VLANs habe ich nun folgendermaßen aufgeteilt
VLAN ID WAS ZUGRIFF 1 INTERN ALLES 10 VIP 1, 20, 30, 40, Eigenes VLAN, Internet 20 HAUS 30, 40, Eigenes VLAN, Internet 30 SPIONE Eigenes VLAN, Internet 40 UNTRUSTET Eigenes VLAN, KEIN Internet 50 GAST Eigenes VLAN, bestimmte Ports ins Internet 60 VPN 1, 10, 20, 30, 40, Eigenes VLAN, Internet 1 und 10 sind selbsterklärend. 20 wären alle Endnutzer im Haus ohne administrative Fähigkeiten. Ggf. dürfen sie noch auf bestimmte Ports im 10er VLAN zugreifen (NAS Freigaben o.Ä.).
30 sind Geräte, die zwangsläufig ins Internet müssen, also bsp. Amazon Alexas oder Bridges für irgendwelche IOT Geräte.
40 dasselbe in grün, aber Geräte, die explizit nicht ins Internet können sollen (Bastelkram, verschiedenes, Billig-IP-Cams, ...)
50 s.o. und 60 dann VPN; der VPN Port soll der einzige aus dem WAN erreichbare Port sein. Zugang per Keyfile und Passwort, effektiv werde vermutlich nur ich selbst das von unterwegs verwenden. Daher Zugriff auf alles wichtige.
Der 50 kann man ggf. auch noch ausgewählte Ports ins 20er Netz geben, sodass beispielsweise auf den lokalen Webserver zugegriffen werden kann. Mal schauen. Das hier ist nur ein grober Überblick, wie ich das gerne aufbauen möchte.
@jegr said in pfsense, UniFi, und TP-Link: VLAN Setup:
Beim Netz bin ich mit bei, da würde ich mir wenn ichs eh neu machen muss einmal die Mühe machen das ordentlich aufzuziehen mit ein paar VLANs mehr (schon gebaut aber ggf. nicht genutzt) damit ich das erweitern kann wenn nötig.
Was für VLANs würdest Du ggf. noch hinzufügen?
-
@benjsing
Moinsen,
VLANs sind ja (imho) immer eine seeeehr individuelle Angelegenheit:- je nach persönlichem Gerätefuhrpark (vom heiligen Backupserver hin zu schnatternden billig IoT oder alten Clients ohne verfügbare Updates/Patches),
- Anwendungsbedürfniss (was soll wen wo und wofür erreichen dürfen?)
- Aufwand der Einrichtung UND Pflege
- im Heimnetz: Alltagstauglichkeit (jaja, im Beruf auch, aber da kümmert sich idR ja die IT, ätsch)
Was mir bei deiner sonst sinnig anmutenden Segmentierung aufgefallen ist:
Warum ein VPN-VLAN? Eigentlich willst du ja per VPN auf Dienste im Heimnetz(segment) zugreifen können. Du kannst also dann im spezifischen VPN Interface unter den Firewallregeln angeben, was erreichbar sein darf oder auch nicht.Du könntest (wie gesagt, ist alles eine Frage des persönlichen Geschmacks) aus meiner Sicht die Trennung zwischen VLAN 10 und 20 überdenken. Wenn das NAS zb in VLAN10 steht, aber Endgeräte aus dem VLAN20 meistens zugreifen (?), dann wäre das zu überlegen, ggf. besser dann mit der Firewall des NAS selber feinjustieren (und Nutzerrechten).
Also zB:
VLAN1 als reines Native VLAN ohne produktiven Datenverkehr
VLAN10 HAUS (du und die Familie /WG)
VLAN20 SPIONE (Alexa, ggf. Netzwerkdrucker, SmartHome IoT)
VLAN30 UNTRUSTED ("will nach Hause telefonieren aber darf nicht IoT")
VLAN40 GÄSTEDamit würde ggf. häufiges Routing zwischen (in der alten Trennung) HAUS und NAS in VIP wegfallen...
Aber das ist eben nur (m)eine Idee dazu...
:) -
@benjsing Ich hab das bei mir etwas anders aufgebaut und daher mehr VLANs:
- 1 - ist tot, gibts nicht damit keiner Blödsinn macht
- 99 - Management, da ist alles mit Console, Management UI etc. drin. NAS UI, Proxmox UI, etc. (würde ich heute anders nummerieren, prinzipiell aber egal)
- 123 - Gast/WLAN: bekommt Internet, sonst nur Minimalzugriff und DNS und für bestimmte Clients (via WPA2-Enterprise Auth) Dashboards (IoT HA). Alle anderen nur WiFi/Internet mit geblockten IPs und gefiltertem DNS (via Infra DNSen)
- 270 - Infrastruktur: 2x DNS, Automatisierung, Monitoring, Logging, NAS, alles was zentral gebraucht wird
- 271 - LAN: Clients, meistens PCs oder Laptops, ggf. auch per WiFi und WPA2Ent Laptops.
- 272 - IoT: Kram der hoffentlich kein Netz braucht, HomeAssistant Control, MQTT, etc.
- 273 - Media: Kram der ganz sicher Internet braucht. Streaming Gedöns, Sonos Boxen, AndroidTV/Chromecast und so'n Kram
- 274-276 - Labs / frei
- 277 - Work: abisoliertes Testnetz mit direkter VPN Strecke zur Firma, nur aus dem Netz erreichbar, company DNS etc.
Daher keine so starre Einteilung aber durch WPA2Ent und Radius based VLANs pushe ich die Clients dahin wo ich sie haben will.