17.10.2023, aktualisiert am 23.11.2023

2157

Cisco SG350-10 Management Board nicht von allen VLANs zugängig machen

gelöstFrage Netzwerkmanagement Netzwerke

Hallo,

ich habe mein Netzwerk mit viel Hilfe aus diesem Forum so eingerichtet, dass ich nun folgende Konfiguration habe;

Internet ==> Fritzbox 6660 Cable (192.168.178.1) ==> Cisco (192.168.178.2) => Netgear (192.168.178.3) ==> Diverse clients über WLAN mit Hilfe der Ubiquiti APs, einmal AC Pro (192.168.178.5)
und einmal Lite (192.168.178.4) und LAN (Patchfeld was zu einzelnen Räumen im Haus geht)

VLANs:
VLAN 10 (Private Geräte) - 192.168.10.0/24
VLAN 20 (Gästegeräte) - 192.168.20.0/24
VLAN 30 (IoT Geräte) - 192.168.30.0/24
VLAN 40 (Arbeitsgeräte) - 192.168.40.0/24
VLAN 50 (Klingel) - 192.168.50.0/24

ACLs: (Beispiel für alle anderen ACLs die genauso konfiguriert sind)
VLAN10 to any

Das funktioniert soweit alles gut.

Jetzt wollte ich gerne noch dafür sorgen, dass man die Management-Konsole des Cisco SG350 (192.168.178.2) nicht aus allen VLANs erreichen kann und nur über Geräte mit einer bestimmten IP. Ich frage mich wie ich meine ACLs ändern muss damit das hinhaut, aber der Cisco gleichzeitig für das Routing weiter erreichbar bleibt?

Kann mir da bitte jemand weiterhelfen?

Grüße

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

Content-ID: 83352349714

Url: https://administrator.de/forum/cisco-sg350-10-management-board-nicht-von-allen-vlans-zugaengig-machen-83352349714.html

Ausgedruckt am: 20.04.2025 um 19:04 Uhr

29 Kommentare

Neuester Kommentar

Dein Management VLAN ist dann vermutlich (geraten) VLAN 1 und der Cisco setzt die [ Layer 3 VLAN Segmentierung] um. Ist das richtig? Leider machst du dazu nur wenige Angaben.

Du erzeugst dann eine ACL
deny ip any host 192.168.178.2
permit ip any any
Diese bindest du auf alle VLAN IP Interfaces außer auf VLAN 1

Die ACL ist selbsterklärend. Damit wird dann an jeglicher Traffic aus diesen Segmenten der eine Zieladresse 192.168.178.2 hat geblockt und jeglicher anderer Traffic erlaubt.
Das wäre die einfachste Lösung.
Man kann das auch noch etwas granularer machen indem man nur die TCP Ports filtert usw. Das kommt aber immer drauf an wie deine eigene Sicherheitsanforderung ist und wieviel Aufwand du treiben willst.

Sorry, ja, mein Management VLAN ist VLAN 1 und der Cisco übernimmt die Layer 3 VLAN Segmentierung. Ich hatte das alles so gemacht, wie du mir in diesem Post gesagt hattest.

Wenn ich die ACL so mache wie von dir angegeben und auf alle VLAN IP Interfaces (ist immer die .1 am Ende siehe Beispiel VLAN 10 (Private Geräte) - 192.168.10.1/24) binde außer VLAN 1, heißt dass doch dass ich mit meinem Gerät (192.168.10.X) mit dem ich rauf will auch nicht mehr raufkomme oder? Sprich ich müsste da in der ACL doch noch eine permit-Zeile hinzufügen richtig?

Wenn ich die ACL so mache wie von dir angegeben

Die o.a. ACL gilt nur wenn der Switch im Default auf den Whitelisting ACL Mode (Default Action Deny Any) gesetzt wurde Das musst du beachten!

heißt dass doch dass ich mit meinem Gerät (192.168.10.X) mit dem ich rauf will auch nicht mehr raufkomme oder?

Wie kommst du darauf? 🤔
Das letzte ACL Statement "permit ip any any" hast du gesehen oder?!

Nochmal die Logik der ACL:

Zeile 1: deny ip any host 192.168.178.2 = Blockiert eingehend ALLES was als Zieladresse die 192.168.178.2 hat, sprich also alles was den Switch direkt anspricht.
Zeile 2: permit ip any any = Lässt alles andere nach überall passieren
Default Regel am Ende: Blockiere den ganzen Rest (Default Action Deny Any)

