VLan funktioniert nicht (Keine DHCP Vergabe und Internetzugang)

Ggf. hilft auch dieses Tutorial:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
es bezieht sich zwar nicht auf den Zyxel Switch zeigt aber identische Switch Konfigs die analog auf den Zyxel übertragen werden können..

Ich kenne leider nur die Zyxel-eigenen (ZyNOS-basierenden) Switches. Die 1500er Serie ist zugekauft. Bei anderen Herstellern ist es häufig so, dass man einen Port erst dann in VLAN1 auf "not Member" setzen kann, wenn _zuvor_ die PVID umgestellt wurde.
Wenn Du möchtest, kann ich mir das mal per Teamviewer ansehen. Morgen vormittag würde passen.

Gruß
Steffen

Auffällig ist zuallererst das in der Konfig der Firewall (Zyxel UGS-20w) es keinerlei Hinweise gibt das die überhaupt tagged Ports, also welche mit VLAN Tagging supportet !! (Bei dir mit VLAN ID 100 getaggt).
Sieht man sich alle FW Screenshots oben an, kommt man zu dem Schluss das diese Firewall keinerlei VLAN Tagging generell supportet ! Damit wäre die ganze Konfig mit tagged Ports dann eh obsolet, egal ob der Switch das supportet, denn der will ja tagged Pakete sehen an Port 24.
Die Einstellung "WAN Trunk" ist hier keineswegs VLAN Tagging sondern eine reine Link Aggregation (Bündelung von Links). Hat also mit VLANs nicht das geringste zu tun.

Die Firewall müsste hier zwangsweise taggen, denn der Zyxel Switchport 24 ist ja auf ein tagged VLAN eingestellt für das VLAN 100, erwartet hier also mit der VID 100 getaggte Pakete ! Ungetaggte Pakete an diesem Port forwardet der Switch immer automatisch ins VLAN 1, da das immer als Default anliegt.
Das lässt also nur den Schluss zu das die Firewall (Zyxel UGS-20w) keine VLAN tagged Pakete supportet und diese Konfiguration damit nicht funktioniert.
Wenn du dir das o.a. gepostete Tutorial zum VLAN Tag Handling ansiehst, dann erkennst du das die dort vorgestellte M0n0wall/pfSense Firewall sehr wohl ein VLAN Tagging im Interface Setup supportet. Diese Einstellungen sieht man bei deiner Zywall aber nirgendwo. Wenigstens nicht bei den Screenshots oben !!

Fazit: VLAN Tagging scheint nicht zu klappen, da nicht supportet auf der Zywall FW. Du musst also ganz schlicht und einfach den Port 24 auf "untagged" setzen (grau) und ihn dann mit dem Switch verbinden. Damit liegt das VLAN 100 dann nur untagged auf den Ports 16 bis 20 und 24. Damit wird dann der untagged Traffic von der FW der hier ankommt nicht in VLAN 1 sondern dann in VLAN 100 geforwardet !!
Anders ist das vermutlich wegen des nicht vorhandenen VLAN 802.1q Supports der Zywall FW nicht möglich !

P.S.: Es ist übrigens völlig normal das das Default VLAN 1 immer untagged am Switch anliegt und sich bei einigen (Billigswitches) nicht entfernen lässt. Der IEEE VLAN Standard 802.1q sieht das ausdrücklich vor und das Gros der einfachen Switch Hersteller im billigen Consumer Segment hält sich auch daran !
Es ist aber kein Muss. Bei Premium Herstellern ist das konfigurierbar.

Hallo aqui,


Alle Zywalls der Typenreihe "USG" unterstützen (anders als die alten Zywalls) tagged VLAN. Man hat auch keine Wahl: ein VLAN-Interface ist auf diesen Geräten zwangsweise mit Tagging verbunden - will man es untaggt, muss man schlicht einen anderen Interfacetyp wählen.



Ja beim WAN-Trunk handelt es sich um ein Zusammenfassen von Links auf Layer 3 - hat also nichts mit dem VLAN-Trunk nach Cisco-Terminologie zu tun. Dennoch benötigt er diese Policy-Route, denn er muss hiermit festlegen, dass die Zywall beim Zugriff vom VLAN aufs Internet Source-NAT aufs outgoing Interface macht.


Gruß
Steffen

