VLAN mit Cisco SG220, ESXIund Pfsense

Hallo,

Eher unwichtig

OK

Und dein Wireshark hat keine Quelle und Ziel genannt? Bekommt der entsprechende DHCP denn überhaupt die Anfrage nach einer IP? Notfalls DHCP Logging vorher einschalten.

Gruß,
Peter

Hallo,

Schön, wenn du die Spaltenüberschriften wegschneidest. Was sollte auf ein DHCP Discover folgen? Es scheint das dein DHCP gar nicht mitbekommt das jemand anfragt, oder eben falsch konfiguriert oder eben falsche IPs oder eine Firewall oder falsche Regeln für eine Firewall oder oder oder. Wir wissen hier zu wenig von dein Konstrukt, um zu sagen es ist Komponente X.
https://wiki.wireshark.org/DHCP
https://en.wikiversity.org/wiki/Wireshark/DHCP
https://www.wireshark.org/lists/wireshark-users/200803/msg00237.html
https://mrncciew.com/2012/12/27/understanding-dhcp/
https://forum.netgate.com/topic/154744/jeweils-einen-dhcp-server-pro-vla ...
https://networkengineering.stackexchange.com/questions/58084/no-dhcpoffe ...
https://www.reddit.com/r/networking/comments/2ax0z0/dhcp_responding_with ...
https://networkengineering.stackexchange.com/questions/69480/how-to-capt ...

Wenn du alles was in der PFSense ankommt (auch deine DHCP Discover zählen dazu) logst, solltest du da schon was sehen können, sonst ist die PFSense bei dir eher nur Störenfried und Briefbeschwerer.

Gruß,
Peter

Hallo,

Dann ist deine vLAN Konfiguration falsch. Und wer soll bei dir für die vLANs zuständig sein und zwischen diesen Routen usw. usw. usw.

Da wir hier keine deiner Konfigurationen kennen...

Gruß,
Peter

Zeigt ja immer ganz klar das es dann KEINE Layer 2 Verbindung gibt und sehr wahrscheinlich das VLAN Tagging falsch oder fehlerhaft ist !

Hier sieht meine eine grobe Grundkonfig wie man mit ESXi VLANs sauber jongliert auf einem VLAN Switch:
Sophos Software Appliance UTM - VLAN - CISCO SG Series Switches


Allgemeine Grundlagen zur VLAN Einrichtung mit pfSense und Cisco SG Switches wie immer hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern

Dann hast Du wahrscheinlich an der PfSense das Interface auf tagged statt untagged konfiguriert.

Gruß
Alex

Das ist tödlich und darf man niemals machen, denn die VLAN IDs über 90 sind System reserviert. Die darf man niemals verwenden und sind absolut Tabu im Setup.
Du hast also wieder einen Fehler beim VLAN Tagging gemacht !!

Bedenke immer das das Native VLAN (PVID) an so einem Port UNtagged ist. Das ist vermutlich der Debnkfehler den du machst.

Da muss ich mal ausnahmsweise widersprechen Bei vSphere heißt VLAN 4095 nichts anderes als Trunk Port. Also keine Sorge, es werden keine Frames mit der "illegalen" ID 4095 getaggt, sondern es besagt nur, dass der vSwitch das Tagging der VM selber überlassen soll.

Gruß
Alex

Gut wenn die solche Netzwerk fremde Nomenklatur nutzen ist das deren Sache. Verwirrt aber nur, denn diese VLAN IDs sind im Netzwerkbereich Tabu. In der Regel werden die für MSTP und PVSTP Management intern benutzt und da gibts Chaos wenn man die physisch nutzt.
Wie auch immer man es nennt ,diese IDs sollte man aber auf wirklicher physischer Infrastruktur niemals nutzen.
Das ist dann auch absolut OK.

@aqui... Wie oft denn eigentlich noch? Das habe ich dir schon mehrmals gesagt und auch verlinkt... das ist bei Vmware der Standard (egal ob der einfache Standard vSwitch oder der Distributed Switch aus der Enterprise Umgebung), ist weltweit im Vmware Umfeld etabliert und steht auch in deren HowTos!

Und würde es damit Probleme geben, hätte dies der Weltmarktführer im Virtualsierungsumfeld ggf schon geändert.