Du hast aber Recht, die ACL hat noch einen gravierenden (Denk)Fehler, sorry. 🙈
Wenn du im VLAN 10 bist kannst du damit nicht auf die .178.2 zugreifen aber wenn du stattdessen die lokale .10.1 ansprichst oder eins der anderen lokalen IP Interfaces, also immer das jeweils lokale Switch IP Interface bist du dennoch auf dem Switch Management.

Folglich musst du also alle Switch IP Interfaces in die ACL einbinden ala:
deny ip any host 192.168.178.2
deny ip any host 192.168.10.1
deny ip any host 192.168.20.2
deny ip any host <vlanX_ip>
permit ip any any

Natürlich kann man die ACL auch spezifischer gestalten:

Zeile 1: deny ip 192.168.10.0 0.0.0.255 host 192.168.178.2 = Blockiert eingehend ALLES was aus .10.x kommt und als Zieladresse die 192.168.178.2 hat, sprich also alles was den Switch direkt anspricht.
Zeile 2: permit ip 192.168.10.0 0.0.0.255 any = Lässt alles was aus .10.x kommt nach überall passieren
Default: Blockiere den ganzen Rest (Default Action Deny Any)

Diese Variante ist sicherer hat aber den Nachteil das du sie dediziert für jedes VLAN erstellen und dem entsprechenden VLAN Interface zuweisen musst.
Außerdem musst du bei DHCP, sofern der Switch selber DHCP Server für deine VLANs ist, und du keinen zentralen DHCP Server mit DHCP Relay verwendest eine Ausnahme für DHCP zusätzlich in die ACL bringen! Guckst du dazu HIER!

Der Vorteil von der obigen Variante ist das es zwar etwas mehr "Scheunentor" ist mit any any aber du die ACL nur einmal erstellen musst für alle IP Interfaces außer vlan1 und keine Ausnahme für DHCP brauchst.

Zitat von @aqui:
Du hast aber Recht, die ACL hat noch einen gravierenden (Denk)Fehler, sorry. 🙈
Wenn du im VLAN 10 bist kannst du damit nicht auf die .178.2 zugreifen aber wenn du stattdessen die lokale .10.1 ansprichst oder eins der anderen lokalen IP Interfaces, also immer das jeweils lokale Switch IP Interface bist du dennoch auf dem Switch Management.

Würde ich mit der ACL in dieser Form aber nicht wieder den unerwünschten Nebeneffekt haben, dass die Kommunikation zwischen den VLANs wieder möglich ist, wenn ich nicht den Deny Teil aus dem Screenshot von oben übernehme?

Zitat von @aqui:
Natürlich kann man die ACL auch spezifischer gestalten:

Zeile 1: deny ip 192.168.10.0 0.0.0.255 host 192.168.178.2 = Blockiert eingehend ALLES was aus .10.x kommt und als Zieladresse die 192.168.178.2 hat, sprich also alles was den Switch direkt anspricht.
Zeile 2: permit ip 192.168.10.0 0.0.0.255 any = Lässt alles was aus .10.x kommt nach überall passieren
Default: Blockiere den ganzen Rest (Default Action Deny Any)

Diese Variante würde doch dann auch wieder Kommunikation zwischen den VLANs zulassen oder regelt die Default action? Grundsätzlich ist die Aufteilung der ACLs aktuell eh schon sehr granular, da jedes IP-Interface eine eigene (su wie auf dem Screenshot für VLAN10 zu sehen, nur immer angepasst an das entsprechende VLANx) zugewiesen bekommen hat

DHCP läuft auch über den Switch, also müsste ich das so machen wie in dem von dir verlinkten Beitrag.

dass die Kommunikation zwischen den VLANs wieder möglich ist

Ja, die bleibt dann natürlich möglich. Du hattest ja auch nicht gesagt das du die Kommunikation innerhalb deiner VLANs gänzlich unterbinden willst.

Dann sähe eine ACL natürlich ganz anders aus und wäre deutlich einfacher:

deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Das an jedes VLAN Interface außer 1 blockt dir jegliche Kommunikation in andere 192.168.er VLANs sofern du nur eine 192.168.x.y Adressierung benutzt.
Willst du vorsorglich alle privaten RFC 1918 IP Netze blocken dann sieht das so aus:

deny ip any 10.0.0.0 0.0.0.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

