09.04.2017, aktualisiert am 10.04.2017

7477

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é

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 334669

Url: https://administrator.de/contentid/334669

Ausgedruckt am: 23.11.2024 um 13:11 Uhr

44 Kommentare

Neuester Kommentar

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?
Port 26 kann ich also nicht auf Access VLAN 3 setzen, denn dann ist er aus VLAN 1 raus (excluded).

Ich bringe die aktuelle Konfiguration mal bildlicher.

Was ich von "trunk" fasele, siehst du im Bild beim Interface Setting. Nein, bisher habe ich nie mit tagged gearbeitet, die pfsense hat auch keine extra VLAN Konfiguration (Port/Interface), denn das war mit dem simplen KTI nie notwendig (und ich hoffte, dass es auch so simpel mit dem Cisco gehen würde).

Das VLAN Tutorial war für mich beim Überliegen schon etwas Overkill in input, weil ich innerlich daran festhielt: Was der KTI konnte, muss doch unproblematisch auch der Cisco können.

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?

Meine Angabe war irreführend?

Port 8 Access VLAN 3 [3U als administrativ und operativ]
Port 26 General Mode VLAN 1 + 3 untagged [1U, 1P, 2F, 3U]

Hm. den link habe ich heute auch schon gesehen, passte mir nicht mit den Möglichkeiten in der UI zusammen.

Ich weiß jetzt nicht, auf was ich das Interface einstellen soll, wenn Access nur für 1 VLAN gilt ... ich habe doch sonst wie im obigen Screenshot (Trunk Mode Membership) zu sehen nur General, Trunk oder Customer weiter zur Auswahl.

Wähle ich Access, gilt nur 1 VLAN, fällt raus.
Wähle ich Trunk, hat er "native" das VLAN 1 und dann kann ich zusätzlich als tagged VLAN 3 einstellen ... und dabei hat er sich jetzt aus dem 1 rausgeschmissen und ich kann erstmal gar nix weiter machen (da die FW mit OpenVPN dranhängt ... läuft)
Und sonst gab es nur General Mode, wo ich den Port für mehrere VLANs einstellen kann, habe eben zuvor dort 3U auf 3T gewechselt, also VLAN 3 für port 26 auf tagged, konnte dennoch nicht mit dem Router hinter Port 8 kommunizieren.

Naja, jetzt hab ich den Zugang scheinbar aus dem VLAN 1 rausgeworfen und darf morgen wieder sehr früh in die Firma. Arbeiten und Eishockey schauen funktioniert nicht parallel. Und trotz dass er sich dann wohl ins VLAN 3 getagged reingetan hat, kann er nicht mit Port 8 kommunizieren.

Es ist ganz einfach:

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,

