Aug 31, 2019, updated at Mar 02, 2023 (UTC)

7207

Lancom Muliti-WAN Router und Layer3 Cisco Switch - VLAN Fragen

Hallo Zusammen,
ich bin neu hier und vor allem auch neu im Thema VLAN.
Zum Hintergrund: seit vielen Jahren helfe ich einem guten Freund beim Betrieb der IT seines Handwerkbetriebs. Bisher sind wir mit einem einzigen /24 Netz an 3 Cisco Layer 2 Switches ausgekommen. Durch die geplante Umstellung auf IP-Telefonie mussten eh neue PoE Switche angeschafft werden und auch der aktuelle WAN Router hatte nur ein 100 MBit Interface. Zudem gingen langsam die IP-Adressen aus (viele Laptops, iPads, Drucker, Maschinen, etc. und jetzt eben noch 35 Telefone).

Dafür haben wir folgende neue Hardware bestellt:

Lancom 1900FE als WAN Router: für die Verbindung aller VLANs ins Internet. Wir haben aus Redundanz 2 Internet-"Leitungen". Einmal VDSL und einmal Unitiymedia Kabel. Der Lancom soll beim Ausfall von VDSL auf Unitymedia umschalten. Beide Anschlüsse sind per Fritzbox (eine für Telekom und eine für Kabel) verbunden.
3 x Cisco SG350X-48P als Layer 3 Switch. Der Switch ist als ein Stack Switch konfiguriert. 2 Switches stehen in einem Raum. Der dritte Switch steht einen Stock tiefer. Alle 3 werden per Glasfaser verbunden.

Nun habe ich dies im Testaufbau und kämpfe mit der Verbindung von Lancom und Cisco:
Im Cisco habe ich den Stack erfolgreich aufgebaut. Und ich habe 4 VLANs angelegt:
- VLAN1: 192.168.1.0 / 24: das ist das bisherige LAN, aus dem ich gerne die Clients rausnehmen würde:
- VLAN2: 192.168.2.0 / 24: für die Clients
- VLAN50: 192.168.50.0 / 24: für die IP-Telefone
- VLAN99: 192.168.99.0 / 24: Gastnetz