⚠️ Vorsicht bei den o.a. ACLs wenn du bestimmte Dienste wie DNS z.B. auf einer FritzBox aus den VLANs zentral nutzt, denn die musst du logischerweise in den ACLs freigeben sonst scheitert z.B. die DNS Auflösung!
So eine ACL sähe dann so aus die DNS und NTP (Uhrzeit) z.B. von deiner Fritzbox in VLAN 1 erlaubt.

permit udp any host 192.168.178.1 eq 53
permit tcp any host 192.168.178.1 eq 53
permit udp any host 192.168.178.1 eq 123
permit tcp any host 192.168.178.1 eq 123
deny ip any 10.0.0.0 0.0.0.255
deny ip any 172.16.0.0 0.15.255.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Man kann die ersten 4 Zeilen auch durch nur zwei vereinfachen:
permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
Erklärung:

Die ersten 4 (oder 2) Regeln erlauben jeweils DNS (Port 53) und NTP (Port 123) auf die Fritzbox in VLAN 1. (DNS und NTP nutzen sowohl UDP als auch TCP)
Die folgenden 3 Regeln blockieren alle Zugriffe in alle privaten RFC1918 IP Netze
Die letzte Regel erlaubt allen Traffic ins Internet

Diese ACL kannst du an allen VLAN IP Interfaces außer 1 aktivieren.

Zitat von @aqui:

dass die Kommunikation zwischen den VLANs wieder möglich ist

Ja, die bleibt dann natürlich möglich. Du hattest ja auch nicht gesagt das du die Kommunikation innerhalb deiner VLANs gänzlich unterbinden willst.

Stimmt, tut mir Leid, ich versuche mal eben nochmal so genau wie möglich zu erklären, wie das Setup bisher aussieht;

Internet ==> Fritzbox 6660 Cable (192.168.178.1) ==> Cisco SG350-10 10-Port (192.168.178.2) => Netgear GS324T-100 (192.168.178.3) ==> Diverse clients über WLAN mit Hilfe der Ubiquiti APs, einmal AC Pro (192.168.178.5)
und einmal Lite (192.168.178.4) und LAN (Patchfeld was zu einzelnen Räumen im Haus geht)

VLANs:
VLAN 1 (Management) - 192.168.178.2/24
VLAN 10 (Private Geräte) - 192.168.10.0/24
VLAN 20 (Gästegeräte) - 192.168.20.0/24
VLAN 30 (IoT Geräte) - 192.168.30.0/24
VLAN 40 (Arbeitsgeräte) - 192.168.40.0/24
VLAN 50 (Klingel) - 192.168.50.0/24

Der Cisco SG350-10 10-Port (192.168.178.2) ist das Hirn und kümmert sich um die VLANs, Routing und DHCP. Der Netgear GS324T-100 (192.168.178.3) sorgt nur dafür dass ich mehr Ports habe die ich belegen kann, er befolgt also die VLAN-Konfiguration des Ciscos. Die Fritzbox sorgt für den Zugang von und zum Internet und für DNS. In der Fritzbox selber habe ich dafür folgendes konfiguriert;

und im Cisco folgendes;

Die VLANs sollen nicht miteinander kommunizieren können, daher sehen die ACLs dazu wie unten aus;

Die Konfiguration hatten wir zusammen in einem anderen Post so erarbeitet und sie funktioniert auch einwandfrei. Jedoch möchte ich jetzt zwei Dinge verändern, und zwar will ich das man zusätzlich zu der bestehenden Konfiguration aus den VLANs (abgesehen von dem Gerät 192.168.10.2) nicht einfach so auf die folgenden Management-Konsolen kommt;

FritzBox (192.168.178.1)
Cisco (192.168.178.2)
Netgear (192.168.178.3)

In der Fritzbox selber habe ich dafür folgendes konfiguriert;

Das ist das IP Routing und absolut korrekt! 👍

Die VLANs sollen nicht miteinander kommunizieren können, daher sehen die ACLs dazu wie unten aus;

Die sind dann aber ziemlicher Unsinn wie du ja selber sehen kannst. ☹️
Im ersten Beispiel bzw. auch allen folgenden steht ja schon gleich: permit any 192.168.178.0 als erste Regel, was bedeutet das das VLAN bzw. alle VLANs vollständigen Zugriff auf dein Management IP Netz bekommen!
Gerade DAS will man ja gar nicht und führt dein gesamtes Regelwerk gemäß deiner eigenen Vorgabe (Zitat: "Die VLANs sollen nicht miteinander kommunizieren können") ja völlig ad absurdum.