Oder sollen die es ändern, nur weil du nicht deren Meinung bist ?

4095 ist im im Vmware Umfeld die vlan ID um einen Trunk in eine VM zu leiten. Und ja das ist korrekt...‘und ich denke die wissen schon was sie tun...

Ps.: ich habe da noch nie Probleme in Vmware Umgebungen gehabt... nicht mit Cisco, Netgear, HP oder Juniper.

Warum machst du noch ein Thema auf?

Das Gleiche, nur anders geschrieben, hast du bereits am 04.01 gefragt.

Warum zweimal?

Das es unglücklich gewählt ist und verwirrend ist, steht außer Frage. Hätte man seitens VMware bestimmt auch besser lösen/benennen können.

Das ist natürlich Blödsinn. Sieh dir das obige Tutorial an da klappt es fehlerlos mit dem VLAN IDs 1 (native VLAN) und 3. Mittlerweile ist es auf 10 und 20 erweitert und klappt immer noch.
Die VLAN ID 4095 ist unsinnig.
Zeigt das dein gesamtes Tagging und die VLAN Zuordnung "totally fu... up" ist und falsch oder zumindest fehlerhaft.
Warum hälst du dich nicht ganz einfach an das o.a. Tutorial da ist es doch einfach und verständlich gepostet ?! In dessen Setup stand da auch nirgendwo ein Wort von 4095 bzw. taucht da auch nirgendwo auf usw.
Irgendwo läuft also irgendwas ganz falsch bei dir und deinen VLANs...

Hallo,

Nein

Und weiter?

Wenn du die brauchst, ja, sonst nein, ausser du bist ein NIC Samler

PFSense CLI statt Bilder https://docs.netgate.com/pfsense/en/latest/config/console-menu.html
CISCO SG 220 CLI https://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbss/sf220_sg220 ...

Gruß,
Peter

Ja das könnte sein, denn das Webinterface ist im Default bei einem Layer 2 Model (oder einem Layer 3 Modell im Layer 2 Mode) nur aus dem Default VLAN 1 erreichbar.
Das kann man aber im Setup einstellen aus welchem VLAN man die Management IP erreichen möchte !
Es ist also absolut relevant an welches VLAN man das Management des Switches bindet !
Nein, es geht de facto ja auch mit einer einzigen. Das kannst du am obigen Screenshot und Netzdesign ja selber deutlich sehen.
Nein, dfas ist falsch !
Es ist dann falsch wenn du einen der Ports im VLAN 3 betreiben willst. Oben ist ja das VLAN 3 angewählt und "Excluded" dort bedeutet das kein Port dem VLAN 3 zugewiesen ist weder tagged noch untagged !
Desweiteren falsch ist das alle Ports im Trunk Mode sind ! Es ist kein einziger Port als Endgerät Access Port definiert. Alle Ports sind untagged im VLAN 1 einzige Ausnahme Port 2 der UNtagged im VLAN 11 hängt.

Man kann also an den Screenshots schon sehen das zumindestens der Anschlussport für den VmWare Host vollkommen falsch konfiguriert ist.
Trunk Mode wäre richtig aber er müsste zumindestens tagged in die VLANs gesetzt sein die du auch vom internen vSwitch tagged überträgst.
Ein Screenshot der "VLAN Port Membership" Übersicht des Switches wäre also hilfreich.
Dein Problem ist also nicht die vmWare und das falsche VLAN 4095 sondern schlicht und einfach dein völlig falsches Switch Setup !

Hier ein Beispiel wie es aussehen sollte am VmWare Port 25 und 26 wären dafür entsprechend konfiguriert
Der Rest sind Access Ports (Endgeräte PC, Drucker etc.) im VLAN 1 und 99
T = Tagged
U = Untagged
P = PVID
Steht ja auch alles unten in der Agenda des GUI !

WO stellst du die denn ein ?!
Beachte auch das das native Interface der pfSense also das was auf dem physischen Port liegt immer UNtagged ist !

Was auch unklar ist in welchen VLAN bzw. VM-Netzkarte dein lokaler LAN Port der pfSense ist und wo der WAN Port liegt. Da du die Mac Adressen nicht customized hast sind die im Default gleich. Das klappt deshalb weil die in unterschiedlichen VLAN sind, macht aber eine eindeutige Identifizierung des LAN Ports sehr schwer.