OK, ein bischen abartig aber dafür ist es eben Zyxel...nundenn. Wenn dem so ist dann ist nur das Wörtchen "egress" in der Switch Tagging Konfig etwas verwirrend. In der Regel heisst "egress" ausgehend und das bedeutet das dann nur ausgehende Pakete getagged werden.
Man kann dann nur hoffen das die Zywall dann auch "ingress" Pakete mit einem VLAN 100 Tag sauber ins VLAN 100 forwardet.
Normalerweise ist Tagging immer eine bidirektionale Geschichte ! Na ja ist halt Zxel die mögen das anders sehen...

Abartig ist es offenkundig nur, weil Zyxel drauf steht. Jeder benötigt halt ein Feindbild, um mit der Welt im Reinen zu sein.
Die VLAN-Funktionalität der Zywall unterscheidet sich z.B. nicht von der einer m0n0wall oder pfSense, die Du ja gern für Deine Anleitungen heranziehst. Nur dass das auf der Zywall noch intuitiver einzurichten ist.



Zyxel sieht hier überhaupt nichts anders, sondern hält sich schlicht und ergreifend an die Standards.
Versuche mal ein Weilchen Dein Cisco-Wissen auszublenden und lies Dir das mal unvoreingenommen durch: http://standards.ieee.org/getieee802/download/802.1Q-2003.pdf
Anschließend lies bitte nochmal meine hiesigen Ausführungen: VLAN Konfiguration auf einem Netgear Switch
und spiel mal selbst ein wenig mit asymmetrischen VLANs - spätestens dann sollte der Groschen fallen! Dein Trendnet TEG-160WS unterstützt asymmetrische VLANs...


Gruß
Steffen

Nee, ich hab kein Zyxel Feindbild..keine Sorge Das Thema der asymetrischen VLANs ist schon bekannt aber etwas krank m.E.. Damit erzwingt man asymetrische Pfade im IP was generell nicht verboten ist aber man dann schon sehr genau wissen sollte was man da macht.
Die Problematik auf einer FW ist m.E. damit fatal, denn man muss so zwangsweise 2 Interfaces im Auge haben die man Security seitig betrachten muss um den Traffic wirklich im Sende- und Empfangspfad zu kontrollieren. Nicht wirklich eine Erleichterung einer FW Konfig !?
IMHO ist dort ein wirklich dediziertes tagged Interface, wo der Traffic bidirektional drüber abgewickelt wird besser, denn hier ist nur ein Punkt per Regel zu kontrollieren und nicht multiple wie es bei asymetrischen VLANs ja der Fall ist. Ein sauberes VLAN Konzept ist damit nur sehr schwer einzuhalten. Es mag aber im Einzelfall sinnvoll sein, keine Frage.
Interessant in dem Zusammenhang ist das viele Premium Hersteller asymetrische VLANs in ihren Featuresets gar nicht erst supporten.
Geben wir den Stab mal wieder an Bommel1302 damit er sein Szenario gefixt bekommt....

Zumindest ist die Möglichkeit dazu meist per Default deaktiviert. Das macht m.E. auch Sinn, da 99,9999% der Kunden das niemals benötigen werden. Dementsprechend wissen auch die wenigsten Techniker von dieser Möglichkeit.



Asymmetrisches Routing (also die Wahl unterschiedlicher Router-Pfande je Richtung auf Layer 3) kann dabei eigentlich nicht entstehen. Das auszudiskutieren, führt aber an dieser Stelle vielleicht wirklich zu weit.



Wir haben für morgen eine Teamviewer-Session vereinbart. Ich möchte mir den Switch mal anschauen, denn wie bereits erwähnt, ist das kein ZyNOS-Gerät (womit ich mich auskenne), sondern ein zugekauftes OEM-Produkt.


Gruß
Steffen

OK, dann sind wir mal auf das Ergebnis gespannt...

Wir haben tatsächlich keine Trennung auf Layer 2 hinbekommen. Die Zywall erhält die DHCP-Requests sowohl untaggt im Default-VLAN als auch taggt im zusätzlich angelegten VLAN vom Switch überreicht. Obwohl die PVIDs richtig gesetzt sind. Sehr seltsam.
Ich versuche mal auf Arbeit so einen Switch zu organisieren, um damit noch weitere Tests durchzuführen.

Gruß
Steffen

Vielleicht dann doch besser einen Trendnet... Der kann sowas problemlos

Hallo,