Auch die 2te Regel ist völlig absurd denn sie erlaubt explizit den Zugang auf das lokale Switch IP Gateway Interface, sprich also der direkte Zugriff auf den L3 Switch was du ebenfalls explizit ja nicht willst.
2 Regeln die also ALLES komplett erlauben von dem was du selber gar nicht willst. Du hast also ein Regelwerk erstellt was komplett gegen deine eigenen Vorgaben geht.
Das das ziemlicher (ACL) Quatsch ist sollte man eigentlich auch als Laie erkennen.

Damit das in geordnete Bahnen kommt erstmal 2 ACL Grundregeln vorweg:

Regeln greifen immer nur inbound also VOM Netzwerk Draht IN den Switch hinein
⚠️ Es gilt immer: "First match wins"! Sprich also die ACL arbeitet nach dem ersten positiven Hit im Regelwerk den Rest der Regeln in der ACL nicht mehr ab!

Mit dem Rüstzeug gehst du nun an deine neuen, sinnvollen VLAN Regeln.
Da dein Cisco Switch DHCP Server ist für deine VLANs und DNS und ggf. NTP der VLAN Clients auf die Fritzbox IP passieren müssen, musst du das also vorher in der ACL erlauben.
Damit erstellst du eine einzige ACL die du auf allen VLAN Interfaces außer VLAN 1 aktivierst:

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Erklärung der ACL:

1 = Erlaubt alle UDP Pakete aus dem VLAN mit der Zieladresse Fritzbox und Zielport DNS und NTP so das alle DNS und NTP Requests aus den VLANs bei der FB ankommen. Web Zugriff auf die FB bleibt verboten. (eq = equals = gleich)
2 = Wie 1 nur das hier TCP Pakete gemeint sind
3 = Blockiert aus dem VLAN alles was Zieladressen in allen anderen 192.168.x.y VLANs hat. Sprich also die Kommunikation mit allen anderen VLANs. Das gilt auch wenn du aus VLAN 1 auf Komponenten in anderen VLAN zugreifen willst. Deren Rücktraffic bleibt auch hier hängen. Willst du dies erlauben muss man die o.a. ACL etwas umbauen.
4 = Erlaubt die Kommunikation mit allen anderen Absender- und Zieladressen, sprich dem Internet. Diese Regel bewirkt auch das DHCP Requests der VLAN Clients mit Absender 0.0.0.0 und Ziel 255.255.255.255 auf den Switch passieren können.

Dein Denkfehler ist vermutlich das du die First match wins Grundregel nicht auf dem Radar hattest und die Regel 4 dich verwirrt hat, die ja vermeintlich alles erlaubt. Dem ist aber nicht so...
Alle IP Pakete die aus den VLANs zu einem deiner anderen VLANs wollen bleiben schon vorab an Regel 3 hängen. Sprich hier an 3 gibt es dann einen positiven Hit, der bewirkt das der Rest (Regel 4) nicht mehr abgearbeitet wird. Einfache ACL Logik!

Fazit:
Lösche deinen ACL Unsinn von oben und setze eine korrekte ACL, dann funktioniert es auch wie gewünscht!

Zitat von @aqui:

In der Fritzbox selber habe ich dafür folgendes konfiguriert;

Das ist das IP Routing und absolut korrekt! 👍

Die VLANs sollen nicht miteinander kommunizieren können, daher sehen die ACLs dazu wie unten aus;

* ⚠️ Es gilt immer: "First match wins"! Sprich also die ACL arbeitet nach dem ersten positiven Hit im Regelwerk den Rest der Regeln in der ACL nicht mehr ab!

Das hatte ich tatsächlich nicht auf dem Schirm, als ich die ACLs erstellt habe.

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Ich bin gerade unsicher, aber hab die ACL mal so konfiguriert und werde es damit mal probieren...

Wir sind gespannt...! 😉

Es funktioniert wie von dir beschrieben, danke schon mal dafür. Zwei Fragen noch, eine davon wäre vielleicht was für einen eigenen Thread.

Wenn ich das jetzt auf alle assigne, komme ich mit meinem Rechner (192.168.10.2) auch nicht mehr rauf, daher würde die Zeilen unten zusätzlich doch helfen oder?

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
permit ip 192.168.10.2 192.168.178.1
permit ip 192.168.10.2 192.168.178.2
permit ip 192.168.10.2 192.168.178.3
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Zweite Frage wäre, ich habe in einem VLAN (50) eine Kamera und auf diesen Feed würde ich mit Home Assistant aus einem anderen VLAN (10) gerne zugreifen wollen. Ich will nur den Feed abgreifen können, die Kamera selber soll nicht in das andere VLAN reinkönnen. Wie gesagt, kann sein dass das was für einen eigenen Thread ist...