Der LAN Port ist der einzige Port der dir den Management Zugang ermöglicht. Auf dem WAN Port geht das logischerweise nicht weil FW Regeln das verhindern.
Es ist also essentiell wichtig das zu wissen.
Liegt der LAN Port auf der VLAN ID 0 (172.16.10.0er Netz) landet er im Default VLAN 1 auf dem Switch denn diese Traffic geht untagged über den vSwitch. Da der Trunk Port aus 1UP steht, also aller UNtagged Traffic landet in der PVID 1, ist der Port dann in VLAN 1.
Das kannst du auch immer ganz einfach selber testen denn ein DHCP Client (z.B. PC, Laptop) in diesem Netz bekommt dann vom Default DHCP Server der pfSense eine 192.168.1.x IP zugewiesen.
Am WAN Port der pfSense ist kein DHCP Server aktiv. Folglich wird dort keine DHCP Adresse vergeben und Clients landen im APIPA Netz.

Der WAN Port ist aber selber im Default DHCP Client. Ist er also in einem IP Netz wo ein DHCP Server rennt bekommt der Port automatisch eine IP im Netz. Über das Interface Status GUI der pfSense kann man das also direkt sehen.
Dein Kardinalsfehler ist also das du keinen Access Port im VLAN 3 gesetzt hast !!! Du kannst also nicht testen ob ggf. der pfSense LAN Port in diesem VLAN liegt. Die beiden pfSense Ports liegen ja im VLAN 1 oder 3 also kann es nur eins dieser beiden VLANs sein.
Ergo ist es doch logisch das man sich 1 oder 2 Access Ports in beiden dieser VLANs setzt um das Port Verhalten da zu checken.
Zumindestens bei VLAN 3 hast du das nicht gemacht. Du kannst also mit einem Endgerät niemals testen was im VLAN 3 so los ist.
Wie man auf so einen Kardinalsfehler nicht auch selber kommt ist vollkommen unklar. Es zeigt eher das du vermutlich überhaupt keinen Schimmer hast was VLANs überhaupt sind.
Macht das ganze Unterfangen hier also nicht gerade einfach und da liegt es nahe das du das hiesige VLAN_Tutorial noch einmal dringenst genau lesen und vor allem verstehen solltest !! Vor allem was die Grundlagen anbetrifft. Ggf. hilft da auch nochmal die "VLAN Schnellschulung":
Heimnetzwerk Aufbauen oder auch wie wird ein Longshine LCS-GS8408 eingerichtet
Aaalso fassen wir mal zusammen:

• Trunk Port zum Anschluss des ESXi ist jetzt soweit OK und richtig.
• pfSense Ports sind im VLAN 1 und 3 fragt sich nur welcher ist wo. Musst du rausbekommen
• Ein VLAN (3) des pfSense Ports ist nicht zugänglich da du diesen NICHT zusätzlich als Access Port ins VLAN 3 gelegt hat. Dringenst hier allso 1 oder 2 Access Ports statisch (Klick auch UNtagged) ins VLAN 3 legen damit du darauf überhaupt zugreifen kannst
• Gilt natürlich auch für deine VLANs 11, 12, 13 und 14 die (vermutlich) noch nicht in Benutzung sind ?!

Sieh doch einfach nur einmal auf das Switchbild oben:
Da ist doch eigentlich auch für einen Laien einfach und schnell zu sehen wie das Port Tagging und die VLAN Zuordnung auf dem Switch aussieht !!
Gelb = VLAN 1 = WAN Port der pfSense (ESXi Port=Untagged "1UP", Access Ports= "1UP")
Blau = VLAN 3 = LAN Port der pfSense (ESXi Port=Tagged "3T", Access Ports= "3UP")
Was ist an der einfachen Logik bloß so schwer...?? 😟