wie versprochen, habe ich mich etwas näher mit dem verwendeten Switch und mit dem Szenario von Marcel auseinandergesetzt. Die Ergebnisse habe ich nachfolgend dargestellt. Ist leider etwas viel Text geworden, aber ich hoffe, dass es dennoch verständlich und für Euch interessant ist. Mir hat die Fehleranalyse jedenfalls Spaß gemacht!

Zunächst zum Switch:
Wie Marcel bereits schrieb, lassen sich die Ports tatsächlich nicht aus dem VLAN1 entfernen. Auch wenn Aqui berichtete, dass dies auch bei anderen (Billig-)Switches üblich sei, schockt mich das doch sehr. Damit ist m.E. sowohl bewusstes VLAN-Hopping eines Angreifers als auch (wie in diesem Fall) ein Hereinfallen des Admins auf unbewusst konfigurierte asymmetrische VLANs möglich. Schlimm, dass Zyxel so einen Murks unter eigenem Label verkauft! Ich hab auch mal versucht, herauszubekommen, wer der eigentliche Zulieferer ist. Wenn man sich per Telnet mit dem Switch verbindet, landet man auf einem CLI von ECOS. Das ist Open Source – ermöglicht also leider keinen Rückschluß auf den Switchhersteller. Laut Google läuft das gleiche System auch auf (einigen) Netgear-Switches. Vermutlich sind aber auch die nur zugekauft. Nachdem ich so einiges im Web gelesen habe, scheint es mir am wahrscheinlichsten, dass es OEM-Ware von Broadcom ist. Final belegen kann ich das aber nicht.
Meine Empfehlung ist auf jeden Fall: Finger weg vom GS-1524! Zumal das Modell offenkundig EOL ist, denn es gibt bereits ein Nachfolgeprodukt (wiederum mit anderer GUI – also vermutlich wieder woanders zugekauft *augenroll*).

Kommen wir nun zum Szenario von Marcel:
Meine obige Annahme, „die Zywall erhält die DHCP-Requests sowohl untaggt im Default-VLAN als auch taggt im zusätzlich angelegten VLAN vom Switch überreicht“ hat sich nicht bewahrheitet.
Vielmehr führt die o.g. Besonderheit des Switches in Verbindung mit der Art und Weise, wie die Zywall konfiguriert wurde, ungewollt zu einem asymmetrischen VLAN.

Der Aufbau von Marcel ist im Groben folgender:

Zywall (DHCP-Server für VLAN100) [P2] --- Windows-Server (DHCP-Server)
[P1]
|
[P1]
Switch [P3] --- Accesspoint für Gäste-Netz (VLAN100)
[P2]
|
Client in Windows-Domäne (VLAN1)

Die Portnummerierungen sind für das Beispiel frei gewählt. Fürs Verständnis ist es wichtig zu wissen, dass Zywall und Switch räumlich getrennt sind und dazwischen nur ein einzelnes CAT-Kabel liegt. Der Server muss aufgrund der örtlichen Gegebenheiten an der Zywall angeschlossen sein. Die Zywall wird mithin also als Switch mißbraucht (und das ist hier Teil des Problems).

Die Zywall kennt verschiedene Interfacetypen: unter anderem Ethernetinterfaces, VLAN-Interfaces und Bridgeinterfaces.
Ein Ethernetinterface ist nicht gleichzusetzen mit einem physischen Ethernetport, sondern es handelt sich lediglich um ein repräsentatives Interface. Es kann keinen, einen oder auch mehrere physische Ethernetports repräsentieren. Letzteres wäre ein sog. Portgrouping. Genau das hat Marcel verwendet, weil er auf Port 2 den Server angeschlossen hat und auf Port 1 den Switch und beide im gleichen LAN sein sollen. Zusätzlich benötigte er aber noch ein Firewallinterface, welches getaggt auf dem Uplinkport zum Switch angliegt und das Gästenetz beinhaltet. Er hat deshalb ein VLAN-Interface auf der Zywall angelegt (welches bei den USGs immer ein- und ausgehend mit dot1Q-Tagging verbunden ist). Dabei musste er einen „Baseport“ wählen. Und hier ist der Denkfehler: Hier wählt man - anders als die Benennung in der GUI vermuten lässt - eben keinen physischen Ethernetport aus, sondern ein repräsentatives Interface (es hätte z.B. auch ein logisches WLAN-Interface sein können)! Er wählte „LAN1“, welches die physischen Ports 1 und 2 beinhaltet. Damit liegt das VLAN 100 aber nicht nur auf dem physischen Port 1, sondern auch auf Port 2 getaggt an und er hat damit unbewusst ein asymmetrisches VLAN gebaut!
Der Effekt ist jetzt folgender:

1) Wenn ein WLAN-Client einen DHCP-DISCOVER absetzt, empfängt der Switch diesen untaggt auf Port 3. Da auf diesem Port die PVID=100 ist, steckt er den Traffic ins VLAN100 und gibt ihn entsprechend getaggt an Port 1 aus.
2) Die Zywall empfängt diesen Traffic auf Port 1 und erkennt anhand des dot1Q-Tags, dass er ins VLAN100 gehört. Da auf dem VLAN-Interface 100 auf der Zywall ein DHCP-Server konfiguriert ist, beantwortet er den DHCP-DISCOVER mit einem entsprechenden OFFER.
– Bis hierhin ist alles in Ordnung! –
3) Da der DHCP-DISCOVER ein Broadcast ist und das VLAN100 aufgrund des Portgroupings auch auf Port 2 der Zywall anliegt, gibt diese den Traffic aber zusätzlich auch an Port 2 aus (und zwar getaggt).
4) Der Windows-Server empfängt den DCHP-DISCOVER. Dieser ist zwar auf Layer2 mit einem VLAN-Tag versehen, dies scheint aber nicht dazu zu führen, dass der Treiber den Traffic verwirft. Der DHCP-Server auf dem Windows-Server antwortet also ebenfalls mit einem OFFER.
5) Der OFFER des Windows-Servers geht untaggt auf Port 2 der Zywall ein, diese ordnet ihn korrekter Weise dem repräsentativen Interface „LAN1“ zu und gibt ihn auf Port 1 untaggt aus.
6) Der Switch empfängt diesen Traffic untaggt auf Port 1 und ordnet ihn dem Default-VLAN 1 zu, da die PVID des Ports entsprechend konfiguriert ist.
7) Da man die Ports auf dem Switch aber nicht aus dem VLAN1 entfernen kann, wird dieser Traffic nun auch auf dem Switchport 3 ausgegeben (je nach Konfig taggt oder untaggt) und erreicht somit auch den WLAN-Client.
Zusammenfassung:
Der WLAN-Client fragt auf VLAN100 eine IP-Adresse an. Er erhält daraufhin aber ein Angebot von 2 DHCP-Servern. Das des Windows-Servers kommt aber nicht aus dem VLAN100 zu ihm, sondern aus dem VLAN1 – also klassisches asymmetrisches VLAN!
Dass der WLAN-Client immer das Angebot des Windows-Servers annimmt, könnte daran liegen, dass dieser schneller antwortet, als die Zywall oder aber eine Windows-Maschine generell den OFFER eines Windows-DHCP-Servers bevorzugt.

Wie kann man das Problem nun lösen, ohne andere oder weitere Hardware erwerben zu müssen?

Zunächst kann man auf dem Switch ein weiteres Daten-VLAN anlegen und dieses auf Port 1 und 2 untaggt „fahren“. Im Ergebnis würde die Antwort des Windows-DHCP-Servers den WLAN-Client nicht mehr erreichen, wenn die PVID auf Port 1 richtig gesetzt ist. Die Anfrage des Clients würde aber weiterhin (auch) zum Windows-DHCP-Server gelangen und dieser mit einem OFFER antworten. Entscheident ist es daher, die Fehlkonfiguration auf der Zywall zu beheben.
Ziel ist es, die Zywall so zu konfigurieren, dass das VLAN100 getaggt nur auf dem physischen Port 1 anliegt, während gleichzeitig weiterhin Port 1 und 2 untaggt zur gleichen Broadcast-Domäne gehören. Dies ist möglich und geht so:
Man hebt das Portgrouping des repräsentativen Interfaces „LAN1“ auf und ordnet dieses nur noch dem physischen Port 1 zu. Die VLAN-Konfig bleibt unverändert. Nun nimmt man ein weiteres repräsentatives Interface (z.B. „LAN2“) und mappt es auf Port 2. Fortan wären die beiden physischen Ports aber auf Layer 2 getrennt, was nicht gewünscht ist. Um diese wieder zusammenzuführen, legt man einfach ein Bridgeinterface an, welches „LAN1“ und „LAN2“ als Member hat. Anschließend muss man noch das Firewallregelwerk und das Routing anpassen, da man ab jetzt nur noch mit dem neuen Bridgeinterface statt des repräsentativen Interfaces „LAN1“ arbeitet. Fertig!