komme ich mit meinem Rechner (192.168.10.2) auch nicht mehr rauf,

Du meinst mit deinem Rechner im 10er VLAN .10.2 auf das Konfig Interface des Switches und FB im VLAN-1?
Ja, die Zeilen würden helfen damit der bestimmte Rechner auf den Switch und die Fritzbox kommt
Aber wer oder was ist die .178.3 ??
Du kanns es auch etwas vereinfachen wenn du mit deinem Rechner generell auf alles im .178.0er Netz zugreifen willst:

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
permit ip host 192.168.10.2 192.168.178.0 0.0.0.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Wie stringent du die ACL gestalten willst ist ja immer deine eigene Entscheidung.
Beachte hier das du deinem Rechner dann im DHCP Server eine feste Reservierung auf Basis seiner Mac Adresse geben musst damit er immer fest die .10.2 bekommt!! Sollte die IP einmal durch die Dynamik von DHCP wechseln ists aus mit dem Zugriff auf das .178.0er Netz.

Ich will nur den Feed abgreifen können

Was genau ist ein "Feed" für dich?? Das muss man für eine laufende ACL natürlich wissen.
Und ist der Home Assitant ein einzelner Hostrechner oder mehrere?
Beispiel mit einem Schrotschuss der ALLE TCP oder UDP Protokolle der Kamera die die .50.100 hat und an den Home Assitant mit der IP .10.100 durchlässt dann sähe die ACL an VLAN 10 so aus

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
permit ip host 192.168.10.2 192.168.178.0 0.0.0.255
permit ip host 192.168.10.100 host 192.168.50.100
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Da ACLs bekanntlich nicht stateful sind, benötigst du natürlich auch eine entsprechende Freigabe am VLAN 50:

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
permit ip host 192.168.50.100 host 192.168.10.100
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Zitat von @aqui:

Aber wer oder was ist die .178.3 ??

Das ist der Netgear Switch.

Du kanns es auch etwas vereinfachen wenn du mit deinem Rechner generell auf alles im .178.0er Netz zugreifen willst:

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
permit ip host 192.168.10.2 192.168.178.0 0.0.0.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Die IP ist fest reserviert, also sollte es zu dem wechsel nicht kommen

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
permit ip host 192.168.10.2 192.168.178.0 0.0.0.255
permit ip host 192.168.10.100 host 192.168.50.100
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Kompliziert ausgedrückt, mit dem Feed meine ich den Videostream der Kamera. Der Home Assistant ist ein eigenständiger Host und soll auf den Videostream zugreifen können. Diesen Videostream will ich in Home Assistant verarbeiten können.

Da ACLs bekanntlich nicht stateful sind, benötigst du natürlich auch eine entsprechende Freigabe am VLAN 50:

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
permit ip host 192.168.50.100 host 192.168.10.100
deny ip any 192.168.0.0 0.0.255.255
permit ip any any 

Reicht die Freigabe von

permit ip host 192.168.10.100 host 192.168.50.100

oben nicht aus?

Das ist der Netgear Switch.

Ahh, ok. Alle solche festen IPs zum managen musst du dann so eintragen.
Man kann das auch etwas pfiffiger machen und z.B. alle fest zu managen IP Adressen in einen ersten CIDR Subnetz Block legen den man freigibt. So kann man die ACL effizient gestalten ohne zig Regeleinträge. Z.B.
permit ip host 192.168.10.2 192.168.178.0 0.0.0.7
Gibt den IP Bereich .178.1 bis .178.6 dann frei für den Zugriff vom Rechner mit der .10.2.
Reicht das nicht aus von der Anzahl kannst du die Wildcard Maske vergrößern.
permit ip host 192.168.10.2 192.168.178.0 0.0.0.15
Das gibt dann den IP Bereich .178.1 bis .178.14 frei für den Zugriff vom Rechner mit der .10.2.
Simple ACL Logik...

Reicht die Freigabe von oben nicht aus?

Wie meinst du das genau?? Nur die ACL auf dem VLAN 10 sollte reichen??
Nein, das reicht so nicht, denn wie oben schon gesagt sind ACLs nicht stateful und du musst dann immer beide Richtungen einer Netzwerk Kommunikation betrachten.