Auf dem Cisco habe ich die 4 VLANs eingerichtet und die Ports jeweils einem VLAN zugeordnet. Zudem habe ich je VLAN einen DHCP-Server (macht auch der Cisco) konfiguriert.
Sobald ich einen Laptop nun an einen der Ports anschließe, bekomme ich nun eine IP-Adresse des zugehörigen VLANs. Zudem kann ich auch PCs in den anderen VLANs anpingen (das hat mich viel Zeit gekostet, bis ich hier im Forum auf den Tipp gestoßen bin, dass die PC-Firewall mir hier in die Suppe spuckt und daher der Ping nicht funktioniert.
Ich würde also sagen: die Kommunikation im Switch sieht gut aus.
Einzig offener Punkt: wie kann ich denn das Routing des Gast-LANs in die anderen VLANs verhindern?
Als Router habe ich die 192.168.1.9 (das ist die heutige Adresse des Internet-Routers und ich hätte diese auch gerne an den neuen Lancom WAN-Router vergeben.

Nun zu meinem Sorgenkind Lancom 1900FE, den ich schon mehrere Male in den Werkszustand zurück versetzen musste, da ich nicht mehr drauf kam:
Dem Lancom 1900 habe ich die IP 192.168.1.9 gegeben und mit Eth1 mit einem Cisco Port in VLAN1 verbunden.
Der Lancom hängt über WAN1 - Schnittstelle an der Fritzbox und hat hierfür vom FB-Netz die IP 192.168.201.5 bekommen (habe ich fest zugeordnet). Die Fritzbox hat das Netz 192.168.201.0 und die IP 192.168.201.9. Der Lancom hat Verbindung ins Internet (so findet er z.B. neue Firmware)
Damit kommen nun alle Clients, die im VLAN1 am Cisco hängen auch ins Internet. Aber die Clients an allen anderen VLANs leider nicht.
Ich erreiche den Router 192.168.1.9 (mein Default-GW) auch nur vom VLAN1 aus. Den Port-Tpy, an dem ich den Cisco mit dem Lancom verbunden habe, habe ich auf Cisco auch schon auf Trunk umgestellt. Das ändert aber nichts.
Ich dachte: klar, ich muss auf dem Lancom auch noch die VLANs eintragen und habe dazu erst mal der VLAN Modul aktiviert. Und damit ging das Elend los. Sobald ich den Haken für "VLAN-Modul aktiviert" setze, komme ich nicht mehr auf den Lancom Router um diesen zu administrieren. Und natürlich kommt dann auch kein Client aus VLAN1 mehr ins Internet (da von diesen auch keiner mehr den Router erreicht.

Ich musste den Lancom in Werkszustand zurück setzen, um ihn wieder zu erreichen.
Ich habe viele Tests gemacht und auch vor dem Aktivieren des VLAN-Moduls ein VLAN2 auf dem Lancom eingetragen und die Hoffnung, dass ich evlt. dann über einen an einen VLAN2 zugeordneten Port auf dem Cisco nach Aktivierung an den Lancom dran kommen würde. Aber bisher immer alles ohne Erfolg. Wie gesagt: aktiviere ich das VLAN Modul, ist für mich der Lancom nicht mehr erreichbar. Auch nicht, wenn ich meinen Laptop direkt in einen Lancom Port einstecke und ihm eine feste IP aus dem Lancom-IP-Bereich vergebe.
Nachdem ich bestimmt schon fast 10 Versuche mit Switch und Router hinter mich gebracht habe (immer mit dem Ende Reset Werkszustand), habe ich jetzt versucht, das Ganze einzugrenzen, und den Switch komplett vom Lancom getrennt.
Lancom in Werkszustand. IP Adresse des Lancoms auf 172.23.56.254 belassen. Mit Fritzbox verbunden (spielt keine Rolle). Sobald VLAN Modul aktiviert wird, ist für mich das Ende mit dem Lancom erreicht.

Nun frage ich mich 3 Dinge:

Wie kann man im Lancom 1900FE (Firmware: 10.30.0167RU1 / 09.07.2019) überhaupt das VLAN Modul aktivieren und anschliessend das Gerät noch erreichen?
Ist das überhaupt der richtige Weg, um VLANs ans Internet zu bekommen? Sollte ich - falls ich es jemals schaffe, das VLAN Modul doch noch zu aktivieren und die VLANs auch auf dem Lancom anzulegen - damit Internet für alle VLANs hinbekommen? Ich lese immer wieder, dass eine Alternative wäre, per NAT dies umzusetzen. Hier muss ich mich nochmals die nächsten Stunden genauer einlesen. Aber vielleicht habt ihr mir ja einen Tipp, welcher Weg der bessere ist. Mein Ziel war eigentlich, dass Routing innerhalb meiner LAN-Netze durch den L3 Switch erfolgen soll. Und nur der Internet Traffic soll über den Lancom gehen.
Kann der Lancom Router die Adresse 192.168.1.9 (also eine Adresse aus dem VLAN1 - default VLAN) bekommen? Oder muss ich ihm eine Adresse aus einem anderen Netz geben (z.B. 192.168.0.1), damit ich auf dem Switch eine Route auf 192.168.0.1 eintragen kann? Heute kann ich nur die Default-Router auf 192.168.1.9 einstellen.

Sorry für den langen Text. Aber ich wollte Euch einfach möglichst viel Informationen geben und hoffe nun auf eine guten Tipp.
Vielen Dank!
Tom

Please also mark the comments that contributed to the solution of the article

Content-Key: 490568

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

Printed on: April 19, 2024 at 03:04 o'clock

50 Comments

Latest comment

Moin,

Es gibt bekanntlich immer viele Wege, die nach Rom führen

Variante 1 wäre:

Du baust ein fünftes VLAN (VLAN 1000, als Bsp) als Transfernetz. In dieses kommt nur der Switch mit der IP 10.1.0.2 sowie der Lancom mit der IP 10.1.0.1. Subnetzmaske ist dann /31 bzw 255.255.255.254.
Dann richtest du am Cisco für jedes Nutz-VLAN eine IP ein: 192.168.[VLAN].254/24

Als nächstes brauchst du noch Routing Einträge:

Switch: 0.0.0.0/0 über 10.1.0.1/31. hierdurch sendet der Switch alle Anfragen, deren Netze er nicht kennt über das Transfernetz zum Lancom
Lancom: 192.168.0.0/21 über 10.1.0.2/31. Dadurch sendet der Lancom alle Anfragen, die die 192.168.[VLAN].0er Netze betreffen, an den Switch (plus noch ein paar mehr).

Dann, und das war dein Fehler, erhält jedes Endgerät die IP des Switches in dem jeweiligen VLAN als Standardgateway, also Geräte im VLAN 3 z.B. Die IP 192.168.3.254
zum Absichern musst du dich dann noch mit ACLs auf dem Switch beschäftigen: alle dürfen auf das VLAN 1000 zugreifen (um ins WWW zu kommen), aber nur die VLANs 1-3 dürfen zusätzlich untereinander agieren. Das VLAN 4 hat sonst keine weiteren Rechte.

Variante 2:
Das Routing am Cisco bleibt aus.
Der Lancom muss VLANs aktiv haben: 1-4 und dort auch jeweils eine IP haben (wie oben).
Als Default Gateway erhalten die Clients dann auch wieder die IP des Lancoms aus dem jeweiligen VLAN.
Am Lancom musst du dann nur ein passendes Firewall-Regelwerk setzen, analog zu den ACLs oben.
Ferner würde ich dem Lancom auch noch den DHCP-Server aufs Auge drücken, denn dann brauch der Cisco nur eine IP, und zwar fürs Management.
Der Port Amt switch, der den Lancom angebunden hat, wird als Trunk definiert und erhält alle VLANs als tagged, außer das Gäste WLAN, das könnte man an dem Port auf untagged setzen. Am Lancom dann analog halt

Lies dir in Summe auch mal die ausführliche Anleitung des Kollegen @aqui durch. Hier ist alles sehr gut beschrieben

VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern

Edit:
Das DualWAN-Konzept würde ich obendrein umstellen:

Nutze beide Leitungen aktiv, z.B. UnityMedia (UM) für die Gäste als primären Breakout und den der Telekom (DTAG) für die VLANS 1-3. und die jeweils andere Leitung dann als Backup einrichten. Somit zählt man nicht für eine Leitung, die man nie nutzt, weil die andere eine Verfügbarkeit von 99,9% hat...

https://www.lancom-systems.de/docs/LCOS/referenzhandbuch/topics/aa119893 ...

Gruß
em-pie

Zitat von @em-pie:
Variante 1 wäre:

Du baust ein fünftes VLAN (VLAN 1000, als Bsp) als Transfernetz. In dieses kommt nur der Switch mit der IP 10.1.0.2 sowie der Lancom mit der IP 10.1.0.1. Subnetzmaske ist dann /31 bzw 255.255.255.254.

/30 oder 255.255.255.252 bitte, sonst geht da gar nix. 4 IPs braucht du schon, wenn 2 für Netzadresse und Broadcast flöten gehen.

Mit dem VLAN Modul stehe ich aber auch auf Kriegsfuß...

Ansonsten hier mal reinlesen, ich komm gerade nicht zum testen für eine feine kleine Anleitung
https://www.lancom-systems.de/docs/LCOS/referenzhandbuch/topics/aa102328 ...

Zitat von @shadynet:

Zitat von @em-pie:
Variante 1 wäre:

Du baust ein fünftes VLAN (VLAN 1000, als Bsp) als Transfernetz. In dieses kommt nur der Switch mit der IP 10.1.0.2 sowie der Lancom mit der IP 10.1.0.1. Subnetzmaske ist dann /31 bzw 255.255.255.254.

/30 oder 255.255.255.252 bitte, sonst geht da gar nix. 4 IPs braucht du schon, wenn 2 für Netzadresse und Broadcast flöten gehen.

Das entfällt bei einer 31er Maske.
Wie soll das sonst bei einer 32er Maske mit der Netz- und Braodcastadresse funktionieren ;)

https://tools.ietf.org/html/rfc3021

Mit dem VLAN Modul stehe ich aber auch auf Kriegsfuß...

Bisher sind wir mit einem einzigen /24 Netz an 3 Cisco Level 2 Switches ausgekommen

Du meinst sicherlich einen Layer 2 Switch, richtig ? Also einen der kein Routing macht ?!
Ebenso heisst es Layer 3 bei einem Routing Switch. Soviel mal zur richtigen Nomenklatur und ggf. Korrektur der Thread Überschrift.

Ich würde also sagen: die Kommunikation im Switch sieht gut aus.

Ja, das hast du soweit alles richtig gemacht !
Genau so ein Standard Design zu einem Layer 3 Konzept wie du es machst findest du auch hier:
Verständnissproblem Routing mit SG300-28
Dort ist ALLES explizit erklärt was du zur erfolgreichen Umsetzung deines richtigen Netzwerk Konzeptes wissen musst !

klar, ich muss auf dem Lancom auch noch die VLANs eintragen

Das ist auch genau richtig. Siehe den L3 Thread von oben, dort ist das anhand einer FritzBox explizit beschrieben. Nichts anderes machst du auch auf der Lancom Kiste.

Wie kann man im Lancom 1900FE überhaupt das VLAN Modul aktivieren und anschliessend das Gerät noch erreichen?

Musst du gar nicht !

Richte ein separates VLAN für den Lancom ein um dessen Traffic sauber von deinen Produktiv VLANs zu trennen.
Trage die statische Route auf deine VLANs beim Lancom ein: Zielnetz: 192.168.0.0, Maske: 255.255.128.0, Gateway: <VLAN_IP-Lancom-Koppelnetz>
Default Route 0.0.0.0/0 Gateway: <Lancom_IP>
Fertisch. Siehe o.a. L3 Tutorial !

Ist das überhaupt der richtige Weg, um VLANs ans Internet zu bekommen?

Nein. Halte dich an das o.a. Tutorial !

Kann der Lancom Router die Adresse 192.168.1.9 (also eine Adresse aus dem VLAN1 - default VLAN) bekommen?

Jein !
Die IP hängt vom Koppelnetz ab. In der Regel gibt man als Administrator Routenr aus gutem Grund immer die IPs "ganz oben" oder "ganz unten" im Netz. Bei einem 24er Prefix wie du ihn verwendest also immer die .1 und .254.
Das Koppelnetz kannst du als /24 einrichten mit diesen IPs .1 = Lancom und .254 = VLAN IP Cisco.
Du kannst es auch kleiner und "ökonimischer" machen, da du da ja niemals so viel Endgeräte hast im reinen Koppelnetz. Ein Subnetz mit 8, 16 oder 32 Adressen reicht da allemal. Sprich also 255.255.255.240 (/29) 255.255.255.240 (/28) oder 255.255.255.224 (/27)
Das ist aber kosmetisch. Viele mögen keine "krummen" Subnetzmasken und bleiben bei /24 der Einfachheit halber. Kannst du halten wie ein "Dachdecker".

Halte dich an das o.a. Tutorial, dann klappt das auch sofort !

Hi,

der übliche Fehler, über den ich auch zigmal gestolpert bin, sticht hier gleich ins Auge:

Das VLAN-Modul wird nicht aktiviert. Du brauchst es bei deiner Konfiguration nicht. Für jedes Netz, das du auf dem Lancom anlegst,
gibst du das logische Interface und die VLAN-ID für dieses Netz an.

Den Rest hat aqui ja schon genau erklärt.

Ich würde allerdings zwischen dem Lancom und dem Cisco außer dem Transfernetz auch noch das VLAN1 als Management-VLAN untagged durchreichen und dieses Netz vom Lancom per DHCP mit Adressen versorgen. Wenn du da. z.B. ETH-4 als ungenutzen Port an ein logischer Interface und dieses auf das VLAN-1 bindest, kannst du über ETH-4 immer mit dem Lappy drauf, wenn du dich mal ausgesperrt hast. Und am Cisco reservierst du dir einen Port auf VLAN1 als Backdoor für schlechte Zeiten. Hat dann noch den Nebeneffekt, das neue Hardware im VLAN1 landet und eine IP per DHCP bekommt, damit du zur Erstkonfig drauf zugreifen kannst. Den Internetzugriff aus dem VLAN 1 kannst du auf dem Lancom per FW verhindern, damit das abgeschottet ist.

Für das Gastnetz kannst du auf dem Lancom ein Netz anlegen, das Netz an das gleiche Interface wie die anderen Netze binden, auf dem Lancom DHCP für das Gastnetz aktivieren und dort eine simple Firewallregel nach dem Schema "permit Internet, deny any other" schreiben. Das Gastnetz reichst du durch bis zum Cisco, legst dort das VLAN an, gibst dem Cisco aber keine
IP-Adresse für das Gastnetz. Die Ports für das Gastnetz am Cisco legst du dann in das richtige VLAN. So schickt der Cisco erstmal alles aus dem Gastnetz zum Router und dort greift die Firewallregel, die den Zugriff in die anderen Netze verhindert.

Oder du arbeitest mit ACLs, die wiederum die aqui zwischen zwei mal Augen zwinkern runter beten kann.

Gruß NV

gibst du das logische Interface und die VLAN-ID für dieses Netz an.

Nein !
Nichtmal das braucht er ! Er terminiert ja gar keine VLANs auf dem Lancom !!! Folglich muss er dort auch rein gar nix mit VLANs rumfummeln.
Er hat ein dediziertes Koppel VLAN und dort steckt er schlicht und einfach den Lancom in einem untagged Port dieses VLANs ein. Routen konfigurieren und gut iss... Einfacher geht es nicht !
Wenn er sich an den o.a. zitierten Layer 3 Thread hält hat er das in 10 Minuten zum Fliegen....
Dann warten wir also mal auf ein Feedback vom TO !

@aqui:

Im Prinzip hast du Recht. Wenn er zwischen Cisco und Lancom nur das "Transfernetz" anliegen hat, dann
braucht er kein VLAN. Aber er muss das Transfernetz auch auf dem Lancom konfigurieren. Hier sind dann die Lancom-Namenskonventionen
zuweilen etwas verwirrend. In der Maske zum Anlegen des Netzes ist untagged hier "VLAN 0".

Ich betreibe einen Lancom 1781VA als Router und einen Cisco SG350X-24MP als L3-Switch. Zwischen den Geräten ist mein Transfernetz
(172.16.100.0/30, VLAN-ID 100) mit 172.16.100.1 (Lancom) und 172.16.100.2 (Cisco). Daneben existiert noch mein Management-Netz
(172.16.1.0/24, VLAN-ID 0 = untagged) mit 172.16.1.1 (Lancom) und 172.16.1.2 (Cisco).

Unter Schnittstellen->VLAN->VLAN-Tabelle gibt man dann auf dem lancom dem logischen Interface den Mode "Hybrid", also untagged und tagged.

Auf dem Cisco habe ich meine diversen VLANs füre Clients, Telefone, Drucker, Server etc. angelegt. Die Default-Route zeigt auf die Adresse des Lancom im Transfernetz.

Auf dem Lancom müssen dann noch im Routing die Rückrouten für die VLANs definiert werden, die er auf dem Cisco angelegt hat und dann sollte alles laufen.

Gruß NV

Hallo Zusammen,

ihr seid echt super! Trotz Wochenende so viele Antworten und alles auch noch super schnell! Vielen Dank.
Ich habe mir jetzt erst mal alle Links von Euch seit gestern Nachmittag ausführlich durchgelesen und versucht zu verstehen, wie das bei mir rein passt. Da ich erst wieder Dienstag zurück bin, kann ich erst dann Eure TIpps versuchen umzusetzen und testen, ob ich das so hinbekomme. Auch wenn es deutlich länger als 10 Minuten dauern würde, wäre ich total happy. Mir scheint, dass zwar nur wenige Einträge notwendig sind, aber die Einträge müssen eben zu 100% richtig sein...

Ich versuche erst mal zusammen zu fassen, was ich verstanden habe und dann die Dinge aufführen, zu denen ich noch Fragen habe:

Meine L3 Switch Konfig ist gar nicht so schlecht. em-pie schreibt, dass ich je VLAN eine IP auf dem Cisco einrichten soll (.254). Im Bild der Anleitung von @aqui VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern ist das die .1 (nur damit ich das richtig verstanden habe und ich nicht beides benötige)? Gibt es hier einen Art Quasi-Standard. Also besser .1. oder besser .254 verwenden?
Da mein heutiges Netz und damit sehr viele Clients als Gateway .9 für mein Hauptnetz eingetragen haben, werde ich für das VLAN1 statt .1 oder .254 die .9 als IP für die VLAN Adresse auf dem Cisco nehmen (auch wenn es nicht ganz so schön, da uneinheitlich ist).
Das Gast VLAN bekommt keine IP im Switch, damit es isoliert bleibt
Damit alle ins Internet kommen, baue ich dafür ein zusätzliches VLAN auf (das war mir komplett neu, ich hatte gedacht, dass falls es mir jemals gelingen sollte, VLANs auf dem Lancom zu aktivieren, ohne mich sofort auszusperren, ich damit automatisch ins Internet käme). Ich werde aber auf Euren Rat hören und das über das zusätzliche VLAN machen.

Fragen zum Internet-VLAN:

Das mit dem Lancom und den VLANs ist mir noch nicht klar. Verstehe ich es richtig, dass ich das VLAN Modul im Lancom NICHT aktivieren muss, aber trotzdem in der VLAN-Tabelle des Lancom das VLAN 1000 (falls das die Nr. des Verbindungs-VLANs wäre) eintragen soll. Oder sollen alle VLANs in die Tabelle eingetragen werden, nur das VLAN-Modul soll deaktiviert bleiben - ich verstehe gar nicht, das dieses Modul dann macht.
gemäß dem tollen Bild von aqui lege ich das VLAN für die Internet Verbindung auf dem Cisco an. Bekommt das VLAN eine IP? Oder gebe ich nur dem Port, an dem das Kabel zum Router an den Cisco angeschlossen ist die 10.99.99.254? Und dem Interface am Lancom an den das Kabel vom Cisco angeschlossen wird die 10.99.99.254?
Das Lancom VLAN Modul scheint mehreren Admins Probleme zu machen. Habe hier eine Anleitung eines Foren-Moderators gefunden, wie es aktiviert werden soll (Das Handbuch sagt hier was anderes - und wenn man nach Handbuch vorgeht, ist man ausgesperrt). Zur Vollständigkeit hier der Link zu der Anleitung - ich konnte es noch nicht testen: https://www.lancom-forum.de/lancom-wireless-aktuelle-accesspoint-z-b-l-4 ...

Fragen zum Gast-VLAN:

Woher bekommen die Gäste die IP-Adressen? Ich habe verstanden, dass der DHCP Server fürs Gastlan nicht auf dem Switch, sondern auf dem Lancom laufen soll. Kann ich denn eine Route vom Gast-VLAN zum Switch einrichten, wenn das Gast-VLAN gar keine .1 oder .254 IP Adresse im Switch hat? Und werden DHCP Requests auch geroutet?

Sonstige Fragen:

Ich muss vom Internet noch 2 Ports in mein Haupt-Netz (VLAN1) forwarden. Muss ich das von Router zu Router machen? Also erst ein Portforward von der Fritzbox (eigentlich von beiden Fritzboxen, falls ich über beide Alternativen (VDSL oder Kabel) reinkommen möchte) auf den Lancom und dann von dort eine Portweiterleitung von Lancon in mein 1-er Netz zum SSH Server. Oder geht das auch direkt bzw habe ich gelesen, dass ich auf der Fritzbox auch (vermutlich den Lancom) als exposed Host eintragen könnte. Das scheint zwar sehr komfortabel. Aber dann würden ja alle "Angriffe" vom Internet auf meinen Lancom gehen. Mit der dedizierten Portweiterleitung von 2 Ports auf der FB würde die FB schon mal alle anderen Ports abwehren und der Lancom würde nur noch die 2 Ports abbekommen.
Soll ich vom Lancom eine Route für alle VLANs eintragen (Zielnetz: 192.168.0.0, Maske: 255.255.128.0) oder für jedes VLAN eine eigene Route? Mit der einzigen Route würde ich ja bei der Maske nur Netze von 192.168.1. bis 192.168.31 erreichen. Also mein .50 oder .99 Netz nicht. Jetzt ist eben die Frage: die VLANs alle im Bereich 1-31 anzulegen, oder so belassen und je VLAN eine Route? Oder die Maske auf 255.255.0 verändern?
Meine beiden Fritzboxen haben ja auch noch quasi eigene Netze. In welchen Adressbereich würdet ihr diese legen (sind heute auch im 192.168.x - das muss ich wohl ändern, sonst ist es unübersichtlich oder funktioniert erst gar nicht). Gibts hier best practice?

PS: Danke für den Hinweis bzgl Nutzung beider Internet-Leitungen. Das habe ich auch vor. Allerdings ist heute die Unitiymedia Leitung noch mit langsamem Upload (4MBit) ausgestattet. Neuer Tarif ist bereits bestellt. Dann hat Telekom 180/40 MBit und Unitymedia 400/40. Und sobald dies geschaltet ist, werde ich beide aktiv nutzen

Moin,

nebenbei noch eine kurze, aber wichtige Frage:

Arbeitest du mit einer Windows-Domäne und hast einen Domänencontroller (Windows-Server) in deinem Netz?

Gruß NV

Hallo NV,
erst mal vielen Dank für die Screenshots von Deinem Lancom Router. Damit weiss ich nun schon mal, wo ich das entsprechend einstellen muss.

Zur Frage nach Windows Domäne: ja, die Windows Domäne ist zentraler und elementarer Punkt im Netzwerk. Läuft auf einem VMware Server. Auf dem Domänencontroller läuft heute auch der DNS und DHCP Server und ich hatte geplant, das fürs VLAN 1 auch so zu belassen. Für alle anderen VLANs würde DHCP auf L3 Switch laufen. Fürs Gast VLAN nach meinem Verständnis evtl auf dem Lancom Router?

Gruß Tom

Zur Frage nach Windows Domäne: ja, die Windows Domäne ist zentraler und elementarer Punkt im Netzwerk. Läuft auf einem VMware Server. Auf dem Domänencontroller läuft heute auch der DNS und DHCP Server und ich hatte geplant, das fürs VLAN 1 auch so zu belassen. Für alle anderen VLANs würde DHCP auf L3 Switch laufen. Fürs Gast VLAN nach meinem Verständnis evtl auf dem Lancom Router?

Hallo Tom,

vorab die Anmerkung, das ich kein gelernter ITler und eher erfahrener Anwender als Administrator bin. Aber ich würde DNS und DHCP auf dem Windows-Server belassen für alle Adresspools, die du für die VLANs brauchst mit Ausnahme deines "Management-VLANs" (i.d.R. VLAN1), des Transfernetzes zwischen Cisco und Lancom sowie des Gast-Netzes. Wenn die IP-Scopes im DHCP des Windows-Servers ordentlich angelegt sind und im DNS des Windows-Servers noch Reverselookup und die dynamische DNS-Aktualisierung eingerichtet ist, dann ist das wesentlich komfortabler, einfacher zu verwalten und deine Namensauflösung in der Domäne funktioniert vorwärts wie rückwärts einwandfrei.

Für das Gastnetz könntest du DNS und DHCP auf dem Lancom einrichten. Wenn du auf dem Cisco das VLAN für das Gastnetz anlegst und dem Cisco für dieses Netz KEINE eigene IP-Adresse gibst, dann geht jeglicher Verkehr aus dem Gastnetz über die auf dem Cisco angelegte Default-Route zum Lancom. Dort kannst du dann über die integrierte Firewall sehr einfach den Zugriff aus dem Gastnetz auf alle anderen Netze mit Ausnahme des Internets sperren.

Weiterhin würde ich meine Infrastruktur, also Lancom, Cisco, andere Switches, Access-Points etc. in ein Management-VLAN (i.d.R. VLAN1) packen. Dieses Netz würde ich vom Lancom beginnend durchreichen (untagged) und den Lancom DNS und DHCP für dieses Netz machen lassen. Auf dem Lancom kannst du dem Management-VLAN dann in der Firewall jeglichen Zugriff auf das Internet verbieten. Wenn du nun unkonfigurierte neue Hardware an irgendeinem ungenutzen Port (Access VLAN1) einsteckst, bekommst das neue Gerät eine IP vom Lancom und du kannst drauf zugreifen, um es einzurichten.

Aber das ist nur meine bescheidene Laien-Meinung und es gibt sicher noch unzählige andere Varianten.

Gruß Arno

Verstehe ich es richtig, dass ich das VLAN Modul im Lancom NICHT aktivieren muss

Ja, das ist richtig ! Oder vielleicht Jein... kommt drauf an wie du mit dem gastnetz umgehst, denn das ist dafür der Knackpunkt !!!

Variante 1 = Gastnetz am Switch als VLAN terminiert:
Dann brauchst du in der Tat kein VLAN. Warum auch ??
Der Router Port ist ein untagged Port, sprich also ein Port ohne VLAN Information am Switch im Transfer VLAN.
Folglich ist der Lancom Router Port also auch ein stinknormaler untagged Port also simpelste Standard Konfig.
Genau DAS entspricht dem im Layer 3 Tutorial geschilderten Design:
Vorteil:
Einfache Konfig, klare Routing Regeln, einfach umzusetzen und zu managen !
Nachteil:
Das Gastnetz ! Da es auf dem Switch mit einer VLAN IP terminiert ist bedingt dies zwingend Access Listen Regeln auf dem Cisco Switch die eine Kommunikation des Gastnetzes mit den übrigen Netzen sicher verhindern und nur spezifischen Traffic ins Internet zulassen. Diese Regel ist also Dreh- und Angelpunkt der Gastsicherheit. Weiterer Nachteil ist das die übliche Captive_Portal Konfig die viele Router mit Gast Option bieten so ggf. nicht einsetzbar ist.

Variante 2 = Gastnetz am Router als VLAN terminiert:
Wie hier die Überschrift schon sagt ist das Gast VLAN hier isoliert, sprich es hat keine IP Adresse am Switch und kann folglich dort auch NICHT geroutet werden.
Das Gastnetz wird dann mit einem tagged Uplink auf dem Router terminiert und hier mit entsprechenden Access Regeln und ggf. einem Gäste Captive Portal auf dem Router direkt terminiert.
Klar, das hier dann natürlich auf dem Router eine VLAN Konfig her muss, denn das Gastnetz kommt dort mit einem VLAN Trunk tagged an.
Vorteil:
Etwas sicherer, da es keine direkte Routing Verbindung auf dem Layer 3 Switch gibt. Access Liste auf dem Switch entfällt deshalb. IP mässig landet der Gasttraffik direkt auf dem Router. Ggf. Captive Portal Funktion des Routers mit Einmalpasswörtern (Voucher/Tickets) für Gäste ungehindert nutzbar.
Nachteil:
VLAN Konfig auf dem Router erforderlich, sprich etwas mehr Konfig Aufwand am Router. Dieses Szenario ist hier beschrieben !
Kollege @NixVerstehen hat also nicht ganz Unrecht wenn er es so macht, denn diese 2. Variante biete einige Vorteile für das Design.
Es ist aber letztlich deine eigene Entscheidung wie du das umsetzt. Der obige Weg ist aber richtig. VLAN 1 am Router und das Gast VLAN da tagged anliefern. Sprich also die Tagged Variante am Lancom. Aber eben rein nur für VLAN 1 und das Gastnetz.
Auch was das Thema DNS betrifft ist es richtig was Kollege @NixVerstehen bereits gesagt hat.
Belasse das zentral auf dem Windows Server und richte hier aber (Wichtig !) eine DNS Weiterleitung auf die Lancom Router IP im Transfer Netz ein ! So funktioniert die lokale und auch externen DNS Auflösung im Netz fehlerfrei.
Gleiches gilt übrigens auch für DHCP wenn man das so machen möchte !
DHCP kann man zentralisiert auf dem Windows Server belassen und nicht auf dem Switch konfigurieren. Das Einzige was man dann auf dem Switch machen muss ist dort auf den VLAN IP Interfaces ohne DHCP Server die sig. DHCP Relay Funktion (IP Helper Adresse) auf die IP des DHCP Servers einzustellen damit DHCP Requests aus den VLAN egmenten ohne DHCP vom Switch an den zentralen DHCP Server weitergereicht werden.
Ausnahme natürlich das Gastnetz bei Variante 2, da ja isoliert. Aber da macht ja dann der Router die DHCP Vergabe.
Da wie du selber sagst DNS und DHCP zentral ist solltest du das auch beibehalten. Dann also die 2 wichtigen Punkte bedenken:

DNS Weiterleitung auf die Lancom IP im Transfer Netz am DNS Server. (Lancom ist Proxy DNS)
IP Helper (DHCP Relay) an den VLAN IP Interfaces des Switches ohne DHCP auf die DHCP Server IP konfigurieren.
Entsprechend im Windows DHCP Server die DHCP Scopes für die VLAN Netze einrichten. Getaway = immer die Switch VLAN IP, DNS = Windows Server IP.

Die Lösung des Kollegen @NixVerstehen ist also die Profi Lösung, denn so ein Laie wie er sagt ist er gar nicht !!

@aqui: Hurra...ich wurde in den Adelsstand erhoben

Danke sehr...also doch etwas von dir gelernt

Dann probiere ich doch mal die Variante 2 und versuche VLANs am Lancom zu aktivieren.

Könntest Du bitte (sorry) nochmal schreiben, was Du mit "terminiert" meinst? D.h. das VLAN geht dann bis dort hin und dort wo es terminiert hat es quasi eine IP Adresse. Für Variante 2 wäre das dann so, dass meine normalen VLANs ein IP im Switch haben und damit dort enden. Sie kommen nur über die Route (Default-Route) zum Internet-Verbindungs-VLAN und so zum Lancom Router? Und das Gast VLAN hat keine IP am Switch, aber in Variante 2 ist das Gast VLAN sowohl im Router als auch im Switch angelegt und somit erreicht das Gast VLAN auch den Lancom Router?

Bei Variante 2 ist das Berechtigungsthema doch einfach vom Switch auf den Router verlagert? Nur habe ich dann nur 2 VLANs im Lancoms (habe ich das richtig verstanden): Internet-Verbindungs-VLAN 1000 und das Gast-VLAN?

@NixVerstehen: hast Du 2 VLANs am Lancom und diese Variante gewählt? Oder wie trennst Du Gast-Netz von den anderen Netzen - ich hatte Dich so verstanden, dass Du ganz ohne VLANs am Lancom auskommst.

ACLs traue ich mir nicht zu. Ich bin eh schon ganz verwirrt und froh, wenn ich dies so hinbekomme.

Noch eine Alternativ-Vorschlag: heute habe ich schon ein Gastnetz mit meinem L2 Switch am Laufen: Das Gast Netz ist eigentlich nur ein Gast WLAN (ohne Anmelde-Portal - wer das Passwort kennt, ist im Gast-WLAN). Derjenige der das damals eingerichtet hat, hat auf dem bisherigen L2 Switch ein VLAN99 angelegt. Und dieses VLAN direkt mit der Fritzbox von Unitymedia verbunden. Die ist ja quasi eh in einem getrennten Netz und dort läuft ein DHCP Server. Die gesamte Trennung übernimmt quasi der WLAN Controller von Zyxel. Der hat einen Trunk Port (VLAN1 und 99) zum Switch. Vom Switch werden die 4 APs (ebenfalls Trunk mit VLAN 1 und 99) versorgt. Und dann ist an dem Zyxcel WLAN Controller auch noch ein Port mit der FritzBox von Unitymedia verbunden. Über diesen Port ist das VLAN99 auf dem Zyxel konfiguriert. D.h. darüber bekommt der Zyxel den Gastnetz-Zugang. Da Unitymedia heute ja nur das Backup Netz ist, läuft über die Unitymedia Leitung quasi nur das Gast-Netz und nur falls VDSL ausfällt, läuft der gesamt Traffic über Unitymedia.
Dies könnte ich natürlich so weiter betreiben. Aber ist das nicht genau die Idee eines VLANs, diese direkten Kabel abzuschaffen? Auf der anderen Seite hätte es den großen Vorteil, dass ich weder auf dem Switch noch auf dem Router etwas mit dem Gast-WLAN/LAN zu tun habe. Ich muss das VLAN Gast auf dem Switch nur anlegen, damit der WLAN Controller eine Zuordnung von SSID und VLAN hinbekommt und beide (Gast und Firmennetz) über den entsprechenden Zugang Internet bekommen.
Ist das eine valide Konfig? Oder eher gefährlich / Gebastel?

So in etwa. Auf irgendeinem Gerät muß ja das Netz (VLAN mit Adressbereich) angelegt sein. Wenn du auf dem Lancom das Gastnetz anlegst, dann konfigurierst du dort den Namen des Netzes (z.B. Gastnetz), die VLAN-ID (z.B. 99), die IP-Adresse des virtuellen Routers, den der Lancom in diesem Netz haben soll und ggf. in den DHCP-Einstellungen des Lancom den Adressbereich für DHCP, den DNS-Server (Adresse des Lancom im Gastnetz), Adresse des DHCP-Servers (Adresse des Lancom im Gastnetz).

Für Variante 2 wäre das dann so, dass meine normalen VLANs ein IP im Switch haben und damit dort enden.

Korrekt! Für jedes VLAN hat der Switch eine eigene "virtuelle" IP-Adresse. Quasi sind das dann mehrere "Router" mit eigenen Adressen
in einem Gerät. Wenn du dem Cisco für ein VLAN eine Adresse vergibst, dann ist diese Adresse für dieses VLAN. Das nächste VLAN bekommt eine eigene "virtuelle" IP auf dem Cisco und ist dann Router für dieses VLAN. Da der Cisco selbst für jedes VLAN, in dem er eine IP->Adresse von dir bekommt, auch der Default-Gateway für das jeweilige VLAN ist, kann er die Pakete auch zwischen den VLANs selbst routen. Da geht dann nichts bis zum Lancom. Alles was er nicht kennt, schickt er auf die Default-Route, also das Transfernetz zum Lancom.

Sie kommen nur über die Route (Default-Route) zum Internet-Verbindungs-VLAN und so zum Lancom Router? Und das Gast VLAN hat keine IP am Switch, aber in Variante 2 ist das Gast VLAN sowohl im Router als auch im Switch angelegt und somit erreicht das Gast VLAN auch den Lancom Router?

Genau. Trenne gedanklich die Begriffe VLAN und Netz. Du kannst auf dem Switch VLANs anlegen, ohne ein Netz hierfür auf dem Switch zu definieren.
Das heißt dann für den Cisco nur, das er alles aus dem Gastnetz passieren lässt, wenn man ihm es auf dem Trunkport zum Lancom gestattet. Wenn der Cisco für ein bestimmtes Netz zwar das VLAN kennt, aber selbst keine eigene IP-Adresse in diesem Netz hat, dann schickt er alle Pakete aus diesem Netz über die Default-Route (Transfernetz) zum Lancom. Der wiederum kennt das Gastnetz ja wieder und weiß, was er mit den Paketen anfangen soll. Für das Gastnetz ist dann z.B. das Default-Gateway, das du per DHCP verteilst, die Adresse des Lancom in diesem VLAN. Alle anderen VLANs, die auf dem Cisco "terminiert" sind, erhalten per DHCP die jeweilige "virtuelle" IP des Cisco aus dem entsprechenden VLAN. Erkennt der Cisco dann z.B. ein Paket für eines deiner andern VLANs, routet er es dort hin. Hat das Paket eine externe Adresse, schickt er es über die Default-Route zum Lancom und der schubst es ins Internet.

Bei Variante 2 ist das Berechtigungsthema doch einfach vom Switch auf den Router verlagert? Nur habe ich dann nur 2 VLANs im Lancoms (habe ich das richtig verstanden): Internet-Verbindungs-VLAN 1000 und das Gast-VLAN?

Korrekt. Da kannst du dann eine Abgrenzung des Gastnetzes über eine Firewall-Regel auf dem Lancom machen und musst dich
nicht mit den ACLs des Cisco auseinandersetzen. Wenn du ein Management-VLAN (meistens VLAN1) haben willst, sind es natürlich 3 VLANs zwischen Cisco und Lancom.

@NixVerstehen: hast Du 2 VLANs am Lancom und diese Variante gewählt? Oder wie trennst Du Gast-Netz von den anderen Netzen - ich hatte Dich so verstanden, dass Du ganz ohne VLANs am Lancom auskommst.

Ich hatte in meinem Screenshot weiter oben ein paar Sachen ausgeblendet, um dich nicht noch mehr zu verwirren

Dir reichen ohne Management-VLAN auf dem Lancom das Transfernetz zum Cisco (Default-Route) und das Gastnetz. Wenn du noch das Management-VLAN möchtest, brauchst du 3 VLANs.

ACLs traue ich mir nicht zu. Ich bin eh schon ganz verwirrt und froh, wenn ich dies so hinbekomme.

Ich weiß...es ist sehr viel zu lesen und noch mehr zu verstehen für jemand, der das nicht täglich macht. Aber einfach dran bleiben und fragen.
Geht mir heute noch so, das ich mir das alles mühsam in den Kopf klopfen muss.

Noch eine Alternativ-Vorschlag: heute habe ich schon ein Gastnetz mit meinem L2 Switch am Laufen: Das Gast Netz ist eigentlich nur ein Gast WLAN (ohne Anmelde-Portal - wer das Passwort kennt, ist im Gast-WLAN). Derjenige der das damals eingerichtet hat, hat auf dem bisherigen L2 Switch ein VLAN99 angelegt. Und dieses VLAN direkt mit der Fritzbox von Unitymedia verbunden. Die ist ja quasi eh in einem getrennten Netz und dort läuft ein DHCP Server. Die gesamte Trennung übernimmt quasi der WLAN Controller von Zyxel. Der hat einen Trunk Port (VLAN1 und 99) zum Switch. Vom Switch werden die 4 APs (ebenfalls Trunk mit VLAN 1 und 99) versorgt. Und dann ist an dem Zyxcel WLAN Controller auch noch ein Port mit der FritzBox von Unitymedia verbunden. Über diesen Port ist das VLAN99 auf dem Zyxel konfiguriert. D.h. darüber bekommt der Zyxel den Gastnetz-Zugang. Da Unitymedia heute ja nur das Backup Netz ist, läuft über die Unitymedia Leitung quasi nur das Gast-Netz und nur falls VDSL ausfällt, läuft der gesamt Traffic über Unitymedia.
Dies könnte ich natürlich so weiter betreiben. Aber ist das nicht genau die Idee eines VLANs, diese direkten Kabel abzuschaffen? Auf der anderen Seite hätte es den großen Vorteil, dass ich weder auf dem Switch noch auf dem Router etwas mit dem Gast-WLAN/LAN zu tun habe. Ich muss das VLAN Gast auf dem Switch nur anlegen, damit der WLAN Controller eine Zuordnung von SSID und VLAN hinbekommt und beide (Gast und Firmennetz) über den entsprechenden Zugang Internet bekommen.
Ist das eine valide Konfig? Oder eher gefährlich / Gebastel?

Hmm...da tippe ich ein wenig ins Blaue. Deshalb hier mal wie ich es gemacht habe:
Ich verwende 2 Cisco WAP150 APs. Die Konfigoberflächen der APs sind im VLAN1, die Daten aus dem WLAN laufen über die APs und Switches in meinen VLAN70 (Gastnetz). Mein Cisco L3-Switch hat keine IP für das Gastnetz und mein Lancom-Router kümmert sich um DNS / DHCP. Auf dem Lancom hab ich ein Captiva-Portal mit WLAN-Vouchers. Würde jetzt ein Gerät im WLAN auf ein Gerät in einem anderen VLAN zugreifen wollen, läuft das Paket nun bis zum Lancom, weil es der Cisco nicht selbst routen kann (kennt er ja nicht) und auf dem Lancom verbietet den Zugriff die Firewall auf meinem Lancom.

So ähnlich würde ich das an deiner Stelle aufbauen. Die beiden Leitungen und Fritzboxen würde ich dann als Haupt- und Fallbackleitung
einrichten. Wobei du dem Lancom aber trotzdem beibringen kannst, das z.B. der Gastnetztraffic immer über die Fallbackleitung raus geht.
Das ist machbar.

Gruß Arno

was Du mit "terminiert" meinst?

Damit ist gemeint das die IP Gateway Adresse dieses Netzwerk (VLAN) Segments da liegt. Sprich aller Traffic dann immer über das Gerät muss was die Gateway IP dieses Segmentes hält.

aber in Variante 2 ist das Gast VLAN sowohl im Router als auch im Switch angelegt und somit erreicht das Gast VLAN

Richtig, hat ja aber keine IP Adresse auf dem Switch und ist damit von den anderen VLAN physisch vollkommen isoliert. Der Weg raus geht dann nur über den lancom, was ja auch so gewollt ist.

Bei Variante 2 ist das Berechtigungsthema doch einfach vom Switch auf den Router verlagert?

Wenn du mit "Berechtigungsthema" Access- oder Firewall Listen meinst dann ja. Wie gesagt der IP Traffic fliesst einzig und allein so über den lancom weil nur der die Gateway IP hat.

ACLs traue ich mir nicht zu.

Sind aber kinderleicht....

ohne Anmelde-Portal - wer das Passwort kennt, ist im Gast-WLAN

Oha...gruselig. Das ist rechtlich ein russisches Roulette und für einen Frima ein ziemliches NoGo.
Einmalpasswörter mit Vouchers wären da idealer:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)

Vom Switch werden die 4 APs (ebenfalls Trunk mit VLAN 1 und 99) versorgt.

OK, das ist ein simples MSSID Design wie es durch die Bank üblich ist. Alles was man dazu wissen muss steht hier:
VLAN Installation und Routing mit pfSense, Mikrotik, DD-WRT oder Cisco RV Routern
Das kann man so belassen, in der Tat. Sollte man auch. Dort ist in der regel immer das Default VLAN dran (Management) und das getaggte Gastnetz. In Management VLAN sollte man niemals eine SSID legen. Die SSIDs (WLANs) legt man tunlichst immer nur auf getaggte Netze.
Das Tutorial oben erklärt das ja alles.
Zyxel supportet auf dem Controller ja auch ein Captive Portal mit Einmalpasswörtern. Das solltest du dort in jedem Falle für das Gastnetz aktivieren !!

@aqui: ich glaube, Du hast mich überzeugt. Ich werde das mit den ACLs versuchen. Habe mich die letzten 2 Stunden mal eingelesen und ein paar youtube tutorials angeschaut. Soooo schwierig scheint es nicht zu sein.
Das scheint mir doch am zukunftsträchtigsten zu sein. ich würde dann das gesamte Routing auf dem Switch belassen und die Verbindung zum Lancom über ein Internet-Transfer VLAN realisieren (ohne VLAN Modul am Switch).

Gibt es eine gute Strategie, um das Gast LAN abzuriegeln. Sprich: verbiete ich dem Gast VLAN, dass es in andere Netze darf. Oder mache ich das genau andersrum, also verbiete pro VLAN den Zugriff vom Gast-VLAN?

Soooo schwierig scheint es nicht zu sein.

Ist in der Tat recht einfach. 2 Dinge gibt es immer zu beachten

ACL wirken immer inbound also vom Draht in das VLAN IP Interface rein
Es gilt: "First match wins" Sprich der erste positive Hit in den Regeln bewirkt das die nachfolgenden NICHT mehr abgearbeitet werden. Reihenfolge im Regelwerk der ACL zählt hier also !!

Kleines Beispiel:
Eine ACL hat immer erst die Quell Adresse und dann das Ziel, also von x (Quelle) nach y (Ziel)
Dein Gastnetz VLAN hat die 172.16.1.0 /24 und darf nur ins Internet. Die anderen VLANs liegen auch im 172.16er Bereich:
access-list 100 DENY ip 172.16.1.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 100 PERMIT ip 172.16.1.0 0.0.0.255 any
Diese Liste wird dann an das VLAN IP Interface gebunden !
Sie verbietet alles was 172.16.1.x als Absender hat und irgendeine Zieladresse die mit 172.16.y.y anfängt
Alles was anders ist als 172.16.y.y darf passieren. Kannst du an der quasi selbsterklärenden Syntax schon sehen.
Das wäre deine einfache Gastnetz Access Liste.

Jetzt willst du noch verhindern das die Gäste illegales Filesharing usw. machen und erlaubst deshalb nur Browser (TCP 80 und 443) Traffic:
access-list 100 DENY ip 172.16.1.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 100 PERMIT tcp 172.16.1.0 0.0.0.255 any eq tcp 80
access-list 100 PERMIT tcp 172.16.1.0 0.0.0.255 any eq tcp 443
(eq = equals = entspricht)
Diese Liste verbietet wieder alles was 172.16.1.x als Absender hat und irgendeine Zieladresse die mit 172.16.y.y anfängt
Alles was anders ist als 172.16.y.y und als Zielport TCP 80 (HTTP) oder TCP 443 (HTTPS) hat darf passieren.
Nach dem Muster kannst du dir den Rest dann einfach selber zusammensstricken

Aber immer Vorsicht. Der Teufel lauert wie immer im Detail...
Die obige Liste lässt also auf den ersten Blick nur Browser Traffic zu, sprich alle Gäste können nur surfen. Implementierst du diese Liste wirst du aber schnell merken das in der Praxis gar nichts geht !!
Vielleicht siehst du den Fehler selber ?!
Richtig ! DNS fehlt, denn der Gast muss ja Adressen wie www.administrator.de in eine IP Adresse auflösen und das kann nur das DNS Protokoll. Ohne DNS also kein Internet Traffic. Das sollte in einer ACL also immer per Default drin sein, damit die Namensauflösung klappt. DNS nutzt TCP und auch UDP deshalb sähe die Gastnetz ACL die dann auch funktioniert so aus:
access-list 100 DENY ip 172.16.1.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 100 PERMIT udp 172.16.1.0 0.0.0.255 any eq udp 53
access-list 100 PERMIT tcp 172.16.1.0 0.0.0.255 any eq tcp 53
access-list 100 PERMIT tcp 172.16.1.0 0.0.0.255 any eq tcp 80
access-list 100 PERMIT tcp 172.16.1.0 0.0.0.255 any eq tcp 443
Probier es selber aus !!

Und noch ein Achtung !!
Gesetzt den Fall du betreibst einen DHCP Server müssen ja auch DHCP Requests passieren dürfen. Das können sie so natürlich nicht mit der Folge das dann Gäste erst gar keine IP Adresse per DHCP bekommen !
Also ganz funktioniert sie dann noch nicht bei Verwendung von DHCP.
DHCP sendet Request Broadcasts mit dem Absender 0.0.0.0 (klar Client hat ja keine IP) und Ziel 255.255.255.255 (All Net Broadcast mit dem Zielport 67. (Siehe dazu auch [https://de.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Ablauf_der_DHCP-Kommunikation HIER| auf dem UDP Zielport. Da die 0.0.0.0 auch passieren muss sieht das dann final so aus:
access-list 100 DENY ip 172.16.1.0 0.0.0.255 172.16.0.0 0.0.255.255
access-list 100 PERMIT udp any any eq udp 67
access-list 100 PERMIT udp 172.16.1.0 0.0.0.255 any eq udp 53
access-list 100 PERMIT tcp 172.16.1.0 0.0.0.255 any eq tcp 53
access-list 100 PERMIT tcp 172.16.1.0 0.0.0.255 any eq tcp 80
access-list 100 PERMIT tcp 172.16.1.0 0.0.0.255 any eq tcp 443
Damit hast du nun endlich eine funktionierende Gast Access Liste.
Das kannst dann nun endlich mit einem Testrechner selber im Gastnetz mal probieren.
Fazit: Man muss und sollte wissen was man in einem Netzwerk Segment haben will und was nicht.
Im Zweifel hilft da immer der kotenlose Wireshark Sniffer ! Der hat schon so manchem die Augen geöffnet was im Netz abgeht...und was nicht.

Ich habe mich nun daran gemacht und versucht, die oben von Euch empfohlene Konfig umzusetzen und scheitere aber bereits am Switch.
Zuerst habe ich mal die Zielkonfig aufs Papier gebracht. So soll es aussehen:

Ich habe eigentlich nur 3 Dinge geändert

Ein zusätzliches VLAN 1000 für das InternetTransfer Netz inkl. IP angelegt.
Meine IP vom VLAN1 geändert (von 192.168.1.251 auf .9). Dies ging aber nur, indem ich mich übers VLAN2 an den Switch verbunden habe und VLAN1 IP gelöscht und dann wieder neu angelegt habe.
Die statische Route zum Lancom VLAN Netz angelegt.

Seither funktioniert das Inter-VLAN-Routing nicht mehr. Ich kann also vom Client in VLAN1 nur noch 192.168.1.9 aber nicht das VLAN2 Netz (192.168.2.1) anpingen. Auch auf Console kann ich kein anders VLAN anpingen.

Ich habe mir mal die gesamte Konfig anzeigen lassen. Hierzu 2 Anmerkungen: was bedeutet bei interface vlan1 "no ip address dhcp" und mein nameserver und dns eintrag steht auf 192.168.1.9 - eigentlich wollte ich dem Lancom mal diese Adresse geben, bis ihr mir das mit dem TransferVLAN erklärt habt. Jetzt müsste DNS und nameserver ja vermutlich die 10.99.99.1 (Lancom Router) bekommen? Kann das das Problem sein?

switch4#show running-config
config-file-header
switch4
v2.5.0.83 / RTESLA2.5_930_364_091
CLI v1.0
file SSD indicator encrypted
@
ssd-control-start
ssd config
ssd file passphrase control unrestricted
no ssd file integrity control
ssd-control-end cb0a3fdb1f3a1af4e4430033719968c0
!
!
unit-type-control-start
unit-type unit 1 network gi uplink te
unit-type unit 2 network gi uplink te
unit-type unit 3 network gi uplink te
unit-type unit 4 network gi uplink te
unit-type-control-end
!
vlan database
vlan 2,50,70,99,1000
exit
voice vlan oui-table add 0001e3 Siemens_AG_phone________
voice vlan oui-table add 00036b Cisco_phone_____________
voice vlan oui-table add 00096e Avaya___________________
voice vlan oui-table add 000fe2 H3C_Aolynk______________
voice vlan oui-table add 0060b9 Philips_and_NEC_AG_phone
voice vlan oui-table add 00d01e Pingtel_phone___________
voice vlan oui-table add 00e075 Polycom/Veritel_phone___
voice vlan oui-table add 00e0bb 3Com_phone______________
ip dhcp server
ip dhcp pool network "DHCP VLAN1"
address low 192.168.1.220 high 192.168.1.250 255.255.255.0
domain-name setdom.lan
dns-server 192.168.1.9
exit
ip dhcp pool network "DHCP VLAN2"
address low 192.168.2.101 high 192.168.2.249 255.255.255.0
domain-name setdom.lan
exit
ip dhcp pool network "DHCP VLAN50"
address low 192.168.50.101 high 192.168.50.249 255.255.255.0
domain-name setdom.lan
dns-server 192.168.1.9
exit
ip dhcp pool network "DHCP VLAN99"
address low 192.168.99.101 high 192.168.99.249 255.255.255.0
domain-name setgast.lan
exit
bonjour interface range vlan 1
hostname switch4
username admin password encrypted ….
ip ssh server
snmp-server location "Stackswitch - 2 x Serverraum; 1 x Produktion"
clock timezone MEZ +1
clock summer-time web recurring eu
ip name-server 192.168.1.9
ip telnet server
!
interface vlan 1
name SET
ip address 192.168.1.9 255.255.255.0
no ip address dhcp
!
interface vlan 2
name Clients
ip address 192.168.2.1 255.255.255.0
!
interface vlan 50
name IP-Telefonie
ip address 192.168.50.1 255.255.255.0
!
interface vlan 70
name Produktion
ip address 192.168.70.1 255.255.255.0
!
interface vlan 99
name Gast
ip address 192.168.99.1 255.255.255.0
!
interface vlan 1000
name InternetTransfer
ip address 10.99.99.254 255.255.255.0
!
interface GigabitEthernet1/0/13
switchport access vlan 50
switchport general pvid 50
switchport trunk native vlan 50
!
interface GigabitEthernet2/0/13
switchport access vlan 2
switchport general pvid 2
switchport trunk native vlan 2
!
interface GigabitEthernet2/0/19
switchport access vlan 99
switchport general pvid 99
switchport trunk native vlan 99
!
exit
ip default-gateway 10.99.99.1

Zuerst habe ich mal die Zielkonfig aufs Papier gebracht. So soll es aussehen:

Das sieht alles gut und richtig aus !

Die statische Route zum Lancom VLAN Netz angelegt. Seither funktioniert das Inter-VLAN-Routing nicht mehr.

Das ist auch Quatsch !
Denke mal selber etwas nach. Das "Lancom VLAN Netz" ist dein VLAN 1000, richtig ? Dafür musst du keine Route anlegen ! Wozu auch ??
Das und auch alle anderen VLANs sind doch direkt am Switch (Stack) angeschlossen. Der Switch "kennt" also ALLE VLAN IP Netze damit. Logisch, denn sie hängen ja direkt an ihm dran ! Routen sind damit also doch dann vollkommen überflüssig und zudem auch noch kontraproduktiv !
Das einzige was du auf dem Switch Stack brauchst ist eine statische Default Route (KEIN Default Gateway) auf die Lancom IP Adresse im VLAN 1000. Sprich also: 0.0.0.0 /0 10.99.99.1 ! Das ist ALLES !

Bitte halte dich genau an das Layer 3 Tutorial wo das doch nun alles Schritt für Schritt am Beispiel eines Cisco Switches erklärt ist:
Verständnissproblem Routing mit SG300-28

was bedeutet bei interface vlan1 "no ip address dhcp"

Das bedeutet das die DHCP Client Funktion hier am VLAN 1 IP Interface deaktiviert ist. Das VLAN 1 Interface kann sich also keine IP Adresse automatisch per DHCP ziehen. Ist normal wenn man eine IP statisch dort vergibt, dann wird das automatisch gesetzt was ja auch irgendwie Sinn macht.

und mein nameserver und dns eintrag steht auf 192.168.1.9

Tja, das hast du dann wohl falsch konfiguriert. bedeutet das der Switch dann keinerlei Hostnamen auflösen kann z.B. beim NTP Server usw. Solltest du also beser korrigieren !

Jetzt müsste DNS und nameserver ja vermutlich die 10.99.99.1 (Lancom Router) bekommen?

Jein !

JA = Wenn du keinen anderen DNS Server im Netz hast
Nein = Wenn du einen DNS Server im Netz hast wie einen Winblows DNS z.B. Dann bekommt der Switch diese IP. Der ggf. vorhandene lokale DNS Server (Winblows etc.) hat dann immer eine DNS Weiterleitung auf die Lancom IP. Der Lancom ist ja dann immer DNS Proxy Server zum Internet.

Kann das das Problem sein?

Eher nein. Ein falscher DNS bedeutet ja nur das der Switch selber keine Hostnamen auflösen kann. Er kann dann z.B. die Uhrzeit nicht richtig setzen usw. Das ist aber kosmetisch und hat auf die Layer 2 und Layer 3 Grundfunktionen des Switches keinerlei Einfluss.
Vermutlich ist es deine falsche oder fehlende Default Route ?!

Was weiter falsch aussieht sind deine Access Ports am Switch ! Die sind NICHT als Accesss Ports definiert sondern als Trunk Ports was falsch ist. Jeder Port der ein ungetaggtes Endgerät bedient solltest du immer als Access Port in den Port Settings definieren.
Rein nur wo du Tagged Traffic hast z.B. auf den Inter Switch Links und auf den MSSID APs usw. hast du Trunk Ports (getaggte Ports) ! Trunks sollten nie auf Endgeräte Ports definiert sein, da Endgeräte nie taggen.

Heisser Tip noch zur Switch Grundkonfig. Die SG Modelle telefonieren alle nach Hause zu Cisco über die PNP Funktion (Autokonfig). Das solltest du deaktivieren im Setup (Haken entfernen bei enable)

Hallo Aqui,

die default route habe ich eigentlich schon. Sieht fast aus wie bei deinem Screenshot. Nur kann ich beim Anlegen der statischen Route kein VLAN Interface auswählen und daher ist bei mir das Feld VLAN leer (bei Dir steht VLAN1 drin; bei müsste das dann VLAN 1000 = InternetTransfer VLAN sein). Kann ich aber wie gesagt nicht auswählen. Habe die Route auch gelöscht und neu angelegt. Geht trotzdem nicht.

Was meinst Du mit "Was weiter falsch aussieht sind deine Access Ports am Switch ! Die sind NICHT als Accesss Ports definiert sondern als Trunk Ports was falsch ist."? Wenn ich unter VLAN Settings auf Interface Settings gehe, sind alle meine Ports als Access Ports definiert. Siehe Screenshot. Oder muss ich das nochmals woanders zusätzlich angeben? Ich habe in meiner Testumgebung ja lediglich einen einzigen Port, an den kein Endgerät angeschlossen ist. Nämlich den Port 1 auf Switch 2, der mit dem Lancom verbunden ist. Der stand bisher auch auf Access. Den habe ich jetzt auf Trunk. Und siehe da: plötzlich ging der Ping von einem VLAN zum anderen.
Aber nur, solange das Kabel zwischen Switch und Lancom verbunden war. Ich vermute daher, dass jetzt das Routing über den Lancom lief? Das will ich ja nicht, da ich hier ja nur 1GBit habe und damit der gesamte Traffic von VLAN2 zu VLAN1 über den Lancom laufen würde. Oder liege ich hier falsch. Müsste das VLAN Routing nicht auch ohne Verbindung zum Lancom funktionieren.
Was ich allerdings komisch finde, ist, dass bei den Port Settings hinter allen Ports Layer2 steht. Wenn ich das auf Layer 3 setzen würde (habe ich nicht gemacht), kann ich aber nicht mehr zwischen Access und Trunk auswählen. Das ist dann grau.

Und hier habe ich noch einen Screenshot mit den VLANs und IP Routing enabled:

DNS habe ich den Lancom und 8.8.8.8 (als Prio 2) eingetragen. Und PNP habe ich deaktivert.

Ich habe mich eigentlich an die Anleitung Schritt für Schritt gehalten. Scheitere aber am VLAN Routing (zumindest bei gezogenem Kabel zum Lancom). Und wenn ich das Kabel verbinde, dann kann ich zwar die Switch IP Adressen anpingen, aber ich komme nicht bis zum Lancom.

Nur kann ich beim Anlegen der statischen Route kein VLAN Interface auswählen

Das macht der Switch automatisch, da du ihm ja die .254 schon deinem VLAN 1000 Interface zugewiesen hast...hoffentlich ?!

Was meinst Du mit "Was weiter falsch aussieht sind deine Access Ports am Switch !

Die Port Mode Deklarationen von Endgeräte Ports sahen in der ASCII Text Konfig falsch aus. Muss aber nicht so sein. Wie gesagt Endgeräte Ports sind immer Access Ports und sollten so aussehen in der Port Übersicht:
(Beispiel hier Port 1 = Tagged Uplink auf anderen Switch, Port 2 bis x = Engeräte Ports PC etc.

sind alle meine Ports als Access Ports definiert.

Wenn es so aussieht dann ist das auch alles richtig !

Oder muss ich das nochmals woanders zusätzlich angeben?

Nein, alles gut und richtig so !

Nämlich den Port 1 auf Switch 2, der mit dem Lancom verbunden ist. Der stand bisher auch auf Access.

Ist auch richtig so !

Den habe ich jetzt auf Trunk. Und siehe da: plötzlich ging der Ping von einem VLAN zum anderen.

Das ist vollkommen unmöglich ! Es sei denn....
Du hast das VLAN 1000 tagged auf den Lancom Port gelegt !!!
Dann musst du logischerweise am Switch in den Trunk Mode damit der das VLAN 1000 tagged dort akzeptiert !
Tagged Pakete an einem renen Access Port werden natürlich verworfen.
Vermutlich hast du hier also einen Tagging Mismatch zw. Lancom und Switch, kann das sein ?!

Aber nur, solange das Kabel zwischen Switch und Lancom verbunden war

Das ist klar und logisch. Ohne das Kabel hast du keinen aktiven Link mehr im VLAN 1000 und der Switch nimmt das IP Interface dann auf DOWN, sprich nicht erreichbar. Macht ja auch Sinn wenn da nix mehr ist...
Trotzdem routet der L3 Switch natürlich noch weiter wenn sich z.B. 2 Geräte in VLAN 2, 50, 99 usw. oder anderen befinden. Die werden weiter untereinander geroutet und sind pingbar.

Ich vermute daher, dass jetzt das Routing über den Lancom lief?

"Vermuten" ist ganz schlecht in der IT, weisst du auch selber !

Du musst ja nicht vermuten ! Du kannst das doch ganz klar an deinen Endgeräten sehen WAS die dort als Default Gateway IP eingetragen haben !! Genau DAS Gerät was diese Gateway IP hat, das routet dann auch den Traffic. Die Gateway IP entscheidet also eindeutig WER routet !!
Parallel zeigt dir das doch auch ein Traceroute auf das Ziel (tracert bei Winblows) ! Das zeigt dir den ganzen Routing Weg Hop für Hop einzeln an und so hast du absolute Gewissheit ! Sollte man als Netzwerker eigentlich kennen das Kommando...

Wenn ich das auf Layer 3 setzen würde (habe ich nicht gemacht), kann ich aber nicht mehr zwischen Access und Trunk auswählen.

Auch das ist klar und logsch, denn dann machst du diesen Port zu einem dedizierten Router Port auf dem direkt die IP Adresse liegt. "Layer 2" ist schon richtig wenn du mit VLANs arbeitest !

DNS habe ich den Lancom und 8.8.8.8 (als Prio 2) eingetragen.

Zu 8.8.8.8 muss man wohl nix mehr sagen. Sowas machen heute nur noch Dummies die sich ausschnüffeln lassen wollen. Nimm immer besser eine Adresse da die deine Privatsphäre besser schützt wie 9.9.9.9
https://www.heise.de/newsticker/meldung/Quad9-Datenschutzfreundliche-Alt ...

dann kann ich zwar die Switch IP Adressen anpingen, aber ich komme nicht bis zum Lancom.

Wie gesagt hier checken ob Tagging am Lancom aktiv und ob der Lancom irgendwelche Firewall Regeln aktiv hat die die anderen IPs blocken. Statische Routen auf alle deine VLAN IP Netze (außer 1000 natürlich) sollte dein Lancom natürlich auch haben.
Da reicht eine Summary Route: Ziel: 192.168.0.0, Maske: 255.255.128.0, Gateway: 10.99.99.254 um alle deine derzeitigen VLAN Netze auf dem Switch abzudecken.
Du kannst mit Ziel: 192.168.0.0, Maske: 255.255.0.0, Gateway: 10.99.99.254 auch generell alle 192.168er Netze zum Switch routen um auf Nummer sicher zu gehen

Ansonsten ist die Switchkonfig soweit absolut korrekt und richtig.

Hallo Aqui,

ich würde gerne nochmal einen Schritt zurück gehen, da ich bereits hier ein Problem zu haben scheine:
Wenn ich nur den Switch (sind bei mir ja 3 Switches im Stack) betrachte und kein Kabel zum Lancom gesteckt ist (ich habe nur die 3 Switches zum Stack über entsprechende Ports verbunden, was auch im Webinterface richtig angezeigt wird.

Nun stecke ich das Kabel von meinem PC in einen einzigen Port. Je nachdem zu welchem VLAN dieser Access Port zugeordnet ist, erhalte ich eine IP Adresse aus dem entsprechenden VLAN. Also zB 192.168.2.101 wenn ich an einem Port des VLAN2 hänge. ipconfig zeigt mir Standardgateway 192.168.2.1 an - wie erwartet.
ABER: ich kann dann nur das GW des VLANs anpingen (also 192.168.2.1). Aber nicht das GW des Nachbar-VLANs. Ein Ping auf 192.168.1.9 oder auf 192.168.50.1 sagt Zielnetz nicht erreichbar. Denselben Fehler gibt auch tracert schon beim ersten Ziel (klar) aus.

Das ist doch nicht normal und sollte gehen. Macht es nicht Sinn, dies erst mal zu lösen und dann alles andere zu konfigurieren?

ich suche nun seit Stunden, finde aber nichts. Soll ich die 3 Switches mal in Grundzustand resetten und von vorne beginnen?
Kann ich eigentlich alles nur mal mit einem Switch machen und dann die anderen beiden erst nachträglich in den Stack aufnehmen? Übernimmt er dann mit der Aufnahme in den Stack alles auf den zweiten/dritten Switch der verliere ich dann alle Einstellungen?

Ich bin der Verweiflung nahe - kann man Euch eigentlich einkaufen, damit ihr als Profis das einmal einrichtet (ggf Remote).

ich würde gerne nochmal einen Schritt zurück gehen,

Ist immer der richtige Weg !

Wenn ich nur den Switch (sind bei mir ja 3 Switches im Stack) betrachte

Richtig !
Dieser Stack verhält sich wie virtuelle ein einziger Switch. Quasi wie ein modularer Switch mit Einschüben was dann bei dir die Stack Member sind.

Je nachdem zu welchem VLAN dieser Access Port zugeordnet ist, erhalte ich eine IP Adresse aus dem entsprechenden VLAN. Also zB 192.168.2.101

Richtig ! Aber einzig nur wenn der Switch auch DHCP Server ist in dem VLAN. Wenn du einen zentralen DHCP Server extern hast dann bekommt er die IP von dem wenn DHCP Relay konfiguriert ist. Mit diesem aktiven Port kommt dann auch das IP Interface am Switch hoch, was du dann pingen kannst.
Andere IP Interfaces auf dem Switch kannst du nicht pingen, denn ohne aktiven Link sind die alle DOWN. Ist auch verständlich, denn warum sollten sie aktiv sein wenn in den VLAN Netzen gar nix iss

Soweit ist das richtig...

ABER: ich kann dann nur das GW des VLANs anpingen (also 192.168.2.1).

Richtig !

Aber nicht das GW des Nachbar-VLANs.

Ja ist klar...siehe oben. Kein aktives Endgerät im VLAN (aktiver Port) = dann ist das IP Gateway down. Ist normal bei allen L3 Switches.

Denselben Fehler gibt auch tracert schon beim ersten Ziel (klar) aus.

Klar ! Auch hier siehe oben...
Stecke irgendwas in einer der VLAN Ethernet Ports das einen aktiven Link erzeugt...schon ist das dazu korrespondierende IP Interface oben und aktiv und auch pingbar...
Ganz einfache und simple Logik !!

Das ist doch nicht normal und sollte gehen.

Das ist normal ! "Works as designed !"

ich suche nun seit Stunden, finde aber nichts.

Du brauchst nicht weiterzusuchen...Erklärung siehe oben !

Soll ich die 3 Switches mal in Grundzustand resetten und von vorne beginnen?

Nein ! Nur die IP Interface Logik verstehen das die von aktiven Ports abhängig ist, das reicht völlig.

kann man Euch eigentlich einkaufen, damit ihr als Profis das einmal einrichtet (ggf Remote).

Das wäre ja lamngweilig, dann siehst du nur zu und lernst nix dabei und bleibst dumm in Bezug auf Netzwerk KnowHow ! Ist doch auch nicht die Lösung, oder ?!

Hallo Aqui,
Danke fürs Mutmachen und Motivieren, es doch selbst hinbekommen, zu können.

ich glaube, langsam komme ich der Sache näher: dass die IP Interfaces nur aktiv / anpingbar sind, wenn auch ein Client darin aktiv ist, war der erste Durchbruch. Kaum habe ich ans zweite VLAN einen Rechner gehängt, konnte ich auch das Interface anpingen.

Switch ist denke ich damit eigentlich ganz gut konfiguriert. DHCP und DNS habe ich noch geändert. DNS steht auf dem Lancom. DHCP macht zur Zeit jedes VLAN des Lancoms (ich bin zur Zeit ja noch nicht mit meinem richtigen Netz verbunden und habe daher den Win-Server mit DNS und DHCP Server nicht im Zugriff)

Und nach langer Überlegung, warum der Port des TransferNetzes auf Access und nicht Trunk stehen soll, habe ich dann auch Deinen Hinweis, wie ich das Transfernetz gestalten soll, begriffen. Im Switch ist es ein VLAN. Der Switchport zum Lancom ist fürs VLAN 1000 untagged. Damit ist es nach dem Verlassen des Switches dann ein normales Netz ohne VLAN Info. Und so kann ich auf Lancom Seite das ganze ohne jegliches VLAN konfigurieren. Gesagt, getan. Noch die Route am Lancom zu allen 192.168 er Netzen mit /16 Netzmaske konfiguriert und nun sieht alles schon viel besser aus.

Ich erreiche nun vom Laptop an den VLANs den Lancom (also die 10.99.99.1). Und ich kann auch vom Laptop nslookups erfolgreich durchführen. Komme also wie auch immer geartet raus ins Internet.

Was allerdings noch nicht funktioniert ist, dass ich auf dem Laptop, von dem aus ich ein nslookup www.heise.de erfolgreich absetzen kann, auch www.heise.de im Browser (Chrome oder IE - das ist egal) angezeigt bekomme. Chrome meldet "ERR_CONNECTION_REFUSED" und der IE meldet "Vorübergehender DNS Fehler; Fehlercode: INET_E_RESOURCE_NOT_FOUND.
Ebensowenig kann sich Outlook mit dem Mailserver im Internet (O365) verbinden.
Also irgendwas ist da noch im Argen.
Mein neuer Freund tracert hilft mir da auch nicht weiter.

Hast Du eine Idee, was mir da in die Suppe spucken könnte? Irgendwas am Lancom - das Konfig-Interface ist ja ziemlich unverständlich.

Ich hoffe, dass ich das Problem dank Eurer Unterstützung auch noch gelöst bekomme. Und dann wage ich mich an die ACL fürs Gastnetz....
Vielen Dank
Tom

Guten Morgen Tom,

hast du auf dem Lancom irgendwelche Firewall-Regeln eingerichtet? Verwendest du für die Konfiguration des Lancom das "LANconfig"-Tool oder das Web-Frontend?

Gruß Arno

Hallo Arno,
ich nutze Lanconfig und (manchmal für Systemstatus) auch Web.
Ich selbst habe keine FW Regel angelegt. Aber der Lancom bringt ja einige Einstellungen schon mit. Und ich weiß nicht, wo ich die alle finde und ob mir eine Einstellung da in die Quere kommt.

Gibt’s denn Screenshots der wichtigsten Einstellungen.

PS: wenn ich meinen Laptop direkt in eine Port am Lancom einstecke, dann funktioniert das Web-Browing. Aber da hänge ich ja dann auch anders / direkter im Netz. Oder liege ich mit der Aussage falsch und Firewall Regeln würden genauso zutreffen?

Gruß Tom

Hallo Tom,

das FW-Konfigmenü findest du in Lanconfig hier:

Du kannst hier auch TESTWEISE die Firewall deaktivieren, um diese als Problemverursacher auszuschließen.

PS: wenn ich meinen Laptop direkt in eine Port am Lancom einstecke, dann funktioniert das Web-Browing. Aber da hänge ich ja dann auch anders / direkter im Netz. Oder liege ich mit der Aussage falsch und Firewall Regeln würden genauso zutreffen?

Kann man pauschal nicht beantworten. Du kannst mal einen Screenshot der IPv4-Regeln machen und hier posten. Die findest du im Untermenü "IPv4-Regeln" unter "Regeln" -> siehe Screenshot oben.

Das hier wäre noch als Basiswissen zum Thema Lancom Firewall und Deny-all-Strategie für dich interessant. Ich weiß....seufz....noch mehr Input

Lancom FW mit Deny-all-Strategie

Gruß Arno

Kaum habe ich ans zweite VLAN einen Rechner gehängt, konnte ich auch das Interface anpingen.

Du siehst: Works as designed !

DHCP macht zur Zeit jedes VLAN des Lancoms

Das ist jetzt irgendwie unverständlich und auch Besorgnis erregend....
Auf dem Lancom sollte eigentlich KEIN VLAN definiert sein wenn du dich sauber an das L3 Tutorial gehalten hast !!!
Oder hast du das jetzt nur temporär eingerichtet für dein Test Setup ??
Auch das wäre kontraproduktiv, denn du hast keinen Tagged Trunk auf den Lancom ! Sinnvoller wäre es dann gewesen die DHCPs testweise auf dem Switchstack einzurichten und dann späte im Live Netz mit DNS und DHCP wieder vom Switch zu entfernen.
Irgendwas ist das also schief gelaufen bei dir mit der Lancom Anbindung...jedenfalls hört es sich nach deiner o.a. Beschreibung so an ?!

Im Switch ist es ein VLAN. Der Switchport zum Lancom ist fürs VLAN 1000 untagged.

So wäre es richtig !

Damit ist es nach dem Verlassen des Switches dann ein normales Netz ohne VLAN Info.

Genau richtig ! Wie jeder untagegd Port. Das er im VLAN 1000 hängt "weiss" nur der Switch da du ihm das ja statisch gesagt hast !

und nun sieht alles schon viel besser aus.

👏

Komme also wie auch immer geartet raus ins Internet.

So sollte es auch sein ! 👍

Also irgendwas ist da noch im Argen.

Kann aus reiner IP Routing Sicht, sprich aus Sicht der IP Infrastruktur nicht mehr sein ! Wenn nslookup die richtige IP zurückliefert ist es de facto nicht die Infrastruktur. Soviel oist klar. Das kannst du ja auch klar an der Tatsache sehen das du aus allen VLANs eine Hostadresse im Internet pingen kannst. ICMP Pakete, die ja auch auf IP basieren, kommen also sauber ans Ziel. Lediglich deine Dienste die auf TCP basieren nicht und das auch nur aus den gerouteten VLAN Netzen. Ein sehr starkes Indiz das da noch etwas fehlkonfiguriert ist an der Lancom Firewall !!!
Dann hast du nämlich ein Problem mit der Applikation selbe. Oder einen Proxy definiert im Browser der da gar nicht ist oder sowas... Vermutlich aber falsche oder fehlende Regeln in der FW.
Am Switch und der Konfig liegt es de facto nicht sofern du noch keine Access Listen aktiv hast !

Irgendwas am Lancom - das Konfig-Interface ist ja ziemlich unverständlich.

Davon kannst du sicher ausgehen. Das Konfig Interface ist in der Tat gruselig.

wenn ich meinen Laptop direkt in eine Port am Lancom einstecke, dann funktioniert das Web-Browing

Das ist ein Indiz dafür das die Lancom Firewall vermutlich das NAT für die TCP Dienste TCP 80, 443, Email usw. verbietet.
Wie Kollege @NixVerstehen schon richtig sagt ist das jetzt rein ein Konfig Problem der Lancom Firewall. Vermutlich müssen dort die 192.168er IP Netze noch irgendwie freigeschaltet werden.
Das müsste aber ein Lancom Spezl beantworten....

Zitat von @aqui:

DHCP macht zur Zeit jedes VLAN des Lancoms

Das ist jetzt irgendwie unverständlich und auch Besorgnis erregend....
Auf dem Lancom sollte eigentlich KEIN VLAN definiert sein wenn du dich sauber an das L3 Tutorial gehalten hast !!!

Sorry, hatte mich verschrieben. DHCP macht zur Zeit noch der Switch für jedes VLAN. Natürlich hast Du Recht, dass auf dem Lancom kein VLAN existiert / angelegt ist.

Ansonsten ist unglaubliches passiert. Da die Hardware bei mir im Büro steht und lärmt, habe ich sie über Nacht komplett abgeschaltet. War heute unterwegs und als ich sie gerade wieder eingeschaltet habe, funktioniert alles.
Ich vermute, dass sich durch die ganzen Konfigurationsversuche der Lancom verschluckt hatte. Ich hoffe es bleibt so stabil und ich habe mich nicht zu früh gefreut.

Trotzdem werde ich später noch ein paar Screenshots vom Lancom Routing und sonstigen Einstellungen auf die Frage von Arno posten. Da sind mir schon noch ein paar Dinge unklar und es wäre super nett, wenn ein Lancom Profi mal drüber schauen könnte.

@aqui: morgen starte ich mal mit den ACLs. Könnte sein, dass ich Dich da nochmals um Unterstützung bitten muss.

Tausend Dank bis hierher. Ohne Euch wäre ich aufgeschmissen gewesen. Und das Beste: ich glaube, dass ich vieles begriffen habe.
Tom

War heute unterwegs und als ich sie gerade wieder eingeschaltet habe, funktioniert alles.

Bitte jetzt nicht esotherisch werden. Auch wenn es viele hier im Forum immer behaupten: sowas gibt es in der IT nicht !

Aber wie so immer... Reboot tut manchmal gut !! Gut das es nun werkelt we es soll.

morgen starte ich mal mit den ACLs. Könnte sein, dass ich Dich da nochmals um Unterstützung bitten muss.

Klar, immer her damit. Das Grundgerüst wie es geht siehst du ja oben !

ich glaube, dass ich vieles begriffen habe.

Das ist die Hautptsache ! 👍

Zitat von @NixVerstehen:
Kann man pauschal nicht beantworten. Du kannst mal einen Screenshot der IPv4-Regeln machen und hier posten. Die findest du im Untermenü "IPv4-Regeln" unter "Regeln" -> siehe Screenshot oben.

Hallo Arno,
inzwischen läuft es ja (nach reboot). Trotzdem stehe ich mit dem Lancom Router auf Kriegsfuß. Daher poste ich hier mal die wichtigsten Einstellungen. Wäre super, wenn Du mal drüber schauen könntest.

Firewall-Einstellungen (nichts verändert): unter Allgemein habe ich die v4 Firewall aktiviert; die v6 deaktiviert. Unter IPv6->Allgemein habe ich IPv6 deaktiviert. Der Lancom hängt hinter 2 Fritzboxen, die VDSL bzw Kabel liefern. Auf jeder FB habe ich v6 ebenfalls deaktiviert.

Gegenstellen: heute habe ich in Testumgebung nur eine Gegenstelle. Der Lancom hängt hinter meiner Fritzbox. Vermutlich war die Default Zeile schon drin. Und ich habe über Assistenten die zweite Zeile erstellt und vermutlich INTERNET genannt. Wäre besser, ich hätte sie VDSL genannt. Kann ich die ohne Nebenwirkungen umbenennen?

VLAN: Das VLAN Modul ist NICHT aktiviert. Ich habe aber trotzdem (hatte ich irgendwo hier im Forum gesehen) in die VLAN Tabelle VLAN1 nochmals eingetragen:

IPv4 Allgemein:

IP-Router - Routing: den ersten Eintrag habe ich modifiziert. Das ist mein Rück-Routing zum Switch für alle meine VLAN Netze. Die anderen 4 Zeilen waren auch schon drin; 2 davon sind deaktivert. Spricht was dagegen, die deaktiverten Zeilen zu löschen. Macht es ja nicht gerade übersichtlicher. Die letzte Zeile ist wohl mein Routing ins Internet. Wozu benötige ich denn die vorletzte (aktivierten) Zeile.

Und wie kann ich denn dieser Verbindung eine feste IP zuordnen. Also für meine VDSL Verbindung habe ich der Fritzbox das Netzwerk 10.99.98.0 gegeben. Die Fritzbox hat die 10.99.98.1 und ich würde dem Lancom gerne die 10.99.98.254 für die VDSL Verbindung geben.
Bei Unitymedia wäre es genau dasselbe.

Load-Balancing:
Sobald Unitymedia die Leitung auf 400/40 upgraded, würde ich Loadbalancing aktivieren. Den Link, wie das funktioniert, hast du ja schon oben mal reinkopiert. Ist soweit verständlich. Ich lege unter Loadbalancing eine virtuelle Verbindung an (z.B. INET1+2) und trage dort beide Internet-Verbindungen ein - heute habe ich nur eine, da in Testumgebung. Und diese muss ich dann in der Routingtabelle für die Route nach 255.255.255.255 statt der bisherigen Verbindung INTERNET eintragen?

DynDNS:
Bei VDSL habe ich leider keine feste IP. Trotzdem möchte ich z.B per SSH von aussen einen Linux Server erreichen können. Soll ich den Dyndns Update den Lancom machen lassen (würde ich über Assi einrichten) oder besser die zugehörige Fritzbox?

Port Forwarding:
Ich möchte z.B. den Port 443 an meinen Linux Server weiterleiten. Dazu leite ich in der Fritzbox 443 an die IP (des Fritzbox-Netzes) des Lancoms weiter (10.99.98.254) - und hierfür muss ich diese IP fest vergeben und kann dem Lancom Interface für VDSL keine DHCP Adresse zuordnen lassen.
Kommt das Routing hier damit klar, dass ich an IP Adressen weiterleite, die in VLANs auf dem Switch sind? Also z.B. an 192.168.1.111

Danke
Tom

Jetzt habe ich noch eine Frage: ich habe ein Programm, das per Tunnel über Port 11955 auf einen Server im Internet zugreift. Dies funktioniert von einem Client, der an den Switch angeschlossen ist, nicht. Hänge ich den Client direkt an meine Fritzbox, dann funktioniert es.
Erstaunlicherweise kann ich aber vom Client am Switch per SSH über Port 8022 auf einen SSH-Server im Internet zugreifen.
Das sind ja beides ausgehende Verbindungen. Wer bremst mich hier denn aus? Der Switch oder der Lancom Router. Und warum funktioniert Port 8022 aber Port 11955 nicht raus?
Ich habe noch keine ACLs angefasst....

Der Lancom hängt hinter 2 Fritzboxen, die VDSL bzw Kabel liefern

Macht der Link Load Balancing mit Failover dann ??

Spricht was dagegen, die deaktiverten Zeilen zu löschen

Solltest du machen !

Die Fritzbox hat die 10.99.98.1 und ich würde dem Lancom gerne die 10.99.98.254 für die VDSL Verbindung geben.

Statische IP Adressierung an diesem WAN Port setzen. Aber das sollte ein Lancom Spezl besser beurteilen können.

und hierfür muss ich diese IP fest vergeben und kann dem Lancom Interface für VDSL keine DHCP Adresse zuordnen lassen.

Doch das ginge mit einem ganz einfachen Kniff !:
Sieh dir im Lancom Port Setup dieses Ports an welche Mac Adresse (HW Adresse) der Lancom dort hat.
Dann trägst du im FritzBox DHCP Server diese Mac Adresse ein und weisst der fest die .254 zu !
Wie das geht hat AVM hier beschrieben:
https://avm.de/service/fritzbox/fritzbox-7590/wissensdatenbank/publicati ...
Dann bekommt der Lancom Port immer fest die .254 auf Basis seiner Mac Adresse. So kannst du DHCP belassen.
Technisch besser ist es aber diese IP statisch zu setzen.

Dies funktioniert von einem Client, der an den Switch angeschlossen ist, nicht.

Das kann eigentlich nicht sein ! Logisch, denn Outbound Sessions werden ja nicht verändert. Der Traffic mit dem 11955 Zielport wird ja stinknormal auf den Lancom geroutet und der NATet den ja dann auf eine der FritzBoxen. Dort werden se wieder geNATet auf die finale öffentliche IP im Internet. Exakt so wie Brower Traffic, Email oder was auch immer was fehlerlos klappt.
Vermutlich spielen ggf. noch andere Protokollkomponenten da eine Rolle so das es kein reiner SSL Traffic mit Port 11955 ist wie z.B. PPTP mit GRE oder IPsec mit ESP.
Da kann das doppelte NAT mit deiner WAN Anbindung der FritzBoxen kontraproduktiv sein oder noch eine extra Konfig erfordern. Das kann man so nicht beurtelen weil deine Infos zu dieser Kommunikation zu wenig sind.
Hier solltest du auf diesem Client mal einen Wireshark laufen lassen und dr diese Port 11955 Session mal genau ansehen !
Einmal mit der FB direkt und einmal aus dem VLAN Netz. Da wird dann sofort klar woran es liegt und welche Komponenten da noch beteiligt sind.
Generell kann es ja niemals sein das eine Anwendung in einem gerouteten Netz nicht funktioniert. Wireshark ist hier also dein Freund !

Und warum funktioniert Port 8022 aber Port 11955 nicht raus?

Das "riecht" wieder mal sehr verdächtig nach Lancom Firewall !!! Der Switch ist es ganz sicher nicht !
Wie auch ?? Der "sieht" ja rein nur auf die IP Adressen für seine Wegefindung, also rein Layer 3. Von TCP und UDP Ports oder Anwendungen also Layer 4 und drüber weiss der rein gar nix. Den kannst du also ganz sicher ausschliessen solange keine ACLs aktiv sind !

Guten Morgen Tom,

Firewall-Einstellungen (nichts verändert): unter Allgemein habe ich die v4 Firewall aktiviert; die v6 deaktiviert. Unter IPv6->Allgemein habe ich IPv6 deaktiviert. Der Lancom hängt hinter 2 Fritzboxen, die VDSL bzw Kabel liefern. Auf jeder FB habe ich v6 ebenfalls deaktiviert.

In dieser Konfiguration hat es die Firewall gemütlich, denn sie hat nichts zu tun. Zeile 2 (der Contentfilter) ist deaktiv. Die Zeile kannst du rauswerfen, wenn der Lancom keine Inhaltsprüfungen (braucht Zusatzlizenz) machen soll. Zeile 1 blockt Netbios, das sollte drin bleiben.
In deiner Einstellung ist die Firewall erst einmal wirkungslos, da sie alles passieren lässt. Von der Denkweise her beachte folgendes:

Es gibt 4 Firewall-Objekte, von denen du 3 benötigst:

Aktions-Objekte -> Sagt der Firewall, was zu tun ist, wenn eine Bedingung zutrifft, z.B. Akzeptieren, Verwerfen, Zurückweisen
Stations-Objekte -> Einzelne Subnetze, Gesamtes lokales Netz, einzelne Geräte, bestimmte Adressbereiche
Dienst-Objekte -> Vordefinierte Templates, z.B. http, https, ftp, smtp,.....

Es ist eine Vielzahl von Objekten vordefiniert und jede Firewall-Regel kann sozusagen nach dem Baukastenprinzip zusammengebaut werden.
Die Regeln werden von der Firewall automatisch in die richtige Reihenfolge gebracht, also erstmal alles mit Prio 0 anlegen.
Es wird diejenige Regel verarbeitet, auf die als erstes alle Bedingungen zutreffen.

Die Betrachtung erfolgt immer in der "Flußrichtung" eines Datenpaketes. Eine Erlaubnis z.B. für http (80) aus dem lokalen Netz in Richtung Internet bewirkt, das die Antwort aus dem Internet die Firewall in Richtung lokales Netz passieren darf. Aber eben nur diese Antwort und keine nicht vorher angeforderten Datenpakete. Die Firewall weiß also, was raus ging und läßt eingehend nur das passieren, was sie in ihrer Sendetabelle vermerkt hat. Beispiel:

Prio: 0, Name: Deny-all, Quelle: beliebig, Quelldienst: beliebig, Ziel: beliebig, Zieldienst: beliebig, Aktion: zurückweisen

Diese Regel würde jeglichen Verkehr über die FW, egal über welches Protokoll, blockieren. Also auch das Internet ist blockiert. Dazu gehört auch ein Ping und DNS!

Prio: 0, Name: Allow http, Quelle: beliebig, Quelldienst: beliebig, Ziel: beliebig, Zieldienst: http,dns Aktion: akzeptieren

Diese Regel bewirkt, das ausgehende Verbindungen über http und die externe Namensauflösung per dns über die Firewall, also auch Internet, erlaubt wird. Damit werden auch die eingehenden Rückantworten für diese Verbindung erlaubt. In Verbindung mit Regel 1 wird alles andere blockiert.

Also eigentlich ganz einfach

Die erste Zeile kann ein Default-Eintrag sein. Ich hab hier leider keinen Vergleich. Aber mach doch über Lanconfig eine Sicherung der Konfig und werfe die Zeile anschließend raus. Dann siehst du was passiert. Wenn du mit dem Assistenten eine neue Internet-Verbindung einrichtest, wird diese in der Tat "INTERNET" genannt. Umbenennen hab ich noch nie gemacht. Aber in einigen Untermenüs wird wiederum dieser Name "INTERNET" für Einstellungen herangezogen, also besser lassen und die zweite Verbindung "INTERNET2" nennen.

VLAN: Das VLAN Modul ist NICHT aktiviert. Ich habe aber trotzdem (hatte ich irgendwo hier im Forum gesehen) in die VLAN Tabelle VLAN1 nochmals eingetragen:

Die Zeile 2 ist meiner Meinung nach unnötig, da Zeile 1 bereits das Default VLAN1 auf alle logischen Interfaces bindet. Zeile 2 wäre also doppelt gemoppelt.

IPv4 Allgemein:

Passt.

Rückroute passt. Du schickst damit alles eingehende mit Ziel innerhalb 192.168.0.0/16 an deinen Switch. Die Zeilen 2 - 4 brauchst du mutmaßlich, damit Adressen aus privaten Adressbereichen und Multicasts nicht ins Internet geroutet werden. Du kannst also Zeile 2 und 3 aktivieren. Sind bei mir auch aktiv. @aqui: Richtig?

Da bin ich gerade selbst überfragt.

Load-Balancing:
Sobald Unitymedia die Leitung auf 400/40 upgraded, würde ich Loadbalancing aktivieren. Den Link, wie das funktioniert, hast du ja schon oben mal reinkopiert. Ist soweit verständlich. Ich lege unter Loadbalancing eine virtuelle Verbindung an (z.B. INET1+2) und trage dort beide Internet-Verbindungen ein - heute habe ich nur eine, da in Testumgebung. Und diese muss ich dann in der Routingtabelle für die Route nach 255.255.255.255 statt der bisherigen Verbindung INTERNET eintragen?

Lancom Backup-WAN-Verbindung
Lancom Load-Balancing

DynDNS:
Bei VDSL habe ich leider keine feste IP. Trotzdem möchte ich z.B per SSH von aussen einen Linux Server erreichen können. Soll ich den Dyndns Update den Lancom machen lassen (würde ich über Assi einrichten) oder besser die zugehörige Fritzbox?

Hab mich hier noch nie mit DynDNS befasst. Zuhause verwende ich die MyFritz-Funktion auf der Fritte. Allerdings würde ich SSH nicht von extern erreichbar machen, sondern VPN bevorzugen.

Port Forwarding:
Ich möchte z.B. den Port 443 an meinen Linux Server weiterleiten. Dazu leite ich in der Fritzbox 443 an die IP (des Fritzbox-Netzes) des Lancoms weiter (10.99.98.254) - und hierfür muss ich diese IP fest vergeben und kann dem Lancom Interface für VDSL keine DHCP Adresse zuordnen lassen.

Lancom-seitig mußt du die Firewall eingehend für 443 öffnen und den Port dann auf deinen Linux-Server weiterleiten. Aber mit der fixen IP bin ich wie gesagt überfragt.

Ggf. kannst du dem User @tikayevent eine kurze PN mit dem Link zu diesem Beitrag schreiben und ihn bitten, hier mitzulesen. Er ist ausgesprochen fit im Umgang mit den Lancom-Geräten.

Gruß Arno

Lach...und wie immer gilt: Ich bin versierter Laie und kein Admin. Falls etwas falsch ist, möge man mich bitte berichtigen.

Ich bin versierter Laie und kein Admin.

Dafür klingt das Obige aber schon sehr professionell !

Das du wahrlich kein Laie mehr bist haben wir oben ja schon geklärt !

Vielleicht gibts ja noch Feedback vom Kollegen @tikayevent on top ?!

Zitat von @NixVerstehen:
In dieser Konfiguration hat es die Firewall gemütlich, denn sie hat nichts zu tun. Zeile 2 (der Contentfilter) ist deaktiv. Die Zeile kannst du rauswerfen, wenn der Lancom keine Inhaltsprüfungen (braucht Zusatzlizenz) machen soll. Zeile 1 blockt Netbios, das sollte drin bleiben.
In deiner Einstellung ist die Firewall erst einmal wirkungslos, da sie alles passieren lässt.

Ups.... dachte im ersten Moment, dass ich gerade alle Rechner offen im Internet hängen habe. Aber mein Lancom hängt ja hinter den Fritzboxen. Und die lassen ja nichts durch. Bzw nur die 3 Port-Weiterleitungen. Damit kann ich die FW ja so belassen.

Habe eine neue Verbindung über Assistenten eingerichtet und habe diese INET_VDSL benannt. Zweite Verbindung für Kabel wird entsprechend bezeichnet INET_KABEL. Assisten hat auch gleich die Route auf die neue Verbindung geändert. Alle anderen Zeilen habe ich rausgeworfen.

Die Zeile 2 ist meiner Meinung nach unnötig, da Zeile 1 bereits das Default VLAN1 auf alle logischen Interfaces bindet. Zeile 2 wäre also doppelt gemoppelt.

Habe ich rausgeworfen. Läuft weiterhin alles.

Da bin ich gerade selbst überfragt.

Ich habs gefunden, nachdem ich es über den Assistenten eingetragen habe.
Ist unter Kommunikation -> Protokolle -> IP-Parameter zu finden. Dort ist eine Zeile je Verbindung (bei mir INET_VDSL) und in der Zeile ist die IP-Adresse sowie GW und Nameserver einzutragen. Falls DHCP steht dort vermutlich überall 0.0.0.0 drin.

Lancom Backup-WAN-Verbindung
Lancom Load-Balancing

Hab mich hier noch nie mit DynDNS befasst. Zuhause verwende ich die MyFritz-Funktion auf der Fritte. Allerdings würde ich SSH nicht von extern erreichbar machen, sondern VPN bevorzugen.

Werde Dyndns auch über die Fritzbox machen. Diese bekommt ja vermutlich früher/sofort mit, wenn sich die public IP geändert hat.
SSH ist mein Notzugang. Und ich lasse dort nur SSH über Key zu.

FixeIP ist gelöst siehe oben. Und Port Weiterleitungen haben ich eingetragen unter IP-Router -> Maskierung -> Port Forwarding Tabelle.

Vielen Dank!

Ups.... dachte im ersten Moment, dass ich gerade alle Rechner offen im Internet hängen habe.

War auch falsch gedacht denn wie jeder sehen kann ist das eine "Outbound" Regel. Sprich also alles was vom lokalen LAN ins Internet geht.
Aus gutem Grund ist da NetBios geblockt !

Und die lassen ja nichts durch.

Außer TR-069 Schnüffeleien vom Provider !

Werde Dyndns auch über die Fritzbox machen. Diese bekommt ja vermutlich früher/sofort mit, wenn sich die public IP geändert hat.

Ist auch der richtige Weg, denn diese Router halten ja direkt die jeweils öffentliche IP Adresse die für DynDNS relevant ist.

Hurra! Die ACLs für das Gastnetzwerk haben auf Anhieb funktioniert. Nun kann ich die Komponenten in den nächsten Tagen in Produktion nehmen.
Ihr seid meine Helden!!! Vor einer Woche war ich noch kompletter VLAN Laie. Nun verstehe ich täglich etwas mehr.

Dazu auch noch eine Frage: ich habe ja die 3 Cisco’s als Stack verbunden. Und zwar in meiner Testumgebung per Kupfer. Im richtigen Betrieb soll das per Glasfaser erfolgen. Bei der Konfiguration des Stacks gibt man ja u.a. das Interface an, über den der Switch an den Stack angeschlossen wird. Dieses ändert sich ja jetzt bei mir.
Ich erinnere mich, dass nach der Initialen Aufnahme jeden Switches in den Stack dieser in einen Art Grundzustand versetzt haben und ich sogar das Passwort neu setzen musste.
Wird mich dies beim Umstieg von Kupferport - auf Glasport auch treffen und ich muss quasi von vorne beginnen, oder behält der Stack die Konfig und ich kann quasi nur die Interfaces ändern? Also Kupfer und Glas parallel anschließen und dann das Verbindungsinterface ändern?

Und zu ACL habe ich auch noch eine Frage:
Mein Produktions VLAN (70) wollte ich zuerst nur komplett abschotten (kein Inter-VLAN Routing, kein Internet) mit ACL:
access-list 100 DENY ip 192.168.70.0 0.0.0.255 any any

Nun habe im Produktionsnetz ein kleines NAS, auf das die Maschinen-PCs sporadisch ihre Konfigurationen sichern. Dieses würde ich wiederum gerne in die Cloud sichern.
Wie erlaube ich dem NAS am cleversten Internet Zugang?
Meine Idee: NAS bekommt 192.168.7.2 und die Maschinen PCs zum Beispiel 192.168.70.200 und höher. Und dann diese Regeln
access-list 100 DENY ip 192.168.70.0 0.0.0.255 192.168.0.0 0.0.255.255
access-list 100 PERMIT ip 192.168.70.0 0.0.0.15 any any
Die erste deny Regel verbietet dass die Produktionsnetz Rechner in die anderen 192.168-er VLAN kommen
Und die Permit Regel erlaubt den unteren 70-er Adressen Internet Zugriff.

Ich frage mich allerdings, wer den oberen IP Adressen im 70er Netz den Zugriff aufs Internet verbietet? Ist dafür die Default Action „Deny All“ (so heißt diese in der GUI) da?

Hurra! Die ACLs für das Gastnetzwerk haben auf Anhieb funktioniert.

👏 Glückwunsch ! Und wars nun schwer ?!

Wird mich dies beim Umstieg von Kupferport - auf Glasport auch treffen

Vermutlich nein, denn du musst nur die Stackports neu definieren. Der Switch macht ein reboot und resett nur wenn er initial aus dem Stand alone Modus in den Stack Member Mode versetzt wird. Ist ja auch klar, denn er muss ja von einem evtl. vorhandenen Stack Master die Konfig übernehmen und dann muss er dafür logischerweise nackig sein.
In einem bestehenden Stack reicht es aber die Stackports neu zu definieren und umzustecken.

Also Kupfer und Glas parallel anschließen und dann das Verbindungsinterface ändern?

Genau so sollte es klappen.

Und dann diese Regeln

Sind richtig so !

Ich frage mich allerdings, wer den oberen IP Adressen im 70er Netz den Zugriff aufs Internet verbietet?

Auch wenn es da nicht steht aber am Ende eines Regelwerks steht als genereller Default immer access-list xyz DENY any any
Da es Default ist steht es explizit nicht in der Konfig es ist aber immer existent.
Damit kommen die "oberen" 70er IPs nicht raus.

Zitat von @aqui:

Hurra! Die ACLs für das Gastnetzwerk haben auf Anhieb funktioniert.

👏 Glückwunsch ! Und wars nun schwer ?!

Es war zeitintensiv. Aber extrem spannend und lehrreich!

Nun bin ich gerade dabei, alle Ports entsprechend zu konfigurieren und habe dazu noch Fragen:
Ich habe im Prinzip 4 Arten von "angeschlossenen Geräten":

3 Server unter vmware auf denen diverse Windows- und Linux-Server laufen. Alle im Haupt-LAN (bei mir noch historisch bedingt das default VLAN). Werden die VMWare Server über einen Trunk Port angeschlossen? Auf jedem VMWare Server liegt ja ein virtueller Switch. Daher dachte ich, dass Trunk-Port richtig wäre. Wenngleich ich den vmware-Switch noch ohne VLANs betreibe. D.h. Stand heute hängen alle VMs auf dem einen virtuellen Switch mit default VLAN. Und auch alle meine Gäste hängen im Default VLAN.
Alle Clients/Desktops/Laptops in VLAN10 - die werde ich alle dem VLAN10 untagged zuweisen.
Die WLAN Infrastruktur bestehend aus 1 x Controller und 4 x APs. Im VLAN Tutorial habe ich schon gelesen, dass die APs alle notwendigen VLANs als tagged konfiguriert werden sollen. In meinem Fall also VLAN10 (Clients) und VLAN99 (Gastnetz). Nur beim WLAN-Controller bin ich nicht sicher. Muss dieser auch für beide VLANs getagged werden. Oder hängt er nur im default VLAN?
Die (neuen, noch nicht gelieferten) IP-Telefone: für die habe ich ja das VLAN50 vorgesehen. Also hätte ich diese Ports mit VLAN50 untagged konfiguriert. Nun empfiehlt unser IP-Telefonanlagen-Anbieter (IP-Telefonie bei uns; Die IP TK Anlage in der Cloud), den Desktop/Laptop des Mitarbeiters an das Telefon anzuschließen um Ports zu sparen. Also hängt das Telefon direkt am PoE Port und hat aber einen kleinen Switch eingebaut, so dass man den Laptop dann direkt am Telefon einstecken kann. Nun frage ich mich, wie das gehen kann. Ich möchte ja gerne, dass das Telefon im VLAN50 und der Laptop im VLAN10 hängt. Konfiguriere ich dann diese Ports mit VLAN10 UND VLAN50 tagged? Und dann gibts da ja noch im Cisco Switch die Einstellungsmöglichkeit eines Telefonie-VLANs (ich glaube, es steht auf 4). Was hat es denn damit auf sich. Soweit ich verstanden habe, soll man Telefone, die man direkt anschließt (was ich ja mache) nicht auf dieses VLAN legen. Ist denn dieses Port-Sharing / nutzung des internen Telefon-Switches emfehlenswert. ich finde es schon charmant. Hätte aber für 25 der 30 Telefone die Möglichkeit, Telefon und Laptop jeweils an einen dedizierten Port zu hängen. Dann wäre auch die Frage nach der Port-Konfig geklärt. Aber bei 5 Arbeitsplätzen wäre ein Port-Sharing sehr hilfreich

Vielen Dank
Tom

Werden die VMWare Server über einen Trunk Port angeschlossen?

Diese Frage kann man dir leider nicht beantworten, da du keinerlei Informationen lieferst zur Konfig des internen vSwitches. Diese Konfig ist aber essentiell wie du auch den physischen Switch anbindest.
Wenn du die VMs taggen solltest im vSwitch dann ja.
Wenn er nur als dumme, einfache Bridge arbeitet dann nein. Es hängt einzig davon ab ob du die VMs in unterschiedlichen VLANs betreibst und ob du diese dann per Tagging weiterreichst.
Also hier können wir wegen der fehlenden Infos auch nur im freien Fall raten wie du dir ja auch selber denken kannst.

Alle Clients/Desktops/Laptops in VLAN10 - die werde ich alle dem VLAN10 untagged zuweisen.

Ist richtig !

Die WLAN Infrastruktur

Auch hier ist eine zielführende Hilfe schwer, da man deine WLAN HW nicht genau kennt.
Es gibt Controller die sämtlichen Traffic der APs auf sich tunneln und dann zentral an den Switch reichen. Da bleiben APs und Controller nur im untagged Default VLAN (Management) und der Controller koppelt tagged aus.
Das ist aber heute eher die Ausnahme denn sowas skaliert nicht und bei Billig APs und Controller gibt es sowas eher wenig.
Dort sind APs und Kontroller immer in einem untagged Management Netz verbunden. Das solltest du auch dann so als getrenntes Manmagement VLAN betreiben oder dein generelle Management VLAN dafür nehmen. In dieses VLAN bindet man natürlich keine SSID. Logisch, denn man will natürlich nicht in einem aktiven WLAN seinen AP Management Traffic haben.
Fazit: Es reicht APs und Controller in einem untagged VLAN zu betreigen und die Privat und Gast WLANs dann als separate VLANs auf die jeweiligen SSIDs zu mappen.
Daraus folgert dann natürlich das die APs mit 3 Netzen und einem Trunk Port angeschlossen werden müssen. Das Native VLAN (untagged) des Trunks setzt man auf das Management VLAN und die Tagged VLANs dann auf die entsprechenden SSIDs.
Sieh dazu auch das Praxisbeispiel im VLAN Tutorial. Das entspricht exakt diesem Szenario.

den Desktop/Laptop des Mitarbeiters an das Telefon anzuschließen um Ports zu sparen.

Das kann man machen und ist oft gängige Praxis.
Das Voice VLAN ist dann tagged. Ist auch klar, denn viele Anlagen Hersteller arbeiten dann mit 802.1p Priorisierung. .1p ist immer Teil des .1q VLAN Tags deshalb ist ein Tagging des Voice VLANs dann Pflicht und auch um es vom PV VLAN, der ja nicht im Voice VLAN liegt, zu trennen.
Also auch hier dann Trunk ! Tagged VLAN ist das Voice VLAN und das Native VLAN (untagged) setzt man dann wieder auf das PC Client VLAN.
Sinnvoll ist es hier noch das Voice VLAN per LLDP-med durch die Telefone automatisch setzen zu lassen. Dann muss man das nicht immer statisch auf den Telefon Ports konfigurieren beim Umstecken von Telefonen wenn Mitarbeiter mal umziehen.
Siehe dazu auch diese Threads:
Kaufberatung - Switches mit VoIP-Priorisierung
Redundante Core Switches

Nun frage ich mich, wie das gehen kann.

Nun, du hast doch oben gelernt wie VLAN Switches jetzt funktionieren. Im Telefon ist ein kleiner VLAN Switch integriert. Ob der nun 2 oder 20 Ports hat spielt keine Rolle er funktioniert vollkommen identisch zum großen Switch.
Tagged Traffic ist Voice, also VLAN 50, das leitet der Switch ans Telefon.
Untagged Traffic ist das Native VLAN das der Telefon Switch an den 2ten Port weiterreicht.
Exakt so wie ein "großer" Switch.
Der LAN Switch ist dann ein Trunk als Tagged Memeber im Voice VLAN und das Native VLAN setzt du auch VLAN 10, fertig ist der Lack !
Wo ist denn da dein Problem ??
Wie oben schon gesagt solltest du per LLDP-med das Voice (Telefonie) Netz automatisch auf 50 setzen lassen. Die Telefone bzw. die Anlage sollte das supporten. Frag den Telefonie Installateur dafür. der MUSS dir diese Infos alle liefern.
Zu Cloud Telefonie und Sicherheit oder Vertraulichkeit sagen wir jetzt mal besser nix. Hat ja auch mit dem Thema nix zu tun aber beii 5 Plätzen wärst du mit einer eigenen kleinen Auerswald 4000 VoIP Anlage sicher besser gefahren. So bekommt jetzt die ganze Welt mit mit wem und was du telefonierst...aber egal. Zurück zum Thema...

Zitat von @aqui:

Hurra! Die ACLs für das Gastnetzwerk haben auf Anhieb funktioniert.

👏 Glückwunsch ! Und wars nun schwer ?!

Hatte mich zu früh gefreut. Nach Reboot des Laptops im Gast-VLAN gings nicht mehr. Ursache aber schnell gefunden: Laptop hat keine DHCP Adresse bekommen. Habe mich sofort an Deinen Post weiter oben erinnert und noch die Regel mit UPD Port67 freigeschaltet. Jetzt funktioniert es. Hier zur Doku meine 3 Regeln (und ich will das Gast-LAN nicht nur fürs Surfen einschränken)

Hallo @aqui,

Zitat von @aqui:

Werden die VMWare Server über einen Trunk Port angeschlossen?

sorry für die fehlende Info. Ja der vSwitch ist heute nur eine Bridge. Kein VLAN. Ich habe lediglich die VMware hosts mit je 2 Kabeln an jeweils einen meiner physischen (alten) switches angeschlossen, die wiederum per Uplink-Port 1GB miteinander verbunden sind. Ich dachte, ich bekomme so etwas redundanz und vor allem ggf mit 2 x 1GBit eine doppelt so schnelle Anbindung. Bin aber gar nicht sicher, ob das wirklich so funktioniert.
Habe aber verstanden. Solange keine VLANs im vSwitch, bleibt der Port auf access und untagged im entsprechenden VLAN.

Die WLAN Infrastruktur

Auch hier ist eine zielführende Hilfe schwer, da man deine WLAN HW nicht genau kennt.
Fazit: Es reicht APs und Controller in einem untagged VLAN zu betreigen und die Privat und Gast WLANs dann als separate VLANs auf die jeweiligen SSIDs zu mappen.
Daraus folgert dann natürlich das die APs mit 3 Netzen und einem Trunk Port angeschlossen werden müssen. Das Native VLAN (untagged) des Trunks setzt man auf das Management VLAN und die Tagged VLANs dann auf die entsprechenden SSIDs.

Auch hier sorry. WLAN Hardware ist von Zyxel. Controller: NXC2500 und 4 x Accesspoints NWA5123-NI
Ich habe die nicht selbst eingerichtet, sehe aber, dass es dort die von Dir angesprochene Mapping-Tabelle von VLAN zu SSID gibt.
Also konfiguriere ich die Anschlüsse als Trunk Ports und lege das Mgmt Netz auf untagged und die beiden VLANs (2 für Client und 99 für Gast) auf tagged.
Hierzu ne Frage: wenn ich von Access auf Trunk umstelle, dann ist das default VLAN untagged und alle anderen VLANs tagged. Also: 1U, 2T, 50T, 70T, 99T, 1000T - ist das das default-Verhalten beim Umkonfigurieren von Access auf Trunk und ich muss dann einfach die nicht notwendigen VLANs explizit (ich nutze die GUI) per Exclude rauskonfigurieren?
Nur zum Verständnis: falls ich alle VLANs auf dem Port belasse, dann funktioniert es trotzdem. Nur bekommt der Accesspoint dann auch den Traffic der nicht verwendeten VLANs ab. Mangels Mapping auf einen SSID fängt er damit zwar nichts an, ist aber unschön. Daher nehme ich das VLAN 50, 70 und 1000 raus.

den Desktop/Laptop des Mitarbeiters an das Telefon anzuschließen um Ports zu sparen.

Verstanden. Danke! Trunk-Port mit 2U, 50T (2 ist Client; 50 ist Telefon-VLAN)
Ich habe unter Voice LAN Properties den VLAN Default Wert jetzt auf mein VLAN = 50 gesetzt. Hoffe, das war richtig.
Dabei kam aber die im Bild angezeigte, blau markiert Warnung "Auto Smartport und Telefon OUI gehen nicht gemeinsam" - Telefon OUI wäre doch die Erkennung über die Mac-Adresse des Telefon-Herstellers. Du empfiehlst ja LLDP zu nutzen. War das mit der Konfig der Voice VLAN ID ein Fehler?

Ich habe auch 2 Zeilen in der Tabelle Auto Voice LAN

Sinnvoll ist es hier noch das Voice VLAN per LLDP-med durch die Telefone automatisch setzen zu lassen. Dann muss man das nicht immer statisch auf den Telefon Ports konfigurieren beim Umstecken von Telefonen wenn Mitarbeiter mal umziehen.

Wir werden Innovaphone Telefone bekommen.
Auf deren Wiki habe ich zu LLDP gerade dies gefunden: Since v10 by factory default the innovaphone devices accept VLAN configuration via LLDP provided by the switch. If an LLDP VLAN setting is received from the switch
Du schreibst, das Telefon bekommt die VLAN ID (50) von der TK-Anlage. Aber Innovaphone schreibt, dass die Konfig vom Switch kommt. Macht der Switch das automatisch, indem ich unter VoiceVLAN wie oben im Screenshot das VLAN50 eingetragen habe?
Wenn ich den Eintrag von Innoaphone weiter lese, steht da: "If an LLDP VLAN setting is received from the switch, it takes precedence over both local configurations on the device and VLAN information received in a DHCP lease"
D.h. evtl. kann ich die TK-Admins auch bitten, die Info über VLAN-ID durch deren Konfig an die Telefone schicken zu lassen, falls meine Switch-Konfig das nicht sauber überträgt.
Muss ich denn im Switch sonst noch was bzgl QoS für die Telefonie konfigurieren.

Und noch zum Unziehen der Arbeitsplätze der Mitarbeiter: Wenn ich Desktop ans Telefon anschließe, dann muss ich ja den Port von Access auf Trunk umstellen. Also ganz so frei mit dem Umzug ist doch keiner. Wäre dies bei getrennten Dosen/Ports (also Telefon auf einem Port und Desktop auch auf eigenem Port) besser? Könnte ich dann alle diese Ports an den Arbeitsplätzen (was ja alle wären, bis auf die Drucker-Ports) auf VLAN2 = Client konfigurieren. Und wenn ein Telefon angeschlossen wird und LLDP funktioniert, dann wird auf dem Port von VLAN2 auf VLAN50 umgestellt und das Telefon bekommt dann eine IP aus dem Telefon VLAN?

Das ist clever gelöst. Hätte nicht erwartet, dass ein IP Telefon ein VLAN fähigen Mini-Switch mitbringt. Aber sehr konsequent und saubere Lösung

Hätte nicht erwartet, dass ein IP Telefon ein VLAN fähigen Mini-Switch mitbringt

Das können VoIP Telefone schon seit 20 Jahren, seit die ersten auf dem Markt sind ! Zeigt wie lange das schon an dir vorbeigegangen ist !

Also ganz so frei mit dem Umzug ist doch keiner.

Das ist natürlich richtig wenn du auch reine Untagged Ports hast. Aaaaber....
Du kannst über die Mac Adresse oder über 802.1x eine dynamische VLAN Zuornung machen mit deinen Switches. Dann konfiguriert sich alles selber. Das ist aber eine andere Baustelle die dich vermutlich im ersten Ansatz das hier erstmal sauber zum Fliegen zu bringen vermutlich etwas überfordert. Da sind mehrere offene Baustellen eher kontraproduktiv ! Also alles besser der Reihe nach...

Aber Innovaphone schreibt, dass die Konfig vom Switch kommt.

Das ist auch so richtig bei LLDP ! Die statische Konfig bezog sich darauf das man das auch in der Anlagenkonfig den Telefonen statisch mitgeben kann. Letzteres bedeutet aber immer mehr Management Aufwand. Mit LLDP ist das natürlich etwas bequemer.
Die obigen Punkte hast du jetzt aber alle richtg auf dem Radar ! Damit sollte das jetzt ein Knderspiel sein !

Hallo @aqui,
ich benötige nochmal deine Hilfe:
ich wollte ja das Produktionsnetz ähnlich abschotten, wie das Gast-Netz, nur dass hier eben nur die niedrigen IP Adressen, in dem das NAS für die Produktion liegt, ins Internet für die Sicherung dürfen. Also habe ich diese Regeln auch fürs Produktions-VLAN eingerichtet. Nur eben per der Permit Regel mit anderer Netz-Maske (0.0.0.15). Leider hat damit der Ping von zB 192.168.70.200 auf .5 nicht funktioniert.

Nach längerer erfolgloser Suche habe ich dann das mit dem Gast LAN versucht. Und auch hier (Regeln siehe unten im Bild) können die einzelnen Rechner im Gast-Netz (192.168.99.0] nicht untereinander kommunizieren (Ping versucht). Ich kann nicht einmal die .1 Adresse (192.168.99.1) anpingen. Nehme ich die ACL vom VLAN99, dann funktioniert der Ping untereinander und auch der Ping aufs VLAN Interface .1
Ehrlich gesagt, verstehe ich nicht, welcher Teil der 3 Regeln unten im Bild dies verhindert?
Fürs Gast LAN kein Problem. Aber eben fürs Produktions-LAN, da jeder Client das NAS erreichen soll.

Zitat von @aqui:

Hurra! Die ACLs für das Gastnetzwerk haben auf Anhieb funktioniert.

👏 Glückwunsch ! Und wars nun schwer ?!

ich benötige nochmal deine Hilfe:

Immer gerne aber die anderen hier dürfen sicher auch mithelfen.

Leider hat damit der Ping von zB 192.168.70.200 auf .5 nicht funktioniert.

Das ist auch logisch und wird schenll klarr wenn du dir deine Regel von oben ansiehst. Im ACL Regelwerk gilt wie immer: "First match wins !" Bedeutet: Der erste positive Hit in der ACL bewirkt das nachfolgende NICHT mehr ausgeführt werden !!
Deine erste Regel dort am .90er Interface DENY IP 192.168.90.0 0.0.0.255 192.168.0.0 0.0.255.255 killt also ALLES was vom .90er Netz in ein irgendwie geartetes 192.168er Netz geht. Der Rest des Regelwerkes mit nachfolgenden irgendwelchen Permits in 192.168er Netze wirkt dann logischerwese nicht mehr. Works as desgned....würde der Netzwerker sagen.

Du musst also deine ACL in anderer Reihenfolge strukturieren. Beispiel:
Sollen die unteren IPs bis .90.14 in andere 192.168.er Netze und Internet kommen, der Rest aber geblockt sein sähe das so aus:
PERMIT IP 192.168.90.0 0.0.0.15 192.168.0.0 0.0.255.255
DENY IP 192.168.90.0 0.0.0.255 192.168.0.0 0.0.255.255
PERMIT IP 192.168.90.0 0.0.0.15 any
Willst du auch alle weiteren RFC 1918 IP Netze ausschliessen sähe es z.B. so aus:
PERMIT IP 192.168.90.0 0.0.0.15 192.168.0.0 0.0.255.255
DENY IP 192.168.90.0 0.0.0.255 10.0.0.0 0.255.255.255
DENY IP 192.168.90.0 0.0.0.255 172.16.0.0 0.15.255.255
DENY IP 192.168.90.0 0.0.0.255 192.168.0.0 0.0.255.255
PERMIT IP 192.168.90.0 0.0.0.15 any
Die Reihenfolge zählt hier also !!

Was natürlich nicht geht ist wenn du z.B. im gleichen IP Netz (.90.0er Netz) den Zugang der unteren IP Adressen (bis .14) auf die oberen verbieten willst.
Logischerweise ist das unmöglich weil IP Adressen im gleichen IP Netz ja gar nicht geroutet werden und so auch niemals über den Layer 3 Switch gehen, folglich also den ACL Filter so gar nicht "sehen", die ja nur am Routing Interface hängt. Die ACL kann also einzig nur auf Pakete wirken die geroutet werden. Sie wirken NCHT auf lokale Pakete. Wie auch ?? Die verbleiben ja in ihrer lokalen L2 Collision Domain und kommen niemals zum L3 Interface. Dieses ist in die lokale VLAN Kommunikation der Endgeräte dort ja gar nicht involviert.
Sowas kannst du dann nur mit Mac Adress Filtern oder mit Layer 3 Filtern direkt auf jedem einzelnen Port filtern. Global über das Layer 3 Routing Interface des VLANs im Switch ist das technisch aus den o.a. Gründen natürlich nicht möglich.
Nur das du das auf dem Radar hast !

Zitat von @aqui:
Du musst also deine ACL in anderer Reihenfolge strukturieren. Beispiel:
Sollen die unteren IPs bis .90.14 in andere 192.168.er Netze und Internet kommen, der Rest aber geblockt sein sähe das so aus:

Wenn ich das richtig verstehe, dann bewirken diese Zeilen:
PERMIT IP 192.168.90.0 0.0.0.15 192.168.0.0 0.0.255.255
Die 14 unteren 90-er IPs kommen in die anderen 192.168-er Netze
Das ist aber überhaupt nicht notwendig.
DENY IP 192.168.90.0 0.0.0.255 192.168.0.0 0.0.255.255
Der Rest (die oberen 90er) kommen in kein anderes 168er Subnetz
Aber sie müssten doch im 90er Netz die unteren 90er erreichen. Also die Maschinen (oberen 90er erreichen das NAS (untere 90er Adresse)

PERMIT IP 192.168.90.0 0.0.0.15 any

Die unteren 90er kommen ins Internet

Die Reihenfolge zählt hier also !!

Was natürlich nicht geht ist wenn du z.B. im gleichen IP Netz (.90.0er Netz) den Zugang der unteren IP Adressen (bis .14) auf die oberen verbieten willst.

Genau das war auch mein Verständnis. Innerhalb des 192.168.90.0 Netzes kann jede IP Adresse jede andere im .90er erreichen. Das geht ja ohne Routing.
Aber genau dies geht mit meinen ursprünglichen beiden Regeln nicht. Liegt das daran, dass
DENY IP 192.168.90.0 0.0.0.255 192.168.0.0 0.0.255.255 an erster Stelle stand?

Vielleicht habe ich mich bei meiner Problembeschreibung etwas unscharf ausgedrückt.
Ich meinte, dass ich mit meinen ursprünglichen Regeln keinen Ping von 192.168.90.200 auf 192.168.90.5 hinbekomme. An der Firewall kann es nicht liegen, denn sobald ich die ACL vom VLAN90 entferne läuft der Ping. Ist das erklärlich? Und durch die neuen von Dir vorgeschlagenen Regeln in anderer Reihenfolge behoben.

Die 14 unteren 90-er IPs kommen in die anderen 192.168-er Netze

Ja, das ist richtig !
Sorry, wenn das nicht so sein sollte, dann habe ich dich irgendwie missverstanden.

Der Rest (die oberen 90er) kommen in kein anderes 168er Subnetz

Jepp, auch richtig verstanden.

Die unteren 90er kommen ins Internet

Auch das ist richtig !
Sprich also in der Gesamtheit: Die unteren 40 kommen in die 192.168er Restnetze und ins Internet. Der Rest kommt nirgendwo hin und kann nur im eigenen Netz arbeiten.
Sorry wenn das falsch verstanden war was du eigetlich wolltest.

Liegt das daran, dass ... an erster Stelle stand?

Nein ! Sollte es wenigstens nicht. Die Filterliste wirk ja einzig nur auf gerouteten Verkehr über das L3 Interface.
Diese Regel besagt ja das der Traffic vom .90er Netz in alle anderen 192.168er Netze geblockt wird. Traffic z.B ins Internet oder z.B. 10er Netze usw. sollte weiter funktionieren (sofern ein PERMIT IP 192.168.90.0 0.0.0.255 any am Ende steht !!). Kommunikation im eigenen L2 Netz also im .90er Netz selber sollte also niemals unterbunden werden.
Voruasgesetzt du platzierst die ACL richtig unter dem L3 Interface unt nicht als Port ACL ?!! Letzteres filtert dann natürlich den gesamten 192.168er Traffic weg auch untereinander. ACLs platziert ma in der Regel aber immer als L3 ACL am Routing Interface !!!

Zitat von @aqui:

Hurra! Die ACLs für das Gastnetzwerk haben auf Anhieb funktioniert.

👏 Glückwunsch ! Und wars nun schwer ?!

Wird mich dies beim Umstieg von Kupferport - auf Glasport auch treffen

Also Kupfer und Glas parallel anschließen und dann das Verbindungsinterface ändern?

Genau so sollte es klappen.

Nur zu Doku-Zwecken: es hat genau so geklappt.
Parallel zum Kupfer schon mal die Glas-Ports "verkabelt" und dann nur im Web-Interface die Stackports neu festgelegt. Diese werden grafisch gelb markiert dargestellt. ich habe das für alle 3 Switches auf einmal gemacht und erst dann anschliessend auf "OK" gedrückt. Danach gabs einen Reboot und der Stack lief von da an übers Glasfaser. Anschliessend habe ich die Kupfer Verbindungen entfernt.

German solved Question LAN, WAN, Wireless Networks

Hotly discussed

How to set up and configure a Linux GRE tunnelAlexWisha - 3 Comments

WIREGUARD VPN ON UDM PRO BEHIND FRITZBOX - HANDSHAKE DID NOT COMPLETEjstricker - 1 Comment

End of Support dates for Office 2016, 2019 Apps und Productivity ServersDani - 1 Comment