Gruß
Steffen

Oha, oha...das hört sich aber gehörig nach einer Bastellösung an... ist aber wohl zwingend vonnöten wenn man solch vermurkste Switchhardware sein eigen nennt. So oder so Dank für das ausführliche Feedback was doch einen klaren Blick auf diese spezifische und zugegebenermaßen "vermurkste" Switch Hardware ermöglicht !
Es ist sehr verwunderlich das der grauselige Zyxel Switch sich so abartig verhält, denn andere Billigheimer in diesem Sektor können sehr wohl sauberer mit so einem banalen VLAN Szenario umgehen...aber nundenn.
Noch 2 Comments dazu: Diese Billigswitches kommen so gut wie immer von Accton in Taiwan. Das ist ein Massenproduzent von billiger Switchhardware, die die Hersteller dann nur mit einem Aufkleber entsprechend "branden"..bei der Zyxel Gurke ist das nicht anders.
Was das default VLAN anbetrifft lässt der weltweite IEEE 802.1q Standard (VLAN Standard) ausdrücklich das Vorhandensein des default VLANs immer an tagged Interfaces zu bzw. standartidiert dieses Verhalten. Billigheimer halten sich also deshalb an diesen Standard, versäumen aber so gut wie immer eine Konfig Option dies auch zu unterbinden. Warum auch.... Blödmarktkäufer benötigen das so gut wie nie und würden es auch nicht bezahlen sondern dann lieber zu einem anderen Billigheimer greifen wenn der noch ein paar Euro preiswerter ist...so ist nun mal die Realität und dann lässt man es Hersteller seitig halt. Im Consumer Segment zählt halt jeder Cent....
Mit solchen Frickel Lösungen wie oben und grausligem Bridging zu leben ist dann der komplizierte Workaround um das wieder geradezubiegen. Nichts gegen deine Versuche die eher davon zeugen mit Engagement und technischem Sachverstand das Problem zu lösen...aber eine skalierbare und saubere Lösung für ein Produktivumfeld ist das ja nun wahrlich nicht. Das soll keine sinnlose Herstellerdiskussion hier auslösen aber auch das können andere Billighersteller weitaus besser....
Fazit mal wieder das sich eine sinnvolle Produkt Information vorher immer lohnt !

@Bommel1302
Wenns das denn jetzt war und alles zum Fliegen gekommen ist bitte dann auch
Wie kann ich einen Beitrag als gelöst markieren?
nicht vergessen.

Das ist damit ja auch nicht gesagt. Zyxel gehört aber in diesem Segment zweifelsohne zu den Billigheimern und da muss man dann eben solche Nachteile in Kauf nehmen. Wenn das Auge des betrachters eben nur den Billigheimer Markt betrachtet hast du ohne Frage absolut recht !
Andere Billigheimer haben diese Nachteile aber andererseits eben nicht, deshalb auch der Hinweis dann besonders genau ins Datenblatt zu sehen.
Und gerade wenn man aufs Geld schielt und eben nicht bei den Cisco, Brocade, HP, Entensys, Extremes und Junipers dieser Welt fündig wird oder fündig werden will !
Letztlich ist dein Problem ja gelöst, wenn auch schlecht aber wenns die Funktion erfüllt ist ja alles gut.

Hallo,

wenn die Ports aus dem VLAN 1 raus sollen der Switch das aber nicht zulässt, würd eich die Ports einfach in eine ungenutztes VLAN verschieben und das VLAN entsprechend schließen.
Dann solten diese Ports aus dem Weg sein.

Außerdem solte der Windof Server, respektive seine Netzwerkkarten Treiber in der lage sein das VLAN Tag auszulesen.
Wenn nicht solte man an dieser Stelle über eine neue Netzwerkkarte nachdenken die das kann.
Alternativ sollte es möglich sein zwischen dem Router und dem Server einen Trunk nach Cisco Vorbild zu konfigurieren.
Damit wäre die Kommunikation immer noch gewährleistet, aber der DHCP Broadcast könnte geblockt werden.

brammer