Was dann passiert ist das dein Traffic zum Initiieren des Streams von .10.100 durch die ACL auf .50.100 zwar passieren kann, danach auch die Kamera dann Streamtraffic mit Absender .50.100 und Ziel 10.100 sendet dieser aber dann logischerweise an der ACL Blocking Regel an VLAN 50 hängen bleibt (deny ip any 192.168.0.0/16) sofern du dort an VLAN 50 kein entsprechendes Regelwerk dafür definiert hast!
Einfache Logik! 😉

Zitat von @aqui:

Das ist der Netgear Switch.

Ahh, ok. Alle solche festen IPs zum managen musst du dann so eintragen.
Man kann das auch etwas pfiffiger machen und z.B. alle fest zu managen IP Adressen in einen ersten CIDR Subnetz Block legen den man freigibt. So kann man die ACL effizient gestallten ohne zig Regeleinträge. Z.B.
permit ip host 192.168.10.2 192.168.178.0 0.0.0.7
Gibt den IP Bereich .178.1 bis .178.6 dann frei für den Zugriff vom Rechner mit der .10.2.
Reicht das nicht aus von der Anzahl kannst du die Wildcard Maske vergrößern.
permit ip host 192.168.10.2 192.168.178.0 0.0.0.15
Das gibt dann den IP Bereich .178.1 bis .178.14 frei für den Zugriff vom Rechner mit der .10.2.
Simple ACL Logik...

Die habe ich tatsächlich in den ersten CIDR Subnetz Block gelegt, siehe unten

Fritzbox 6660 Cable (192.168.178.1)
Cisco SG350-10 10-Port (192.168.178.2)
Netgear GS324T-100 (192.168.178.3)
Ubiquiti Lite (192.168.178.4)
Ubiquiti AC Pro (192.168.178.5)

Reicht die Freigabe von oben nicht aus?

Jetzt verstehe ich, danke. Ich werde das mal so konfigurieren und mal testen, melde mich dann wieder 😉

Danke für die bisherige Hilfe. Ich habe die ACL angepasst und allen VLANs zugewiesen, sie sieht jetzt wie folgt aus;

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
permit ip host 192.168.10.2 host 192.168.178.0 0.0.0.7
permit ip host 192.168.10.20 host 192.168.50.2
permit ip host 192.168.50.2 host 192.168.10.20
permit ip host 192.168.10.0 0.0.0.255 host 192.168.10.0 0.0.0.255
deny ip any 192.168.0.0 0.0.255.255
permit ip any any  

Die dritte Zeile von unten habe ich hinzugefügt, um die Kommunikation der Geräte untereinander im VLAN10 zuzulassen. Ich hatte die Konfiguration erst ohne sie, da konnten meine anderen Geräte dann mit den unterschiedlichen Services nicht mehr kommunizieren. Ist das so richtig angewandt oder entspricht das nicht der Best Practice?

Das komische ist, ohne die Zeile für den Datenverkehr in VLAN10 hatte ich vorhin eine Verbindung zwischen .10.20 und 50.2. Seitdem ich die Zeile drin hab, kann ich da nicht mal mehr erfolgreich pingen..

Die dritte Zeile von unten habe ich hinzugefügt, um die Kommunikation der Geräte untereinander im VLAN10 zuzulassen.

Das ist Unsinn, denn die Kommunikation von Clients in einem VLAN untereinander passiert ja immer direkt im Layer 2 und nicht über den L3-Switch/Router.
Wozu auch wenn die beiden Partner im gleichen IP Netz liegen und sich direkt "sehen" können. Es wäre ja unsinnig wenn der Router dann noch als überflüssiger "Durchlauferhitzer" dazwischen liegen müsste.
Du kannst Partner im gleichen IP Netz ja auch ganz ohne Router an einen ungemanagten Switch oder sogar mit einem Kabel Rücken an Rücken hängen und sie können fehlerlos miteinander kommunizieren.
Mit anderen Worten: Diese Regel ist völlig nutzlos da sie niemals greift!

Als ob das nicht schon genug wäre ist sie obendrein auch noch syntaktisch völlig falsch!

Nach soviel ACL Schulung hier solltest du es aber langsam mal drauf haben... 😉
Eine Regel mit dem Parameter "host" impliziert, wie der Name schon sagt, immer eine 32 Bit Hostmaske (invers 0.0.0.0 wie es in ACLs ja üblich ist).
Hier dann aber in Kombination mit host eine Netzwerkmaske anzugeben ist doppelter Unsinn und bewirkt erwartungsgemäß das o.a. Fehlerbild.

Oh okay, also fliegt die direkt raus, so dass nur noch folgendes übrig bleibt?