[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 Admin
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".

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
werden mehr als eine SSID angeboten und jede soll/muss in ein eigenes VLAN rein.

Gruß
Dobby

Tut mir leid, du verwirrst mich. Alle VLAN 3 ports sollen untagged sein, genau das habe ich bei port 26 mit dem general mode doch versucht ... denn mit trunk kann ich doch nur VLAN 1 untagged, der Rest ist dann tagged. Also 1U, 2-3T.

2. Lass den Router im WLAN AP laufen und dann das Problem mit der Erreichbarkeit auch glöst.

Dann würde das Netzwerk dahinter im gleichen Bereich liegen wie unser Hauptnetzwerk.

Zur pfSense hin muss alles tagged sein wenn die die VLANs routen soll

Die pfsense soll eigentlich keine VLANs routen, der Switch soll die VLANs hantieren, port 26 soll einfach nur mit allen VLANs kommunizieren können.

So, gelöst.

Danke an TP-Link [Ironie des Tages]

http://www.tp-link.de/faq-329.html

Port 8 und Port 26 im General Mode

Port 8 - 1U, 2F, 3U, 3P
Port 26 - 1U, 1P, 2F, 3U

Fertig. Punkt. Funktioniert genauso wie mit den KTI früher. WLAN Router kann mit Firewall, sieht das restliche Netzwerk aber nicht und Firewall kann mit WLAN Router.

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.

192.168.100.254/24 (pfsense) - port 26 - port 8 - 192.168.100.152 (WLAN Router WAN) - 192.168.63.252/48 (WLAN Router LAN)
Da die Geräte hinter dem WLAN Router aber nicht ins Hauptnetzwerk sollen, sondern nur Internet von der pfsense beziehen sollen, steht da ein WLAN Router und bekommt Internet von der pfsense am WAN-Port.
Und nur über diese VLAN-Frickelei funktioniert das Vorhaben.

Wie gesagt: KTI kannte kein tagged und den ganzen Schmu, daher habe ich das auch nicht in irgendwelche Betrachtungen gezogen und alles so eingerichtet wie beschrieben. Und weil ich jetzt die ganze Konfiguration auch so lassen wollte (weil never change ...), ist es wie es ist.

Ja, ich versteh's wohl nicht und erst hieß es: Es muss tagged, dann mit tagged geht es nicht, half mir auch nicht weiter, sorry.

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.

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.

Die pfsense hat keine freien Interfaces mehr, da ist nix mit direkt drauf. 1x LAN, 1x ADSL, 1x LTE, 1x SDSL = ist voll.

Und der Cisco wurde bestimmt nicht wegen dem Chef VLAN angeschafft ...

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

Vermutlich habe ich das dann auch falsch umgesetzt, denn das hatte ich versucht.
VLAN ID 3 auf die LAN NIC, 192.168.100.5 als Static IP, für die VLAN rules sämtlichen traffic rein/raus auf pass und die IP beim Router als Gateway eingetragen.

War dann wohl so nicht richtig, wie es scheint. Also die VLAN Subinterface IP aus dem 192.168.63er Segment nehmen, wenn der Router zum AP degradiert wird? Mich verwirrt, wie ein tagged subinterface dann mit dem untagged access port 8 kommuniziert (das ist auch das, was mich beim Trunk verwirrt, wenn weitrere VLANs im Switch tagged sind und die anderen Mitglieder untagged) ...

Ehrlich, Netzwerke sind wahrlich nicht mein Ding, Programmierung und der ganze Käse ist alles kein Hit aber Routen und Traffic und das Zeugs, da schaltet mein Hirn nicht mit.

Gern probiere ich es dann noch einmal auf dem richtigen Wege, wenn ich die Wegweiser richtigen lesen könnte ...

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.

Ich poste hier nachher mal ein paar Screenshots für dich was genau zu tun ist.

Ja, das fände ich großartig. Mir fällt rekursives Lernen einfacher als vor'm Fluss zu stehen und die Steine zu suchen, wo ich drüber soll *lach*

Heute werde ich das Projekt aber nicht mehr anfassen, nur noch darüber nachdenken. Stundenausgleich ^^ halber Tag frei.

Aber ich finde deine Geduld bemerkenswert und bin für deine sachdienliche Hilfestellung sehr dankbar.

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 !

Super, dann war ich mit meinem VLAN Subinterface ja schon auf der richtigen Spur (den port 26 hatte ich auch auf Trunk gesetzt bei dem Test, nur war der WLAN Router eben noch Router und ich hatte es im gleichen Netz wie das LAN belassen ... und so haben die beiden dennoch nicht miteinander kommuniziert).

Werde ich morgen dann so umsetzen, einzig eine Sache bereitet mir etwas Kopfzerbrechen (da weicht mein Cisco von deinen Bildern ab):
Interface Settings, unter den Trunk-Einstellungen beim Port ist bei mir bereits die Angabe nach dem tagged VLAN festzulegen.

Trunk Mode Membership
Native VLAN ID: 1 (klar)
Tagged VLANS:All VLANs (dann sind alle anderen existierenden tagged)
________________User Defined (da hattee ich ja gestern Abend testweise die 3 eingetragen, dann war der Port nicht mehr für das native VLAN 1 erreichbar ...)

Ich hoffe also, dass ich das bei Port To VLAN auch dementsprechend korrigieren kann, dass dann wirklich nur VLAN 3 tagged ist (erstmal).

Aber das sehe ich dann morgen.

Bis dahin erneuten Dank für deine ausführlichen Screenshots. Eigentlich ist es gar nicht mehr unklar, nur hat mich das ganze Geschreibe und Gelese von tagged muss, tagged darf nicht, tagged sollte doch zu sehr verwirrt. (Zwischenzeitlich klang es so, als ob das tagged bis zum Gerät hinter Port 8 durchgereicht wird, daher fragte ich mich dann, wie tagged und untagged miteinander kommunizieren sollen.)

Hat alles wunderbar geklappt. Eine Regel, dass WLANChef net auf alles außer LAN net zugreifen darf, steht auch.

Nur eine Frage: Wenn ich jetzt von meinem PC (im LAN net) aus auf den WLAN Router Zugreifen will, genügen dazu Firewall Regeln (momentan habe ich auf dem LAN Interface eingestellt, dass meine LAN IP auf WLANChef net zugreifen darf, nutzt nix) oder muss meine Anfrage auch im 3T sein? (Ich hoffte, dass meine Anfrage zur FW geht [WLANChef Interface IP ist ja erreichbar] und diese dann darüber ins VLAN 3 getagged weitergeleitet wird.)

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...

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.

Sowie es einen Match gibt wird der Rest des Regelwerks nicht mehr abgearbeitet (First match wins Regel !)
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.

Hm, die Regeln auf dem VLAN 3 Interface sehen so aus:

ID	Proto	Source	Port	Destination	Port	Gateway
*	IPv4 *	wlan_router_ip	*	LAN net	*	*	Pass
*	IPv4 *	WLANChef net	*	! LAN net	*	GW_WAN	Pass

Da ich aufgrund von Gatewaygroups im LAN die Gateways definiert habe, musste ich natürlich auch eine LAN Regel setzen, sonst geht die Anfrage ins Internet.

ID	Proto	Source	Port	Destination	Port	Gateway
*	IPv4 *	mein_pc_ip	*	WLANChef net	*	GW_LAN	Pass

Dennoch erreiche ich den WLAN Router nicht (erinnert mich an das alte: Ich erreiche den Speedport in der Außenstelle nicht Problem).
Hatte anfangs als test im VLAN alles auf any und pass und im LAN auch ohne Gateway, kein Erfolg.

(In meinem Netzwerk gibt es nur statische IP-Adressen, kein dynamisches DHCP.)

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 !

Naja, es ist nunmal ein WLAN Router, AP ist er dadurch, dass nichts am WAN Port anliegt, sondern nur das LAN konfiguriert ist (der Router hat somit kein Gateway) und der PC dahinter die pfsense als Gateway hat. Firewall am Router ist auch deaktiviert.

Ich kann den Router von der pfsense aus anpingen, nicht aber von meinem PC. Tracert geht nur bis zur VLAN Interface IP.

Zur LAN-Regel wie gesagt: Ich nutze Multiwan mit Gatewaygruppen. Es gibt also Lanregeln wie: Büro - Gatewaygruppe 1; Praktikanten - Gatewaygruppe 2. Ich nutze derzeit explizit das SDSL Gateway, weil unser LTE-Traffic sonst zu schnell aufgebraucht wird. Wenn ich dann keine LAN-Regel setze (noch vor den Internetgatewayregeln), dass meine Anfrage über das LAN Interface gehen soll, geht mein tracert (WLAN Router IP) ins Internet und nicht über die VLAN Interface IP.
E: Gut, ich muss das Gateway nicht eintragen, tracert geht auch ohne aber die LAN-Zugriffsregel aufs WLANChef net muss ich haben, sonst geht die Anfrage ins Internet. Ping bleibt erfolglos.

Das Häkchen bei Bypass ... bringt auch keine Änderung.

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....

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 !

Bei den TP-Link Routern(!) kannst du im LAN kein Gateway eintragen, das geht nur bei richtigen APs. Gateway-Feld gibt es nur für die WAN-Seite.

Müsste ich also doch wieder WAN nutzen, zwischen pfsense und Router einen anderen Netzwerkbereich als wie die WLAN Endgeräte haben und Firewall aus um nicht doppelt zu NATen?

Oder ich lasse es wie es ist und laufe zur Not die 12 Treppenstufen nach oben :D

E: Auch eine statische Route einzurichten, nutzt nix, denn diese gilt auch nur für WAN ... narf.

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:

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.

Jetzt bekommt der Router am LAN die Gateway IP per DHCP "augezwungen". Bei 50% dieser Billigrouter funktioniert dieser "Trick" Vielleicht hast du eine Chance damit.
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.

Ich probier mal den DHCP Trick, die Geräte die wir haben, sind alle erst angeschafft worden, kann ja keiner vorher ahnen, dass die zwar als AP laufen können aber nachher nicht mit VLAN + Zugriff spielen.
Neues wird jedoch nicht angeschafft, da sitzt mir die Buchhaltung gleich im Nacken (ja, auch wegen der kleinen Summen, besonders wenn es dann auch noch irgendwo angebracht werden muss [wir haben Zwischendecken mit Panels]). Und solange der Router/AP dann läuft, läuft er und muss ja eig. auch nicht weiter administriert werden (zur Not eben mit Netbook dran oder vom Chef PC).

So ein Gerät wollte ich dann auch so für ein Gäste-WLAN nutzen (für Schulungen mit Externen), da tausche ich dann besser gleich den einen neuen Router gegen einen schon irgendwo rumstehenden richtigen AP (wo kein VLAN genutzt wird, da WLAN für Monteure im gleichen Netz).

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, das sollte dir als Sinnbild in Sachen notwendige finanzielle Ausgaben genügen

Mit Patchkabel in die Zwischendecke ist nicht, da sind keine und da die Netzwerkdosen alle brav im Kabelkanal unter den Fenstern sind ... fällt jedenfalls raus. (da wird jetzt niemand nen Kabelkanal zur Decke montieren)

Schrottig und Chinaböller hin oder her, die Dinger sollen auch keine Wunder bewirken, sondern nur rumstehen, einstauben und bissl Netzwerkverkehr durchlassen. Das ist was TP-Link auch kann (und die Dinger halten auch viele Jahre, nicht wie so mancher Linksys und Netgear die wir so hatten). Und für 28€ netto gab's immerhin schon zwei von den Dingern ^^

Cheffe (Sr.) hat oben sein eigenes Netzwerk (nur keine Dose, da ist nur eine in einer nichtgenutzten Privatwohnung, wo jetzt sein WLAN-Router dranhängt), die Monteure sind im Hauptnetzwerk mit ihren Firmenhandys (Bilderübertragung, Systemeinbuchung) und die sind i.d.R. nichtmal in der Lage, einen WLAN Zugang einzurichten. Hm, sicher könnte man das mit VLAN sogar noch restriktiver fahren und wirklich nur bestimmte Ports und IP durchlassen. Zur Not häng ich mich kurz an 'nen VLAN 3 port dafür und könnte auf die dann auch so zugreifen. (Werde ich vermutlich auch so machen, aber jetzt neue Geräte inaktiv setzen ... dafür ist die Notwendigkeit nicht vorhanden.)

Und hey, ich kann mir erst dann über Dinge Gedanken machen, wenn ich darüber Bescheid weiß. Wenn ich nicht weiß, wie sich ein Auto fährt, macht es für mich auch keinen Unterschied, ob das Navi im Dacia funktioniert. (Der ehem. Leiter unserer Wassertechnik fährt sogar Dacia ...)

Tja, das wird mit DHCP doch nix. Der LAN Port bei den Dingern hat keinen Modi, dort kann man nur manuell eine IP und Subnetzmaske eingeben.

Ich könnte den WAN-Weg aber nutzen, denn das Gerät sieht ein Remote Management für eine IP aus einem anderen Netz vor (den hatte ich damals auch eingerichtet, musste mich dann nur ins richtige VLAN packen).

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...

Ich habe jetzt (weil ich's einfach testen wollte) den anderen TP Link Router (also doch nicht den AP) für den Gäste WLAN-Zugang genommen.
Auch ins VLAN 3 (jeder WLAN Router steht auf Enable AP Isolation - sollen sich doch die beiden Router untereinander erreichen, egal) aber auf's WAN des Routers (Firewall aus), dann DHCP vom Router (so kümmert er sich um sein LAN-Netz und ich muss an der pfsense nicht noch weiter konfigurieren) in ein 192.168.164.0/24 und meine PC IP im Remote Management.

Funktioniert. Auch mein Zugriff und das ohne extra Regel auf dem pfsense VLAN-Interface, dass der WLAN Router zurück ins LAN net kommunizieren darf. (also nur pass für ! LAN net)

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 !

Ich weiß wofür das enable ap isolation steht ;) und ja, ich halte Netze einmalig, ist ja auch einfacher so in einer Netzwerktabelle die Übersicht zu behalten ^^

@aqui

Passend noch zur Themaüberschrift:

Mir ist aufgefallen, dass die Ports, die zu den anderen Cisco Switches führen/linken, nun plötzlich auch als Trunk Mitglied in allen VLANs sind.
google ergab was mit DTP, dazu finde ich bei meinen Modellen aber kein Setting, könnte es dann am automatischen Smartport liegen (Administrative und Operational Auto Smartport stehen auf enabled - der Op lässt sich auch gar nicht ändern)?
Ist dir etwas bekannt dazu? Ich würde das gerne deaktivieren (wenn das keine weiteren Auswirkungen hat), da die Ports, die in VLANs sollen extra auch nur auf dem ersten Switch stecken.

Das ist Default das die überall Trunk sind. Solltest du besser auf Access umsrtellen wenn es Access Ports sind und Trunk auch nur da wo Trunks verwendet werden !

Vorher standen alle auf Access, die wurden erst Trunk, nachdem die VLANs aktiv wurden (eigentlich nicht mal direkt dann, wie in meinem ersten Screenshot hier zu sehen - ich frage mich: Wann?).
Vorhin war der Port 25 zum Switch 2 Trunk mit Administrativen VLANs aber keine Operational, dann habe ich meinen Port mal in VLAN3 gepackt, weil ich auf den einen WLAN Router zugreifen musste, schon bekam der Port 25 plötzlich alle VLANs auch als Operational. Da habe ich nicht schlecht gestaunt.

Dass ich die jetzt wieder auf Access stelle, steht außer Frage, ich frage mich nur, ob ich das Verhalten unterbinden kann. Nicht dass die in Zukunft wieder unbeobachtet auf Trunk geändert werden.

Hast du da irgendeinen Automatismus wie LLDP, CDP usw. laufen oder sowas der das dynamisch setzt ? Das solltest du, wenn dann, deaktivieren !

Sieht so aus. Discovery - LLDP, Discovery - CDP sind scheinbar standardmäßig aktiviert. (das sind immer solche Einstellungen, wo ich mir sage: Wenn ich nicht weiß, ob eine Fehlkonfiguration etwas kaputtmacht, belasse ich es beim Standard)

Wenn ich das beides deaktiviere, kann ich also ja auch Smartport deaktivieren, oder?

CDP solltest du in jedem Falle deaktivieren. LLDP kann man lassen. Smartport besser auch deaktivieren. Zuviel Automatismus ist meist kontraproduktiv.

Habe ich gemerkt, alles klar. Wenn ich CDP deaktiviere, muss ich die Folgeauswahl setzen:

CDP Frames Handling:
Bridging
Filtering
Flooding

Ich würde es auf Bridging setzen.

Dann gibt er es an andere Ports einfach weiter. Würd ich nicht machen.
Ich würd's auf Filtering setzen, dann gibt der Switch keine CDP Pakete weiter.