VLAN Konfiguration-Verständis-Frage (Problem bei der korrekten Einrichtung - Cisco)
Aloha, (heute ist Sonntag, ich habe 6h Arbeit hinter mir und vielleicht ist nicht jede folgende Information glasklar, man möge mir dann verzeihen)
ich kam nun endlich dazu unsere alten KTI websmart (irgendwas) switches gegen die Cisco SG250-26 zu tauschen (Konfiguration rein über die UI, advanced)
Zuvor war das Szenario folgendes:
[KTI] Alle Ports außer Port 8 - VLAN 1
Port 8 (führt zu einem WLAN Router für den Chef [der darf ins Internet, nicht aber unser Hauptnetzwerk]) + Port 26 (pfsense) VLAN 3
Punkt, mehr war da nicht, es gab kein (un)tagged/trunk whatever, kannte der KTI nicht. Man hat einfach Ports einer VLAN-Gruppe zugewiesen und fertig, ein Port in mehreren Gruppen war gar kein Problem.
Ich musste auch nichts extra in der pfsense konfigurieren.
So, nun sieht es beim Cisco scheinbar etwas anders aus. Also meine Konfiguration derzeit so:
[Cisco] Alle Ports außer Port 8 - VLAN 1
Port 8 Access VLAN 3 [3U als administrativ und operativ]
Port 26 General Mode VLAN 1 + 3 untagged [1U, 1P, 2F, 3U]
Ich dachte, das müsste doch schon so funktionieren, ist aber nicht. Cisco-Trunk will ich nicht, da VLAN 2 noch dazukommt (gab es damals auch schon, blenden wir jetzt einfach mal aus) und Port 26 auch dort drin sein muss. (und im Trunk-Mode kann ich nur 1 VLAN eintragen)
Habe auch versucht, dass Port 8 auch im General Mode ist und 1P, 2F, 3U hatte, kein Erfolg.
Was ist mein Denkfehler, verstehe ich das System falsch? Ich dachte, es würde genügen, dass beide 3U haben (weil, war früher so ...). Die pfsense kann aber nicht mit dem Router hinter Port 8 kommunizieren (stecke ich Port 8 ins VLAN 1 dann schon).
Muss mit den Cisco-Dingern doch mehr konfiguriert werden? Muss ich taggen? Muss die pfsense-Konfiguration auch angepasst werden? Ich blick's heute einfach nicht (mehr).
Sonnige Grüße,
André
ich kam nun endlich dazu unsere alten KTI websmart (irgendwas) switches gegen die Cisco SG250-26 zu tauschen (Konfiguration rein über die UI, advanced)
Zuvor war das Szenario folgendes:
[KTI] Alle Ports außer Port 8 - VLAN 1
Port 8 (führt zu einem WLAN Router für den Chef [der darf ins Internet, nicht aber unser Hauptnetzwerk]) + Port 26 (pfsense) VLAN 3
Punkt, mehr war da nicht, es gab kein (un)tagged/trunk whatever, kannte der KTI nicht. Man hat einfach Ports einer VLAN-Gruppe zugewiesen und fertig, ein Port in mehreren Gruppen war gar kein Problem.
Ich musste auch nichts extra in der pfsense konfigurieren.
So, nun sieht es beim Cisco scheinbar etwas anders aus. Also meine Konfiguration derzeit so:
[Cisco] Alle Ports außer Port 8 - VLAN 1
Port 8 Access VLAN 3 [3U als administrativ und operativ]
Port 26 General Mode VLAN 1 + 3 untagged [1U, 1P, 2F, 3U]
Ich dachte, das müsste doch schon so funktionieren, ist aber nicht. Cisco-Trunk will ich nicht, da VLAN 2 noch dazukommt (gab es damals auch schon, blenden wir jetzt einfach mal aus) und Port 26 auch dort drin sein muss. (und im Trunk-Mode kann ich nur 1 VLAN eintragen)
Habe auch versucht, dass Port 8 auch im General Mode ist und 1P, 2F, 3U hatte, kein Erfolg.
Was ist mein Denkfehler, verstehe ich das System falsch? Ich dachte, es würde genügen, dass beide 3U haben (weil, war früher so ...). Die pfsense kann aber nicht mit dem Router hinter Port 8 kommunizieren (stecke ich Port 8 ins VLAN 1 dann schon).
Muss mit den Cisco-Dingern doch mehr konfiguriert werden? Muss ich taggen? Muss die pfsense-Konfiguration auch angepasst werden? Ich blick's heute einfach nicht (mehr).
Sonnige Grüße,
André
Please also mark the comments that contributed to the solution of the article
Content-ID: 334669
Url: https://administrator.de/contentid/334669
Printed on: December 3, 2024 at 11:12 o'clock
44 Comments
Latest comment
heute ist Sonntag, ich habe 6h Arbeit hinter mir
Du Armer wo andere faul in der herrlichen Sonne liegen Punkt, mehr war da nicht, es gab kein (un)tagged/trunk whatever, kannte der KTI nicht.
Macht die Sache umso einfacher mit simplen 2 VLANs...So, nun sieht es beim Cisco scheinbar etwas anders aus.
Verglichen mit einem ungemanagten Dummswitch kann man diese Erkenntnis sicher bejahen.Da du kein Tagging machst (jedenfalls sagst du dazu nix) sind alle Ports bei dir untagged Accessports und dein Port Konfig sollte so aussehen:
(Sorry für den verirrten 3ten roten Kreis !)
Was du ja jetzt mit Trunk Mode rumfaselst ist unklar. denn ein Trunk ist eine Link Aggregation also das Bündeln von gleich konfigurierten Ports zu einem virtuellen zu Bandbreite Erhöhung. Mit Tagging usw. hat das erstmal nix zu tun. Und von Trunking redest du hier ja gar nicht.
Was ist mein Denkfehler, verstehe ich das System falsch?
Nee, das sicher nicht, aber scheinbar hapert die einfache VLAN Logik ?! Muss mit den Cisco-Dingern doch mehr konfiguriert werden?
Nöö...Muss ich taggen?
Nöö...jedenfalls nicht bei einfachen Endgeräte Ports. Taggen musst du nur wenn du einem Gerät am anderen Ende die VLAN Konfig mitteilen musst. Sprich VLAN IDs übermitteln das das Gerät gesendeten Paketen vom Cisco das richtige VLAN zuordnen kann.Du schreibst leider nicht ob du an der pfSense einen dediziertn Port für VLAN 3 hast oder einen tagged Port der mehrere VLANs bedient ?
Ein Blick ins hiesige VLAN Tutorial (mit Cisco Konfig) sollte dir aber ganz schnell sonntägliche Klarheit verschaffen
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Wenn ich einen port auf access setzen, dann gilt dieser doch nur für ein VLAN oder sehe ich das falsch?
Ja, das ist absolut korrekt so !Port 26 kann ich also nicht auf Access VLAN 3 setzen, denn dann ist er aus VLAN 1 raus
Auch das ist natürlich richtig !Dann ist aber deine Angabe von oben falsch oder irreführend, denn du hast geschrieben das das Cheffe WLAN das VLAN 3 ist und dort ein Port auf den Accesspoint oder Router geht und Port 26 das VLAN 3 auf die pfSense bringt.
Genau DESHALB nichmal die Nachfrage oben ob die einen dedizierten Port auf der pfSense dafür nutzt oder einen Tagged Port der die VLANs auf Subinterfaces auf der pfSense bedient.
Wenn letzteres der Fall ist musst du natürlich den Port taggen, denn sonst kann die pfSense logischerweise die VLAN ID 3 nicht lesen und zuordnen die der Switch dann mitschickt.
Was ich von "trunk" fasele, siehst du im Bild beim Interface Setting.
Seh ich irgendwie nicht... Vielleicht ist die Sonne zu grell heute Nochmal: Ein Trunk ist eine Link Aggregation also die Zusammenfassung mehrerer physischer, gleicher Links zu einem Virtuellen: Guckst du hier:
Den Screenshot sieht man bei dir nicht...
die pfsense hat auch keine extra VLAN Konfiguration
OK, dann ist das geklärt !Damit MUSS der VLAN 3 Port der pfSense dann auf einen untagged Access Port am Switch der im VLAN 3 hängt !
Siehe Screenshot oben.
und ich hoffte, dass es auch so simpel mit dem Cisco gehen würde
Tut es ja auch....- VLAN 3 anlegen
- Ports untagged zuweisen
- pfSense aufstecken
- Fertisch
Was der KTI konnte, muss doch unproblematisch auch der Cisco können.
Ja klar, das tut er auch.Der KTI ist ein dummer ungemanagter Switch, richtig ?
Das ist der Cisco auch wenn du ihn aus dem Karton auspackst und anschliesst. Alle Ports sind in VLAN 1 und er funktioniert ohne Zutun ebenso wie ein dummer ungemanageter Switch
Versteht man dich aber jetzt richtig willst du 2 vollkommen getrennte Netzwerke auf dem Cisco betreiben. Also so als wenn du 2 separate dumme ungemanagte Switches hast wo der eine VLAN 1 bedient und der andere VLAN 3 (Cheffe)
Das erfordert dann natürlich etwas Konfig auf dem Cisco, da du ja diese 2 getrennten VLANs erzeugen musst...logisch.
Gut mit VLAN 1 hast du quasi schon den einen "getrennten Switch" und mit dem dann eigerichteten VLAN 3 dann den anderen "getrennten Switch".
Klar das man da das VLAN einrichten muss und die Ports dann untagged zuweisen, denn sonst verharren sie ja alle in VLAN 1.
Knackpunkt ist dein Port 26. Der ist falsch eingerichtet. In einem Port based VLAN kann ein Untagged Port logischerweise niemals Mitglied von 2 VLANs sein. Wie sollte das auch gehen ?!
https://supportforums.cisco.com/discussion/11897946/general-vs-trunk-mod ...
Da liegt der Fehler bei dir ! General Mode ist falsch bzw. das setzen multipler untagged VLANs in dem Mode.
Denn empfangsseitig entscheidet immer wieder einzig nur die PVID an dem Port in welches untagged VLAN diese Frames geforwardet werden.
Guckst du auch hier zu dem Thema:
Warum gibt es PVID bei VLANs?
Es ist ganz einfach:
General Ports sind mehr oder minder Unsinn und braucht man nur in sehr seltenen Spezialfällen.
Normal merkt man keinen Unterschied zw. Trunk und General Ports, da im Default auf bei General Ports das Native VLAN immer auf 1 steht und keinerlei multiple untagged VLANs definiert sind.
Deshalb ist die Funktion von Trunk und General auch gleich.
Normal bei Port Based VLANs ist Trunk = Normaler tagged Port und Untagged.
Die Verwirrung mit Trunk usw. ist bei Cisco etwas speziell. In der gesamten Netzwerk Welt sind Trunk Ports immer Port mit Link Aggregation. 802.3ad mit LACP
Einzig Cisco sagt zu einem Tagged Uplink Trunk und bezeichnet Link Aggregation als Etherchannel oder auch Channel.
Deshalb kommt es immer und immer wieder zu Verständigungsproblemen wenn Cisco Leute von Trunks reden und "normale" Netzwerker dann LAGs verstehen. Daher die Verwirrung oben
Alle VLAN 3 Ports auf untagged hätte dein Problem sofort gelöst, denn du hast ja nur untagged Endgeräte im VLAN 3
Alle Ports auf untagged wird dein Problem lösen. So war es früher ja auch. Deshalb ist es umson unverständlicher das du da jetzt mit Tagged Paket hantierst. Konnte der KTI nicht und deshalb hattest du die auch nie... Warum also jetzt das Tagging was keiner deiner Geräte versteht ?!
- Untagged = ist klar das ist ein untagged Endgeräte Port
- Trunk = ist immer festgelegt auf ein festes native VLAN in der Regel ist das VLAN 1. Das native VLAN ist immer das VLAN in das untagged Pakete geforwardet werden an einem tagged Port.
- General = Ist normal das gleiche wie Trunk. Nur mit dem Unterschied das du outbound mehrere untagged VLANs auflegen kannst. Inbound wird aber immer nur eins genommen und nur das dessen PVID du dann setzt.
General Ports sind mehr oder minder Unsinn und braucht man nur in sehr seltenen Spezialfällen.
Normal merkt man keinen Unterschied zw. Trunk und General Ports, da im Default auf bei General Ports das Native VLAN immer auf 1 steht und keinerlei multiple untagged VLANs definiert sind.
Deshalb ist die Funktion von Trunk und General auch gleich.
Normal bei Port Based VLANs ist Trunk = Normaler tagged Port und Untagged.
Die Verwirrung mit Trunk usw. ist bei Cisco etwas speziell. In der gesamten Netzwerk Welt sind Trunk Ports immer Port mit Link Aggregation. 802.3ad mit LACP
Einzig Cisco sagt zu einem Tagged Uplink Trunk und bezeichnet Link Aggregation als Etherchannel oder auch Channel.
Deshalb kommt es immer und immer wieder zu Verständigungsproblemen wenn Cisco Leute von Trunks reden und "normale" Netzwerker dann LAGs verstehen. Daher die Verwirrung oben
VLAN 3 für port 26 auf tagged, konnte dennoch nicht mit dem Router hinter Port 8 kommunizieren.
Das ist auch klar, denn kein Endgerät kann mit Tagged Frames kommunizieren.Alle VLAN 3 Ports auf untagged hätte dein Problem sofort gelöst, denn du hast ja nur untagged Endgeräte im VLAN 3
Und trotz dass er sich dann wohl ins VLAN 3 getagged reingetan hat, kann er nicht mit Port 8 kommunizieren.
Wie gesagt klar...denn deine Endgeräte erwarten alle untagged Frames im VLAN 3. Mit Tagged Paketen können sie nichts anfangen, deshalb klappt das nicht.Alle Ports auf untagged wird dein Problem lösen. So war es früher ja auch. Deshalb ist es umson unverständlicher das du da jetzt mit Tagged Paket hantierst. Konnte der KTI nicht und deshalb hattest du die auch nie... Warum also jetzt das Tagging was keiner deiner Geräte versteht ?!
Hallo zusammen,
das auch immer gerne zur Verwaltung!
2. Lass den Router im WLAN AP laufen und dann das Problem mit der Erreichbarkeit auch glöst.
werden mehr als eine SSID angeboten und jede soll/muss in ein eigenes VLAN rein.
Gruß
Dobby
[KTI] Alle Ports außer Port 8 - VLAN 1
Port 8 (führt zu einem WLAN Router für den Chef [der darf ins Internet, nicht aber unser Hauptnetzwerk]) + Port 26 (pfsense) VLAN 3
1. Lass alles im VLAN1 drinnen das ist das Default VLAN und dort sind immer alle Geräte Mitglied und von daher nimmt der AdminPort 8 (führt zu einem WLAN Router für den Chef [der darf ins Internet, nicht aber unser Hauptnetzwerk]) + Port 26 (pfsense) VLAN 3
das auch immer gerne zur Verwaltung!
2. Lass den Router im WLAN AP laufen und dann das Problem mit der Erreichbarkeit auch glöst.
Punkt, mehr war da nicht, es gab kein (un)tagged/trunk whatever, kannte der KTI nicht. Man hat einfach Ports einer
VLAN-Gruppe zugewiesen und fertig, ein Port in mehreren Gruppen war gar kein Problem.
Ich musste auch nichts extra in der pfsense konfigurieren.
VLANs die zwischen wie Switchen oder einem Switch und einem Router aufgesetzt bzw. werden, werden immer "getaggt".VLAN-Gruppe zugewiesen und fertig, ein Port in mehreren Gruppen war gar kein Problem.
Ich musste auch nichts extra in der pfsense konfigurieren.
Was ist mein Denkfehler, verstehe ich das System falsch? Ich dachte, es würde genügen, dass beide 3U haben
(weil, war früher so ...). Die pfsense kann aber nicht mit dem Router hinter Port 8 kommunizieren (stecke ich Port 8 ins VLAN 1 dann schon).
Zur pfSense hin muss alles tagged sein wenn die die VLANs routen soll und der WLAN AP sollte nur untagged sein, es sei denn dort(weil, war früher so ...). Die pfsense kann aber nicht mit dem Router hinter Port 8 kommunizieren (stecke ich Port 8 ins VLAN 1 dann schon).
werden mehr als eine SSID angeboten und jede soll/muss in ein eigenes VLAN rein.
Gruß
Dobby
VLAN technisch ist das vollkommen falsch. Du belastest den Port massiv mit sinnlosem Traffic aus den VLANs 1 und 2. Dieser Traffic ist für das VLAN 3 ja vollkommen irrelevant.
Dein Problem ist das du einfach nicht verstehst wie das VLAN Tagging funktioniert und was die Trunk und General Ports machen. Sorry...
Nochmal ein letzter Versuch:
Warum willst du überhaupt irgendwas mit einem Trunk oder General Mode machen ?? Allein das ist doch schon Unsinn in deinem Setup. Du hast ausnahmslos doch nur untagged Endgeräteports in dem VLAN3 alles sind ALLE Ports dort reine ACCESS Ports da alle untagged sind.
Wozu also Trunk oder General Ports ?? Das sind Modi die man ausschliesslich benötigt wenn man VLAN Informationen transportieren will. Sprich der Switch sendet oder liest dann VLAN Tags an den Paketen.
Das ist bei dir aber nirgendwo der Fall weil du weder eine Switch zu Switch Kopplung machst noch mit Tagged Subinterfaces an der pfSense arbeitest... Wozu dann also Trunk oder General ??
Was du oben gemacht hast ist eine gruselige Frickelei. Zufällig werden beide Ports untagged im VLAN 3 betrieben, deshalb funktioniert dieses grausige Konstrukt. Aber VLAN 1 und 2 senden da auch noch fröhlich drauf rum und belasten damit ganz massiv die Performance.
Das hätte man sauberer auch mit reinen Access Ports hinbekommen. Denk mal in Ruhe drüber nach !
Übrigens dein TP Link Beispiel geht von einem vollkommen unrealistischen Szenario aus das in beiden VLANs die gleiche IP Adressierung vorhanden ist.
Dann können Geräte in Gruppe 3 nicht mit 4 reden. Klar, da beides unterschiedliche VLANs.
Beide VLANs können aber mit Port 1 reden. Das geht nur wenn die IP Adressierung identisch ist.
Vollkommen irreal sowas, denn wer VLANs hat, der segmentiert natürlich auch immer seine IP Netze und macht nicht so einen Blödsinn wie im TP Link Beispiel.
Vermutlich hast du das auch so gemacht mit dem Cheffe WLAN oder etwa nicht ??
Klassische VLAN Designs sehen so aus.
Dein Problem ist das du einfach nicht verstehst wie das VLAN Tagging funktioniert und was die Trunk und General Ports machen. Sorry...
Nochmal ein letzter Versuch:
Warum willst du überhaupt irgendwas mit einem Trunk oder General Mode machen ?? Allein das ist doch schon Unsinn in deinem Setup. Du hast ausnahmslos doch nur untagged Endgeräteports in dem VLAN3 alles sind ALLE Ports dort reine ACCESS Ports da alle untagged sind.
Wozu also Trunk oder General Ports ?? Das sind Modi die man ausschliesslich benötigt wenn man VLAN Informationen transportieren will. Sprich der Switch sendet oder liest dann VLAN Tags an den Paketen.
Das ist bei dir aber nirgendwo der Fall weil du weder eine Switch zu Switch Kopplung machst noch mit Tagged Subinterfaces an der pfSense arbeitest... Wozu dann also Trunk oder General ??
Was du oben gemacht hast ist eine gruselige Frickelei. Zufällig werden beide Ports untagged im VLAN 3 betrieben, deshalb funktioniert dieses grausige Konstrukt. Aber VLAN 1 und 2 senden da auch noch fröhlich drauf rum und belasten damit ganz massiv die Performance.
Das hätte man sauberer auch mit reinen Access Ports hinbekommen. Denk mal in Ruhe drüber nach !
Übrigens dein TP Link Beispiel geht von einem vollkommen unrealistischen Szenario aus das in beiden VLANs die gleiche IP Adressierung vorhanden ist.
Dann können Geräte in Gruppe 3 nicht mit 4 reden. Klar, da beides unterschiedliche VLANs.
Beide VLANs können aber mit Port 1 reden. Das geht nur wenn die IP Adressierung identisch ist.
Vollkommen irreal sowas, denn wer VLANs hat, der segmentiert natürlich auch immer seine IP Netze und macht nicht so einen Blödsinn wie im TP Link Beispiel.
Vermutlich hast du das auch so gemacht mit dem Cheffe WLAN oder etwa nicht ??
Klassische VLAN Designs sehen so aus.
Da die Geräte hinter dem WLAN Router aber nicht ins Hauptnetzwerk sollen
Klar, das ist ja verständlicherweise der Sinn der Sache. Diese Geräte sind ja alle gewollt im VLAN 3 isoliert und im VLAN 3 sind alle deine Ports untagged Access Ports !Da stecken alle Geräte drin inklusive des WLAN Routers LAN Port. Der WAN Port des WLAN Routers geht dann direkt ohne Switch mit einem Patchkabel auf die pfSense. Und Selbige hat an diesem Port dann entsprechende DENY Regeln das keine Pakete ins Hautpnetz (vermutlich VLAN 1) gehen.
Ein simples Standard Design. Kein Hexenwerk.
Allerdings ist der WLAN Router dort natürlich überflüssiger Blödsinn und sinnloser "NAT Durchlauferhitzer". Genausogut kann man das Netz auch direkt OHNE diesen WLAN Router an die pfSense anschliessen und den WLAN Router dann im VLAN 3 als simplen Accesspoint betreiben:
Kopplung von 2 Routern am DSL Port
Die pfSense macht ja Routing und NAT ! Warum sollte man das davor nochmals machen mit einem WLAN Router ?? Überflüssiger Unsinn, aber egal.
Das Netzdesign hört sich irgendwie wirr und gruselig an. Kann man aber natürlich so machen wenn man es umständlich und kompliziert mag..
Es bleibt aber wieder dabei: die VLAN 3 Ports sind auch in einem sinnvollen Design ohne "Durchlauferhitzer" allesamt immer untagged Access Ports und kein einziger muss als Tagged Trunk oder General Port laufen !
Und nur über diese VLAN-Frickelei funktioniert das Vorhaben.
Das ist absolut korrekt ! Man muss es eben nur richtig machen weil never change ...), ist es wie es ist.
Gruselige Frickelei ohne Plan und ein Performancekiller aber nundenn wenns klappt kann man es so natürlich lassen. Ideal ist es nicht.Warum du dafür dann einen Top Cisco Switch verbraten hast ist vollkommen unverständlich. Dafür hatte ein halb so teuerer TP-Link oder Netgear usw. allemal gereicht.
Aber egal...Case closed.
Dann arbeitet man da am LAN Port mit tagged Subinterfaces. Dann kannst du soviele Ports realisieren wie du VLANs hast , egal wie voll die ist
Siehe Beispiel Tutorial:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Siehe Beispiel Tutorial:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
VLAN ID 3 auf die LAN NIC
Das wäre der richtige Weg gewesen, allerdings musst du dann natürlich das LAN Interface der pfSense auf Tagging umstellen mit Subinterfaces:VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Das native VLAN Interface auf der pfSense LAN Port ist dann dein VLAN 1 und das Parent Interface das VLAN 3 mit den entsprechenden IP Adressen passend zu den verwendeten IP netzen in den VLANs.
Das erfordert auf der anderen Seite dann natürlich zwingend einen Trunk Port, klar !
Dieser schickt dann auch Switchseite (Port 26) alle VLAN 1 Pakete untagged raus und alle VLAN 3 Pakete tagged.
Anhand der am Paket angehängten VLAN ID 3 kann die pfSense dann diesen Traffic eindeutig dem VLAN 3 Subinterface zuordnen und diese daten entsprechend der dann am VLAN3 Interface anliegenden Firewall regeln (alles für VLAN1 blocken) zuordnen.
Alle untagged eingehenden Pakete ordnet die pfSense dann dem VLAN 1 Interface zu.
Alles so wie es sein soll.
Das wäre die Ideallösung gewesen aus dem Bilderbuch wie sie auch im VLAN Tutorial beschrieben ist.
Vielleicht solltest du dich doch nochmal aufraffen und das "schön" machen...?!
Ehrlich, Netzwerke sind wahrlich nicht mein Ding
Was denn sonst Briefmarkensammeln ?? Aber im Ernst: Die Erfahrung die du jetzt mit dem Projekt sammelst bringt dich doch weiter ! Das solltest du auch nicht vergessen.
Ich poste hier nachher mal ein paar Screenshots für dich was genau zu tun ist.
So, hier einmal deine ToDos die du umsetzen musst wenns richtig werden soll.
Als Beispielport in den pfSense Screenshots hier ist der OPT1 Port genommen. Da musst du dann den Port nehmen der bei dir relevant ist. Vermutlich der LAN Port.
Man richtet dann quasi auch an der pfSense einen Trunk Port ein wo Pakete reinkommen aus VLAN 3 mit einem Tag damit die pfSense das erkennt und ebenso Pakete an den Switch mit Tag 3 zurücksendet damit der Switch das VLAN erkennt.
Untagged Pakete bedient die pfSense dann über den Parent Port also den physischen Port. Du benienst also quasi 2 IP netzwerke über einen einzigen physischen Port. Anhand des VLAN Tags kann die pfsense (und auch der Switch auf der anderen Seite) diese IP Pakete immer wieder dem richtigen Interface zuordnen und alles bewegt sich in geregelten IP Netzen...
Los gehts
Als Erstes richtest du unter Interface Assign das VLAN Subinterface ein:
Jetzt das VLAN aktivieren und eine statische IP Adresse als Gateway IP definieren
(Beispiel 10.4.4.1 /24)
Im Überblick siehst du nun deine verfügbaren Interfaces auf der Firewall:
Du kannst hier erkennen am Index re0 das beide Interfaces auf einem gemeinsamen physischen Port liegen. Die pfsense kann aber anahand des VLAN Tags 3 diese Pakete dem virtuellen VLAN Port in diesem Interface zuordnen.
Untagged Pakete bedient sie über den physischen Port.
Hier siehst du nochmal den Überblick der beiden Firewall Ports:
Die gemeinsame Macadresse zeigt das es hardwareseitig ein Port ist.
Jetzt kommt die Gegenseite der Switch dran ! Port G1 ist unser Anschlussport an die pfSense:
Der Port muss jetzt die Pakete aus dem VLAN 3 mit einem VLAN Tag versehen damit die pfSense auf der anderen Seite das wieder ihrem Interface zuordnen kann. Folglich müssen also die Pakete aus dem VLAN 3 an diesem Port getagged werden (Trunk Mode). Der Trunk Mode wird hier eingestellt in den Port Settings:
Nun weist du den Ports das VLAN 3 zu:
Du siehst Port G1 der Port zur FW ist hier Tagged und die beiden anderen Ports G6 und 7 sind deine Untagged Endgeräteports für den Cheffe PC und den WLAN Accesspoint.
Nochmal der Überblick der Portzuweisung am Switch:
G1 ist mit der pfSense Port OPT1 (re0) verbunden.
VLAN 3 tagged und das dDefault VLAN 1 (dein lokales LAN) untagged.
Alles wie es sein soll also.
Wenn du einen DHCP Server in der pfSense aktivierst, was du natürlich machen solltest) für das VLAN3 Subinterface bekommt jetzt der PC schon eine IP von der pfSense und du kannst das pfSense Interface pingen
Das wars !!
In dem Stil kannst du auch noch weitere VLANs auf der pfSense terminieren und über sie routen und den Zugriff in andere Netze steuern.
Frag wenn nochwas unklar ist !
Als Beispielport in den pfSense Screenshots hier ist der OPT1 Port genommen. Da musst du dann den Port nehmen der bei dir relevant ist. Vermutlich der LAN Port.
Man richtet dann quasi auch an der pfSense einen Trunk Port ein wo Pakete reinkommen aus VLAN 3 mit einem Tag damit die pfSense das erkennt und ebenso Pakete an den Switch mit Tag 3 zurücksendet damit der Switch das VLAN erkennt.
Untagged Pakete bedient die pfSense dann über den Parent Port also den physischen Port. Du benienst also quasi 2 IP netzwerke über einen einzigen physischen Port. Anhand des VLAN Tags kann die pfsense (und auch der Switch auf der anderen Seite) diese IP Pakete immer wieder dem richtigen Interface zuordnen und alles bewegt sich in geregelten IP Netzen...
Los gehts
Als Erstes richtest du unter Interface Assign das VLAN Subinterface ein:
Jetzt das VLAN aktivieren und eine statische IP Adresse als Gateway IP definieren
(Beispiel 10.4.4.1 /24)
Im Überblick siehst du nun deine verfügbaren Interfaces auf der Firewall:
Du kannst hier erkennen am Index re0 das beide Interfaces auf einem gemeinsamen physischen Port liegen. Die pfsense kann aber anahand des VLAN Tags 3 diese Pakete dem virtuellen VLAN Port in diesem Interface zuordnen.
Untagged Pakete bedient sie über den physischen Port.
Hier siehst du nochmal den Überblick der beiden Firewall Ports:
Die gemeinsame Macadresse zeigt das es hardwareseitig ein Port ist.
Jetzt kommt die Gegenseite der Switch dran ! Port G1 ist unser Anschlussport an die pfSense:
Der Port muss jetzt die Pakete aus dem VLAN 3 mit einem VLAN Tag versehen damit die pfSense auf der anderen Seite das wieder ihrem Interface zuordnen kann. Folglich müssen also die Pakete aus dem VLAN 3 an diesem Port getagged werden (Trunk Mode). Der Trunk Mode wird hier eingestellt in den Port Settings:
Nun weist du den Ports das VLAN 3 zu:
Du siehst Port G1 der Port zur FW ist hier Tagged und die beiden anderen Ports G6 und 7 sind deine Untagged Endgeräteports für den Cheffe PC und den WLAN Accesspoint.
Nochmal der Überblick der Portzuweisung am Switch:
G1 ist mit der pfSense Port OPT1 (re0) verbunden.
VLAN 3 tagged und das dDefault VLAN 1 (dein lokales LAN) untagged.
Alles wie es sein soll also.
Wenn du einen DHCP Server in der pfSense aktivierst, was du natürlich machen solltest) für das VLAN3 Subinterface bekommt jetzt der PC schon eine IP von der pfSense und du kannst das pfSense Interface pingen
Das wars !!
In dem Stil kannst du auch noch weitere VLANs auf der pfSense terminieren und über sie routen und den Zugriff in andere Netze steuern.
Frag wenn nochwas unklar ist !
Glückwunsch !! Du siehst mit Plan und etwas Nachdenken klappt das alles....! Und deine gewonnenen Erfahrungen sind unbezahlbar.
Zu deinen Regeln:
Bedenke das das Regelwerk in der pfSense immer nur inbound gilt. Also für IP Pakete die aus dem Netzwerkkabel in die Firewall reingehen.
Dein Regelwerk am VLAN 3 Interface sollte also grob so aussehen:
VLAN 3 Interface Chef WLAN:
PASS Source: <IP_host_adresse_router>, Port:any, Destination: <lan_net>, Port: any
BLOCK Source: <vlan3_net>, Port:any, Destination: <lan_net>, Port: any
PASS Source: <vlan3_net>, Port:any, Destination: any, Port: any
Hier kannst du sehen das die Regel der Reihe nach arbeitet und...
Deshalb ist die Reihenfolge der Regelanweisungen immer sehr wichtig.
Hier könntest du jetzt noch etwas mehr einschränken wenn der Router z.B. ein GUI hat und du nur HTTP Zugriff erlauben willst (Browserzugang) auf ihn. Dann könnte man die erste Regel noich etwas enger fassen ala:
PASS Source: <IP_host_adresse_router>, Port:any, Destination: <lan_net>, Port: HTTP (TCP 80)
Wenn du im LAN eine feste IP Adresse hast kannst du das sogar noch dichter machen das nur du Zugriff hast auf den Router. Mit der Regel von oben wird der Router IP (und nur der) generell der Zugang ins LAN Netzwerk erlaubt. D.h. auch andere im LAN können so den Router erreichen.
Wenn du das enger haben willst dann muss das so aussehen:
PASS Source: <IP_host_adresse_router>, Port:any, Destination: <skyemugen_lan_host_ip> Port any
Aber Vorsicht hier !!
Ohne feste IP ist das gefährlich, denn ändert die sich mal durch DHCP bist du Gefangener deiner eigenen Firewall Regel.
Wenn die pfSense hier im LAN die IPs per DHCP vergibt kannst du das aber regeln indem du dem DHCP Server im Setup sagst das er deiner Rechner Mac Adresse immer eine feste IP vergeben soll. So bekommst du auch dynamisch per DHCP immer eine feste IP am Rechner und kannst nie an der regel hängenbleiben. Andere DHCP Server (Windows etc.) können das auch. So schaffst du Sicherheit wenn du mit der engen Regel arbeiten willst.
Das gilt übrigens auch für die Router IP im VLAN 3.
Die Regel geht davon aus das die Router IP statisch ist. Die darf sich natürlich auch nicht ändern (DHCP etc.). Ist aber vermutlich eh statisch definiert und damit dann sicher.
Das sollte als Regelwerk schon reichen da ja der Zugriff vom VLAN 3 ins LAN schon verboten ist durch die Regel am VLAN 3 Interface kann auch kein Traffic vom LAN ins VLAN 3 (außer deiner IP bzw. der des Routers in VLAN 3)
Eine extra Regel am LAN Interface ist deshalb nicht mehr erforderlich !
Damit sollte das dann auch final klappen.
Zu deinen Regeln:
Bedenke das das Regelwerk in der pfSense immer nur inbound gilt. Also für IP Pakete die aus dem Netzwerkkabel in die Firewall reingehen.
Dein Regelwerk am VLAN 3 Interface sollte also grob so aussehen:
VLAN 3 Interface Chef WLAN:
PASS Source: <IP_host_adresse_router>, Port:any, Destination: <lan_net>, Port: any
BLOCK Source: <vlan3_net>, Port:any, Destination: <lan_net>, Port: any
PASS Source: <vlan3_net>, Port:any, Destination: any, Port: any
Hier kannst du sehen das die Regel der Reihe nach arbeitet und...
- Nur die Host IP Adresse des Routers als Absender mit einer Zieladresse im LAN erlaubt. (Du oder auch alle im LAN Segment können auf den Router zugreifen)
- Generell sonst den ganzen IP Rest aus VLAN 3 ins LAN Netzwerk verbietet
- und dann den Rest aus VLAN 3 ins Internet erlaubt.
Deshalb ist die Reihenfolge der Regelanweisungen immer sehr wichtig.
Hier könntest du jetzt noch etwas mehr einschränken wenn der Router z.B. ein GUI hat und du nur HTTP Zugriff erlauben willst (Browserzugang) auf ihn. Dann könnte man die erste Regel noich etwas enger fassen ala:
PASS Source: <IP_host_adresse_router>, Port:any, Destination: <lan_net>, Port: HTTP (TCP 80)
Wenn du im LAN eine feste IP Adresse hast kannst du das sogar noch dichter machen das nur du Zugriff hast auf den Router. Mit der Regel von oben wird der Router IP (und nur der) generell der Zugang ins LAN Netzwerk erlaubt. D.h. auch andere im LAN können so den Router erreichen.
Wenn du das enger haben willst dann muss das so aussehen:
PASS Source: <IP_host_adresse_router>, Port:any, Destination: <skyemugen_lan_host_ip> Port any
Aber Vorsicht hier !!
Ohne feste IP ist das gefährlich, denn ändert die sich mal durch DHCP bist du Gefangener deiner eigenen Firewall Regel.
Wenn die pfSense hier im LAN die IPs per DHCP vergibt kannst du das aber regeln indem du dem DHCP Server im Setup sagst das er deiner Rechner Mac Adresse immer eine feste IP vergeben soll. So bekommst du auch dynamisch per DHCP immer eine feste IP am Rechner und kannst nie an der regel hängenbleiben. Andere DHCP Server (Windows etc.) können das auch. So schaffst du Sicherheit wenn du mit der engen Regel arbeiten willst.
Das gilt übrigens auch für die Router IP im VLAN 3.
Die Regel geht davon aus das die Router IP statisch ist. Die darf sich natürlich auch nicht ändern (DHCP etc.). Ist aber vermutlich eh statisch definiert und damit dann sicher.
Das sollte als Regelwerk schon reichen da ja der Zugriff vom VLAN 3 ins LAN schon verboten ist durch die Regel am VLAN 3 Interface kann auch kein Traffic vom LAN ins VLAN 3 (außer deiner IP bzw. der des Routers in VLAN 3)
Eine extra Regel am LAN Interface ist deshalb nicht mehr erforderlich !
Damit sollte das dann auch final klappen.
Die Regeln sind syntaktisch genau richtig !
Aber Frage was den Router im Chef WLAN anbetrifft ??:
Arbeitet der als Router ?? Sprich werden die Internet Verbindungen dann nicht zentral über die Firewall abgewickelt sondern über diesen Router ??
Wenn das der Fall ist (und dananch sieht das regelwerk aus) dann musst du zwingend nich in den Advanced Settings unter:
System -> Advanced -> Firewall & NAT
den dortigen Haken bei Bypass firewall rules for traffic on the same interface setzen !
Dann passt das auch mit deinem Zugriff.
Die LAN Regel ist unverständlich !
Die Firewall regelt doch den Zugriff ins Chef WLAN und als Gateway für die Endgeräte im LAN und auch VLAN 3 ist doch die pfSense aktiv, oder ?
Das Gateway muss da nur rein wenn sie es nicht ist ! Und auch dann gilt wieder der Haken von oben !
Aber Frage was den Router im Chef WLAN anbetrifft ??:
Arbeitet der als Router ?? Sprich werden die Internet Verbindungen dann nicht zentral über die Firewall abgewickelt sondern über diesen Router ??
Wenn das der Fall ist (und dananch sieht das regelwerk aus) dann musst du zwingend nich in den Advanced Settings unter:
System -> Advanced -> Firewall & NAT
den dortigen Haken bei Bypass firewall rules for traffic on the same interface setzen !
Dann passt das auch mit deinem Zugriff.
Die LAN Regel ist unverständlich !
Die Firewall regelt doch den Zugriff ins Chef WLAN und als Gateway für die Endgeräte im LAN und auch VLAN 3 ist doch die pfSense aktiv, oder ?
Das Gateway muss da nur rein wenn sie es nicht ist ! Und auch dann gilt wieder der Haken von oben !
OK, aber dann arbeitet er NICHT mehr als Router und verhält sich dann wie ein reines Endgerät bzw. ein einfacher AP.
Dann ist deine Regel OK und du musst den Haken nicht setzen, denn der Traffic rennt ja dann durch die FW.
Allerdings ist deinen Aussage der Router hat somit kein Gateway dann natürlich fatal.
Wie soll dann ein Zugriff aus einem anderen Netz auf den Router passieren ??
Ein Gateway ist dann hier doch zwingend erforderlich.
Stell dir vor die Management Pakete von deinem PC im LAN mit der Absender IP 10.1.1.1 /24 kommen dann am Router an der in VLAN 3 mit der Adresse 10.3.3.3 /24 sitzt.
Der will dann wieder an deinen PC 10.1.1.1 antworten, sendet ein IP Paket mit der Zieladresse 10.1.1.1 und Absender Adresse 10.3.3.3 und merkt aber das das in einem ganz anderen IP Netz ist (seins ist ja die 10.3.3.0 !) also "sieht" er erstmal in seine eigene lokale Routing Tabelle um einen Weg ins 10.1.1.0 Netz zu finden.
Dort in der Routing Tabelle steht jetzt nichts drin !
Weder eine dedizierte IP Route noch ein Default Gateway. Was nun...?
Damit kann er das Antwort IP Paket also nur noch wegschmeissen (Paket Drop), da er es nicht loswerden kann. Was er dann auch sofort tut mit der Folge das du im Browser nix siehst !
Einfachste IP Logik wie Pakete ihr Ziel finden...
Ohne Gateway IP auf dem Router ist das dann auch vollkommen klar das das nicht gehen kann. Hättest du aber mit Nachdenken auch selber drauf kommen können !
Also....setz dem Routerteil eine Gateway IP auf die pfSense IP in VLAN 3 dann klappt das auch sofort !
Kleine Ursache....
Dann ist deine Regel OK und du musst den Haken nicht setzen, denn der Traffic rennt ja dann durch die FW.
Allerdings ist deinen Aussage der Router hat somit kein Gateway dann natürlich fatal.
Wie soll dann ein Zugriff aus einem anderen Netz auf den Router passieren ??
Ein Gateway ist dann hier doch zwingend erforderlich.
Stell dir vor die Management Pakete von deinem PC im LAN mit der Absender IP 10.1.1.1 /24 kommen dann am Router an der in VLAN 3 mit der Adresse 10.3.3.3 /24 sitzt.
Der will dann wieder an deinen PC 10.1.1.1 antworten, sendet ein IP Paket mit der Zieladresse 10.1.1.1 und Absender Adresse 10.3.3.3 und merkt aber das das in einem ganz anderen IP Netz ist (seins ist ja die 10.3.3.0 !) also "sieht" er erstmal in seine eigene lokale Routing Tabelle um einen Weg ins 10.1.1.0 Netz zu finden.
Dort in der Routing Tabelle steht jetzt nichts drin !
Weder eine dedizierte IP Route noch ein Default Gateway. Was nun...?
Damit kann er das Antwort IP Paket also nur noch wegschmeissen (Paket Drop), da er es nicht loswerden kann. Was er dann auch sofort tut mit der Folge das du im Browser nix siehst !
Einfachste IP Logik wie Pakete ihr Ziel finden...
Ohne Gateway IP auf dem Router ist das dann auch vollkommen klar das das nicht gehen kann. Hättest du aber mit Nachdenken auch selber drauf kommen können !
Also....setz dem Routerteil eine Gateway IP auf die pfSense IP in VLAN 3 dann klappt das auch sofort !
Kleine Ursache....
Das Häkchen bei Bypass ... bringt auch keine Änderung.
Nee, logo...das ist dann ja auch nicht der Grund ! Kannst du aber drinlassen stört nicht !
Du kannst sie aber manchmal dann mit DHCP überlisten und wäre einen Versuch wert, denn ohne Gateway Adresse bist du natürlich verloren...
Der Trick geht folgendermaßen:
Sonst den Chinaböller entsorgen und was schöneres kaufen was damit umgehen kann:
http://varia-store.com/Wireless-Systeme/MikroTik-RouterBoard/MikroTik-c ...
oder mit etwas mehr Power:
http://varia-store.com/Wireless-Systeme/MikroTik-RouterBoard/MikroTik-R ...
Sieht schick aus fürs Cheffe Büro und bei dem Preis bezahlt er das aus seiner Portokasse
Eingehende Verbindungen wie deine zur Fernwartung bleiben dann an der NAT Firewall hängen.
Vom Regen in die Traufe also.
Fazit: Schmeiss den Chinaböller wech und setz dem Cheffe den kleinen 30 Euro AP an die Wand oder Decke. Erspart dir ne Menge graue Haare.
Der Trick geht folgendermaßen:
- LAN Mac (Hardware) Adresse des Routers merken und aufschreiben
- DHCP auf der pfSense für das Cheffe WLAN (VLAN 3 Interface) aktivieren wenn nicht eh schon geschehen.
- Im DHCP Server unter DHCP Static Mappings for this Interface die Mac und die feste IP eingeben
- LAN Port im Router von Static auf DHCP umstellen und danach rebooten.
Sonst den Chinaböller entsorgen und was schöneres kaufen was damit umgehen kann:
http://varia-store.com/Wireless-Systeme/MikroTik-RouterBoard/MikroTik-c ...
oder mit etwas mehr Power:
http://varia-store.com/Wireless-Systeme/MikroTik-RouterBoard/MikroTik-R ...
Sieht schick aus fürs Cheffe Büro und bei dem Preis bezahlt er das aus seiner Portokasse
Müsste ich also doch wieder WAN nutzen, zwischen pfsense und Router einen anderen Netzwerkbereich als wie die WLAN
Stimmt das wäre dann der Workaround aber nützt dir letztlich nichts, denn dann hast du durch das feste NAT (IP Adress Translation) am WAN Port eine Einbahnstrasse.Eingehende Verbindungen wie deine zur Fernwartung bleiben dann an der NAT Firewall hängen.
Vom Regen in die Traufe also.
Fazit: Schmeiss den Chinaböller wech und setz dem Cheffe den kleinen 30 Euro AP an die Wand oder Decke. Erspart dir ne Menge graue Haare.
kann ja keiner vorher ahnen, dass die zwar als AP laufen können aber nachher nicht mit VLAN + Zugriff spielen.
Sorry, aber das ist ein klein wenig blauäugig wenn man billigste Chinaböller der untersten Kategorie kauft um ggf. noch den letzten Euro zu sparen. Sowas rächt sich in einem Firmennetz so gut wie immer, dein Beispiel beweist es. Das sollte man dann eigentlich immer auf dem Radar haben wenn man beim Blödmarkt ganz unten ins Regal greift. Wie immer gilt die alte Binsenweisheit: Wer billig kauft kauft zweimal.Einen Dacia kaufst du ja auch nicht in der irrigen Annahme damit 250 auf der Autobahn heizen zu können. Oder wenn, dann sollten spätestens beim Anblick leichte Zweifel aufkommen. Genau wie beim China Billig AP....
Aber popelige 28 Euronen für einen mehr als anständigen AP der zudem noch besser aussieht sollte doch für den Cheffe und seinen Etat nun wahrlich kein Problem sein. Oder betreibst du/ihr eine Würstchenbude wo du auch den den alletzten Euro sparen musst ???
wir haben Zwischendecken mit Panels
Ist doch gar nicht mal so schlecht. Da musst du nix anbringen. Den AP schmeisst du einfach auf die Zwischendecke und lässt ihn dadurch funken ist ja nur Gips und Pappe und kein Hindernis für 2,4 Ghz.Man sieht nix, muss nicht bohren und WLAN geht trotzdem. Der MT hat sogar PoE wo der Strom übers Patchkabel kommt und einem das Gefrickel mit dem Steckernetzteil erspart. Was will man mehr...?!
Aber wozu lange reden wenns eh auch bei Bagatellsummen am pedantischen Buchalter scheitert. Ist ja auch sein Job. Wenn dann musst du immer direkt zum Cheffe gehen. Der kann dann auch den Buchhalter "überstimmen". OK diese Spielchen kennst du alle selber viel besser....
So ein Gerät wollte ich dann auch so für ein Gäste-WLAN nutzen
Doch dann wohl nicht nochmal so einen schrottigen TP-Link ?? So ein Negativbeispiel sollte dir doch reichen, oder bist du Masochist ? gegen einen schon irgendwo rumstehenden richtigen AP
Besser ist das... !da WLAN für Monteure im gleichen Netz...
...wie der Cheffe ?? Oha...wenn das mal gut geht. Hoffentlich Grobmotoriker und keine "IT Monteure" mit Hacker Ambitionen ?! Der neue Chef (Sohn) sitzt immer noch auf einem defekten Stuhl,
OK, dann ist wohl jede weitere, wie auch immer geartete Argumentation aussichtslos da wird jetzt niemand nen Kabelkanal zur Decke montieren
Das wär jetzt der richtige Schritt aber kostet... und dann gilt wieder: siehe oben !sondern nur rumstehen, einstauben und bissl Netzwerkverkehr durchlassen
Dann reicht das natürlich, keine Frage. Wäre aber natürlich Unsinn wenn du fürs gleiche Geld was bekommst was das Problem nicht hat !ich kann mir erst dann über Dinge Gedanken machen, wenn ich darüber Bescheid weiß
Eine richtige und weise Erkenntnis dort kann man nur manuell eine IP und Subnetzmaske eingeben.
Schade eigentlich, aber dann musst du damit leben....Ich könnte den WAN-Weg aber nutzen
Nein !Das geht nicht (oder nur mit Aufwand) und scheitert an der NAT Firewall des Routers. An der bleibst du hängen wenn du von Extern eine GUI oder andere Session auf die WAN IP Adresse ausführen wird.
Das klappt nur wenn du dann ein Port Forwarding z.B. für TCP 80 erlaubst oder...wenn der Router im Setup HTTP Verbindungen auf seine WAN IP erlaubt.
Dann geht das natürlich auch.
Aber was solls...warum frickeln wenns jetzt rennt. Da musst du nix mehr groß konfigurieren und wenn dann gehst du eben ins Cheffe Büro wie oben schon geschrieben und jutt iss...
Case closed...
Enable AP Isolation
Das bedeutet was ganz anderes nämlich das sie die WLAN Clients untereinander in einer AP Funkzelle NICHT erreichen können. Sprich damit ist dann eine Any zu Any Kommunikation der Clients direkt untereinander unterbunden. Man kann dann nur via AP in die daran angeschlossene Infrastruktur.Macht Sinn bei Hotspots und Gäste WLANs damit die sich ncht untereinander hacken und beschnüffeln
APs "sehen" sich immer untereinander. Logisch, denn sie verhalten sich ja wie normale Endgeräte im Netz.
Mit korrekter IP am LAN Port musst du also beide APs pingen können.
Bei dir natürlich nur solange du im gleichen LAN Segment bist wegen des fehlenden Gateways
Aber du hast alles richtig gemacht.
Du musst nur aufpassen das du keine doppelten IP Netze hast. Auch wenndu das WLAN Netz jetzt ja via NAT im VLAN 3 Netzwerk "versteckst" ist es besser Netze einzigartig zu halten. Sprich das LAN WLAN hinter dem Router sollte nirgends doppelt in deinem Netz sein.
Ansonsten alles richtig gemacht !