permit udp any host 192.168.178.1 eq 53 eq123
permit tcp any host 192.168.178.1 eq 53 eq 123
permit ip host 192.168.10.2 host 192.168.178.0 0.0.0.7
permit ip host 192.168.10.20 host 192.168.50.2
permit ip host 192.168.50.2 host 192.168.10.20
deny ip any 192.168.0.0 0.0.255.255
permit ip any any  

So hatte ich vorhin aber tatsächlich ein Problem im VLAN10, ich konnte die anderen Geräte nicht mehr über ihre IP erreichen. Wo habe ich hier etwas übersehen?

Zitat von @aqui:
Nach soviel ACL Schulung hier solltest du es aber langsam mal drauf haben... 😉

Ich glaube ich muss was das Thema Netzwerk betrifft nochmal grundsätzlich zurück auf die Schulbank...

nicht mehr über ihre IP erreichen. Wo habe ich hier etwas übersehen?

Die Regel "permit ip host 192.168.50.2 host 192.168.10.20" auch unsinnig.
Diese blockt Pakete mit einer Host Absenderaddresse von 192.168.50.2 auf einen lokalen Host .10.20.
Da fragt man sich WO aus dem VLAN 10, was ja immer nur .10.x Absenderadressen haben kann, mit einmal eine .50er Absender IP herkommen soll 🤔
Auch diese Regel ist sinnfrei da sie niemals greifen kann! Zumindestens nicht an VLAN 10.
Immer das Grundsyntax Format: permit/deny Absender_IP zu **Ziel_IP auf dem Radar haben!

Ich glaube es ist einfacher für mich zu erklären, was ich meine wenn ich einfach mal den Screenshot dazu poste.

Zeile 8 werde ich entfernen, da die Geräte sich im VLAN auch so sehen können sollten. Zeile 6 und 7 jedoch sind doch eigentlich so korrekt, für die Kommunikation zwischen 192.168.10.20 und 192.168.50.2 oder?

Zeile 6 schon aber Zeile 7 ist Unsinn, zumindestens dann wenn du diese ACL auf das VLAN 10 Interface mappst. Denke selber mal etwas nach....

Wenn Pakete aus dem VLAN 10 kommen haben die ja erwartungsgemäß eine Absender IP mit .10.6.
Deine Regel 7 permittet IP Pakete mit einer Absender IP von .50.x am VLAN 10 Interface und da fragt man sich dann WO sollen die denn herkommen am VLAN 10 Interface??
Würde ja dann bedeuten du hast im VLAN 10 dann irgendwie Endgeräte mit einer statisch konfigurierten .50.x IP Adresse oder sowas.
Mit anderen Worten: Wen oder was soll denn die Regel 7 permitten?? Das ist doch (Inbound) Traffic der niemals dort (VLAN 10) ankommt und folglich greift diese überflüssige Regel niemals weil dort nie .50.x Absender IPs auftauchen.
Wenn überhaupt müsste diese Regel ans VLAN 50 Interface, denn dort kommen ja auch Pakete mit .50.x IPs an.
Die Regeln greifen doch immer nur inbound und immer nach dem Schema PERMIT/DENY Absender Ziel !

Es war nicht gedacht, dass der .50.2 Traffic aus dem VLAN 10 gekommt, das geht verständlicherweise nicht. Ich habe die ACL so wie sie dort abgebildet ist auf alle VLANs gemappt und dachte wenn dann Traffic von VLAN 50 kommt, würde der durch diese Regel die Verbindung zwischen 50.2 und 10.20 ermöglichen.

Das habe ich so gemacht, da ich nun statt 5 einzelnen ACLs nur noch eine habe, wie weiter oben vorgeschlagen wurde, die ich auf alle Interfaces gemappt habe.

Es war nicht gedacht, dass der .50.2 Traffic aus dem VLAN 10 gekommt.

Ist auch evident wenn dort nur .10.x Endgeräte senden.

und dachte wenn dann Traffic von VLAN 50 kommt, würde der durch diese Regel die Verbindung zwischen 50.2 und 10.20 ermöglichen.

OK, das kann man natürlich machen und hast du leider unterschlagen und war nicht klar.

Eine quasi "Universal ACL" hat dann aber sehr viele VLAN spezifische Statements im Regelwerk die hie und da dann nutzlos sind und man muss dann sehr genau aufpassen das man sich da dann keine Fussfallen legt.
Die Frage ist dann ob man das will oder dann doch lieber wieder etwas mehr VLAN spezifische ACLs dort konfiguriert.
Wie gesagt, kann klappen wenn man aufpasst. Wie dir das kosmetisch am liebsten ist musst du selber entscheiden.