Mit solchen Sätzen machst du uns das Verstehen aber auch nicht gerade leicht... !
Wie ??? Bei solch einfachster VLAN Logik ? Nicht dein Ernst, oder ?!
Völlig verwirrend sind auch die 2 vSwitch Screenshots. Welcher der beiden gilt denn nun ?? Der mit der ID 4095 ist Blödsinn, tun wir also einmal so das es den gar nicht gibt und der letzte Screenshot der gültige ist !
Es bleibt dann dabei das ein Port der pfSense im Default VLAN ist (ID 0, UNtagged) und ein Interface im VLAN 3 (ID 3, Tagged).
Sprich zum Testen dieses Setups benötigt man den ESXi Hostport der aus 1UP, 3T gesetzt sein muss. Das haben wir an Port 26 !
Um das nun sauber mit Endgeräten zu Testen benötigen wir auf dem Switch also noch 1 oder 2 Access Ports im VLAN 1 und VLAN 3
Soweit so gut....

Nun wiederholt sich das Drama am Switchport. WELCHER der 2 Screenshots gilt denn nun ??? Der obere ist wieder Blödsinn, da es dort keinen Access Port im VLAN 3 gibt und man ergo damit nicht testen könnte.
Also ignorieren wir den mal und nehmen auch hier (geraten) an das der 2te der gültige aktuelle ist.
Steckt man jetzt einen Test PC an Port 1 ist man mit dem Interface der pfSense an VLAN 1 verbunden, steckt man ihn rechts neben den Port 1 dann an Port 2 ist die PC im VLAN 3 und mit dem 2ten Port der pfSense verbunden.
Jetzt gilt es nur rauszubekommen WIE die Portzuordung der pfSense ist, sprich WO ist der WAN Port und WO ist der LAN Port ??
Ohne groß GUI und CLI zu bemühen kann man das ganz einfach sehen, denn nur am LAN Port rennt ein DHCP Server der einem Endgerät eine IP verpasst.
Die Logik ist dann einfach:

• Bekommt der PC am Port 1 (VLAN 1) eine IP = VLAN 1 ist der LAN Port und VLAN 3 ist der WAN Port
• Bekommt der PC am Port 2 (VLAN 3) eine IP = VLAN 3 ist der LAN Port und VLAN 1 ist der WAN Port

Man sollte hier nicht vergessen das die Port Nummerierung bei Cisco nicht oben, unten, oben, unten... usw. ist wie bei anderen Switches sondern oberere Reihe, dann untere Reihe ! Wir auch häufig übersehen !!

Aber Bingo... GE2 zu 3UP wie es ja sein soll: !!!....am Port 2 bekommst du ja eine IP, damit ist dann sonnenklar das das VLAN 3 den LAN Port der pfSense beherbergt, also auch das Segment was dann das interne, lokale LAN ist.
VLAN 1 ist dann der WAN Port also der der ins Internet oder auf einen Kaskaden Router geht...siehe Zeichnung oben, denn dort ist es ja völlig identisch !
Deine wirren Ausführungen dananch was dann an GE 2 angeschlossen ist mal VLAN 11, dann wieder 2 usw. kann kein Mensch folgen, weil keiner hier weiss WIE du deine pfSense konfiguriert hast.

Fakt ist folgendes:

• Wenn du einen Port der pfSense als VLAN Port Tagging konfiguriert hast geht dein Design nicht es sei denn du hast in der VmWare den Offload vSwitch lizensiert. Ohne Lizenz, also mit der freien Version, kannst du keine Tags an eine VM direkt bringen.
• Hast du also mehrere lokale VLAN Segmente wie bei dir, musst du das zwangsweise mit Portgruppen und einzelnen Interfaces an der pfSense lösen. Sprich jedes lokale LAN Segment an der pfSense hat eine vNIC mit einer Portgruppe die als VLAN ID tagged auf die physische NIC arbeitet (Port 26)

Vermutlich ist das der Denkfehler den du noch machst ?!

Nee, hast du nicht alles gut.
Du bekommst hier noch etwas Silbertablett mit Honigquast am Beispiel eines 3ten Interfaces für die pfSense. Bei mehr Interfaces muss man diese Schritte einfach nur wiederholen.

• WAN Port = Default vSwitch = Untagged = Switch VLAN 1
• LAN Port = PortGroup VLAN-ID 3, vSwitch = Tagged = Switch VLAN 3
• 2ter LAN Port neu = PortGroup VLAN-ID 7, vSwitch = Tagged = Switch VLAN 3

Port Gruppe im vSwitch für VLAN 7 anlegen:

pfSense VM 3tes Interface anlegen:

pfSense 3tes Interface aktivieren:

Beim Hochfahren der VM sieht man es als "vmx2". Mnn kann es entweder über die Konsole oder im GUI hinzufügen.
Im GUI wird es dann hinzugefügt:

IP Adressierung und DHCP Server auf 3tem Interface (hier 192.168.7.1 /24):

Switchport den richtigen VLANs zuweisen:

Client Testport fürs neue Interface = 2

Check mit Test PC an Switchport 2:

Works as designed !!!

Das ganze Konstrukt sieht dann so aus:

Mehr "Silbertablett" geht nun aber für diese einfache Banalkonfig jetzt nicht mehr. Normal hat man sowas in nicht mehr als 20 Minuten am Fliegen ohne 30 Forenthreads !! 😉

Glückwunsch 👏 ! War ja ne echt schwere Geburt mit dir !
Doch, die ist essentiell wichtig in einem Layer 2 Umfeld. Guckst du hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Sie funktioniert auch auf einem Hypervisor vSwitch, allerdings muss man diese Funktion bei VmWare lizensieren was du vermutlich nicht gemacht hast ?! Ohne eine solche Lizensierung kann der vSwitch keine Tags an die VM selber durchreichen. Du musst also wegen der fehlenden Lizenz bei dir den Weg über die Einzelinterfaces gehen und nicht weil man nach deiner Meinung irgendwas "nicht braucht".
Ja natürlich !
Sieh dir doch bitte die Zeichnung von oben an. Die FritzBox ist ja Member eines VLANs. Im obigen Design ist sie im gleichen VLAN (1) in dem auch der WAN Port der pfSense ist. Logisch, denn das ist dann eine klassische Router_Kaskade mit doppeltem NAT und Firewalling wie sie HIER genau beschrieben ist.
Da der AP auf der FritzBox ja wie üblich als simple Bridge arbeitet also mit dem lokalen LAN der FritzBox verbunden ist funktioniert das WLAN natürlich weiter.
Der Knackpunkt ist aber das das LAN Netz der FritzBox ja das Koppelnetz zum WAN Port der Firewall ist. Der WAN Port ist aber für die Firewall logischerweise der Port wo das "böse" Internet in der Regel ist. Dort schottet sie sich also durch rigide Firewall Regeln und NAT ab.
Willst du also WLAN Traffic der dort landet in die lokalen LANs hinter der Firewall bringen musst du die FW Regeln entsprechend anpassen und auch Port Forwarding Regeln setzen um das NAT dort überwinden zu können. Das Blocken der privaten RFC 1918 IP Netze sollte man am WAN Port in einer Router Kaskade so oder so immer deaktivieren am WAN Port Setup:
Achtung: Das gilt NUR für eine Kaskade und logischerweise NICHT wenn der Port per NUR Modem direkt am Internet hängt !! (Siehe Kaskaden Tutorial oben !!)

Es ist aber wenig ratsam den WAN Port der FW dann so zu "durchlöchern", denn damit schwächt man die Firewall und macht sie potentiell unsicher.
Zusätzliche Access Points kosten nicht die Welt:
https://www.varia-store.com/de/produkt/97657-mikrotik-cap-lite-mit-ar953 ...
Es ist sinnvoller diese dann in den Segmenten zu betreiben als das WLAN der FB umständlich über die Schutzfunktion der Firewall zu frickeln !

Sorry, das wusste ich nicht. Ich nehme alles zurück von oben ! Allerdings wenn du den Akt oben dir das alles beizupulen schon siehst, wie soll das denn erst mit vSwitch Offloading und den VLAN Ports an der pfSense enden ?! Das artet dann sicher in ein 3 Tage Training aus und sprengt völlig den Rahmen einen Administrator Forums....
Wie kann es sowas geben, denn wer sollte dir von der Stirn ablesen können WAS und welche Protokolle du durchlassen willst ?!! Das ist doch immer indiviuell. Ohne Kristallkugel wird das dann nix.

Alles was du zum Regelwerk usw. wissen musst findest du im hiesigen Firewall Tutorial und seinen weiterführenden Links und Beispielen:
Preiswerte, VPN fähige Firewall im Eigenbau oder als Fertiggerät

Was meinst du denn genau, was in der Enterprise erst funktioniert? VLAN Tags an die VM durchreichen funktioniert mit Jeder Version. "richtiges" LACP funktioniert z.B. erst mit der Enterprise Plus