Ich habe das ganze jetzt nochmal aufgedröselt in 3 unterschiedliche ACLs.

Das ist die ACL die ich VLAN 10 zuweisen werde.

Die ersten vier Einträge;

Zitat von @aqui leicht abgeändert:
Erklärung der ACL:

1 und 2 = Erlaubt alle UDP Pakete aus dem VLAN mit der Zieladresse Fritzbox und Zielport DNS und NTP so das alle DNS und NTP Requests aus den VLANs bei der FB ankommen. Web Zugriff auf die FB bleibt verboten. (eq = equals = gleich)
3 und 4 = Wie 1 nur das hier TCP Pakete gemeint sind

Eintrag fünf erlaubt meinem Rechner die Kommunikation mit den Geräten von IP 192.168.178.1-6 (Fritzbox, Switch, Switch, AP, AP).

Eintrag 6 soll die Kommunikation zwischen einem Gerät im VLAN 10 und einer Videoklingel in VLAN 50 erlauben, von 10 nach 50.

Die letzten zwei;

Zitat von @aqui leicht abgeändert:

[...]

* 9 = Blockiert aus dem VLAN alles was Zieladressen in allen anderen 192.168.x.y VLANs hat. Sprich also die Kommunikation mit allen anderen VLANs. Das gilt auch wenn du aus VLAN 1 auf Komponenten in anderen VLAN zugreifen willst. Deren Rücktraffic bleibt auch hier hängen. Willst du dies erlauben muss man die o.a. ACL etwas umbauen.

10 = Erlaubt die Kommunikation mit allen anderen Absender- und Zieladressen, sprich dem Internet. Diese Regel bewirkt auch das DHCP Requests der VLAN Clients mit Absender 0.0.0.0 und Ziel 255.255.255.255 auf den Switch passieren können.

Das ist die ACL die ich VLAN 50 zuweisen werde.

Die ersten vier Einträge sind wie oben beschrieben.

Eintrag fünf soll die Kommunikation zwischen einer Videoklingel in VLAN 50 und einem Gerät im VLAN 10 erlauben, von 50 nach 10.

Die letzten zwei sind wie oben beschrieben.

Das ist die ACL die ich VLAN 20, 30 und 40 zuweisen werde.

Alle Einträge sind wie oben beschrieben und es gibt keine Sonderlocken.

Das müsste mein bisheriges Problem doch lösen, richtig?

Das ist die ACL die ich VLAN 10 zuweisen werde.

Leider schon wieder syntaktisch mit einigen groben Fehlern.

Sie mal selber hin, du hast bei den Hostadressen wieder fälschlicherweise Netzwerkmasken angegeben und bei einigen auch noch falsche.
Außerdem hast du mal normale Netzwerkmasken eingegeben und mal inverse, also einen wirren Mischmasch. Eigentlich solltest du ja langsam wissen das ACLs immer nur mit inversen Masken konfiguriert werden! 🧐

Dies musst du in 10 und 50 korrigieren damit die ACLs sauber laufen.
Der Rest ist aber soweit OK und löst deine Anforderung.

Kannst du mir bitte zeigen, wie genau ich die konfigurieren müsste? Stehe komplett auf dem Schlauch…

Stehe komplett auf dem Schlauch…

Immer noch nach so einem langen Training mit Accesslisten?!

Rekapitulieren wir nochmal um dich vom Schlauch zu nehmen....

Accesslisten immer nur inbound mit der Logik permit/deny <source> <destination>
Die Wildcard Netzmasken werden immer invers eingegeben! Das Cisco GUI weisst extra darauf hin: "0s for matching, 1s for no matching". Folglich ist dann eine inverse 24Bit Netzwerkmaske 0.0.0.255, 16Bit 0.0.255.255 usw. und eine inverse 32Bit Hostmaske 0.0.0.0 da sie ja einen einzelnen Host bestimmt und eben kein ganzes Netz.

Mit dem Rüstzeug geht es dann nochmal an eine Beispiel ACL die dir diese Wildcard Logik dann hoffentlich ohne Schlauch sichtbar macht.

Tip:
Wenn du für deine DENY Regel in die 192.168er Netze noch das Logging aktivierst loggt der Switch auch alle bösen Buhfrauen und Buhmänner mit, die versuchen deine Verbotsregeln zu umgehen!