23
Cisco SG300-10: ACE einrichten
Hallo,
ich habe beim o.g. Switch ein Problem mit den einrerichteten ACEs für meine VLANs.In der angehängten Grafik sind die ACEs dargestellt.
Nun mein Problem:
Ich habe bei mir mehrere VLANs (192.168.1.0:24; 192.168.2.0:24; 192.168.3.0:24; 192.168.4.0:24 und 192.168.100.0:24 als Default-VLAN). Als Router ins Internet fungiert die Adresse 192.168.100.100.
Mit den dargestellten ACEs soll erreicht werden, dass das VLAN 192.168.4.0:24 nicht aus dem VLAN 192.168.100.0:24 erreichbar sein soll (Prio: 10).
Alle anderen Zieladressen sollen sich vom Internet-Zugang (192.168.100.100) erreichen lassen (Prio: 20).
Weiterhin sollen die Subnetze 192.168.1.0:24, 192.168.2.0:24 und 192.168.3.0:24 aus den Default-LAN erreichbar sein (Prio 30 bis 50).
Im Binding ist das Verwerfen als Standard-Aktion eingetragen.
Nun ist es aber so, dass ich aus den Subnetz 192.168.2.0:24 ins Internet komme (gemäß Prio 20 bzw. 40), jedoch der Zugriff auf das Internet vom VLAN 192.168.1.0:24 nicht möglich ist. Das sollte aber mit den Prios 20 und 30 auch funktionieren....
Kann mir da mal jemand einen Tipp geben?
Besten dank im Voraus!
Caspi
ich habe beim o.g. Switch ein Problem mit den einrerichteten ACEs für meine VLANs.In der angehängten Grafik sind die ACEs dargestellt.
Nun mein Problem:
Ich habe bei mir mehrere VLANs (192.168.1.0:24; 192.168.2.0:24; 192.168.3.0:24; 192.168.4.0:24 und 192.168.100.0:24 als Default-VLAN). Als Router ins Internet fungiert die Adresse 192.168.100.100.
Mit den dargestellten ACEs soll erreicht werden, dass das VLAN 192.168.4.0:24 nicht aus dem VLAN 192.168.100.0:24 erreichbar sein soll (Prio: 10).
Alle anderen Zieladressen sollen sich vom Internet-Zugang (192.168.100.100) erreichen lassen (Prio: 20).
Weiterhin sollen die Subnetze 192.168.1.0:24, 192.168.2.0:24 und 192.168.3.0:24 aus den Default-LAN erreichbar sein (Prio 30 bis 50).
Im Binding ist das Verwerfen als Standard-Aktion eingetragen.
Nun ist es aber so, dass ich aus den Subnetz 192.168.2.0:24 ins Internet komme (gemäß Prio 20 bzw. 40), jedoch der Zugriff auf das Internet vom VLAN 192.168.1.0:24 nicht möglich ist. Das sollte aber mit den Prios 20 und 30 auch funktionieren....
Kann mir da mal jemand einen Tipp geben?
Besten dank im Voraus!
Caspi
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 263313
Url: https://administrator.de/contentid/263313
Ausgedruckt am: 22.11.2024 um 05:11 Uhr
23 Kommentare
Neuester Kommentar
Hi
ich kenne jetzt den Switch leider nicht aber bei PRIO 20 hast du bei der Platzhaltermaske 0.0.0.0 drinnen. Wenn das einer Wildcardmaske entsprechen soll dann gehört dort 0.0.0.255 rein oder 0.0.255.255 wenn du alle 192.168er Netze freischalten willst. Probier das mal
LG
ich kenne jetzt den Switch leider nicht aber bei PRIO 20 hast du bei der Platzhaltermaske 0.0.0.0 drinnen. Wenn das einer Wildcardmaske entsprechen soll dann gehört dort 0.0.0.255 rein oder 0.0.255.255 wenn du alle 192.168er Netze freischalten willst. Probier das mal
LG
Danke für die Idee. Mein Gedanke dabei war, dass der Traffic, welcher über diese eine IP (192.168.100.100) kommt, entsprechend erlaubt sein sollte, und wenn nur die eine Adresse angesprochen werden soll, ist doch die Maske 0.0.0.0 die richtige, oder? Für die restlichen Quell-IPs sollten die anderen ACEs zuständig sein.
Die Reihenfolge der Regeln ist in der Tat wichtig. Dabei gelten 2 Grundregeln:
Den Regel Namen sollte man auch im verstänflich wählen also sowas wie "Vlan4-Block" oder sowas. Das erleichtert den Umgang damit.
- Das Filtern wirkt nur Inbound also für alle Pakete die eingehend sind in das L3 Interface des Switches
- Es gilt "First match wins !" Das bedeutet das sowie eine Regel greift also positiv ist alle anderen regeln danch NICHT mehr abgearbeitet werden.
Den Regel Namen sollte man auch im verstänflich wählen also sowas wie "Vlan4-Block" oder sowas. Das erleichtert den Umgang damit.
Von den beiden Grundregeln hab ich gelesen und bilde mir ein, diese auch eingehalten zu haben.
Bei Problemen sollte das im Umkehrschluss heißen, dass die Regeln mit der Prio 10 oder 20 angesprochen haben, wenn die Regel mit der Prio 30 (in Voraussicht, diese ist korrekt), nicht anspricht. Oder etwa nicht?
Der Traffic von VLAN 192.168.1.0:24 ist inbound nicht beschränkt und sollte somit keinen Einfluss auf Verbindungen haben...
Bei Problemen sollte das im Umkehrschluss heißen, dass die Regeln mit der Prio 10 oder 20 angesprochen haben, wenn die Regel mit der Prio 30 (in Voraussicht, diese ist korrekt), nicht anspricht. Oder etwa nicht?
Der Traffic von VLAN 192.168.1.0:24 ist inbound nicht beschränkt und sollte somit keinen Einfluss auf Verbindungen haben...
Prio bedeutet ja nur die Reihenfolge. Leider ist das etwas ungewöhnlich aber wenn es so ist das die höchste Prio auch die erste Regel ist und dann absteigend auf kleinere Nummern, dann ist es so.
Wenn 30 greift wird 20 und 10 nicht mehr abgearbeitet.
Wenn 30 greift wird 20 und 10 nicht mehr abgearbeitet.
verstehe ich das richtig, dass die Höchste Priorität zuerst abgearbeitet wird?
Ich dachte, die Abarbeitung beginnt bei der niedrigsten Prio?
Ich dachte, die Abarbeitung beginnt bei der niedrigsten Prio?
Das war jetzt geraten.... 
Ich kenne das SG-300 Handbuch nicht und müsste das nachlesen
Ich kenne das SG-300 Handbuch nicht und müsste das nachlesen
ich hab mich mal schlau gemacht.. die niedrigsten Prioritäten werden zuerst abgearbeitet.
Somit ist die Reihenfolge (s. Screenshot am Anfang erst mal korrekt).
Aber warum erhalte ich dann nicht die korrekte Funktion? Nochmal zur Klärung:
Ich komme aus dem Netz 192.168.2.x ins Internet (Prio 40), aus dem Netz 192.168.11.x jedoch nicht (sollte nach Prio 20 ja auch funktionieren)
Somit ist die Reihenfolge (s. Screenshot am Anfang erst mal korrekt).
Aber warum erhalte ich dann nicht die korrekte Funktion? Nochmal zur Klärung:
Ich komme aus dem Netz 192.168.2.x ins Internet (Prio 40), aus dem Netz 192.168.11.x jedoch nicht (sollte nach Prio 20 ja auch funktionieren)
Regel 40 besagt ja das eine beliebige IP Absender Adresse ins 192.168.2.0er Netz darf und
der Host 192.168.100.100 zu jeder beliebigen IP Adresse darf (Internet)
Die 40er Regel lässt also nichts ins Internet zu sondern lediglich den Zugriff ins 2.oer Netz !
der Host 192.168.100.100 zu jeder beliebigen IP Adresse darf (Internet)
Die 40er Regel lässt also nichts ins Internet zu sondern lediglich den Zugriff ins 2.oer Netz !
das ist mir klar. Diese ACL ist ans VLAN 1 - also das des 100er Netzes gebunden.
Alle anderen VLANs haben erst mal kein ACL bekommen, um diese eine zu testen - und es funktioniert nicht.
Meine Idee war:
- dass keine IP aus dem 100er-Netz ins 4er VLAN darf (Prio 10)
- der Internet-Router 192.168.100.100 überall hin darf (außer eben ins 4er Netz), daher Prio 20
- jede Adresse des 100er-Netzes auf die Subnetze 1, 2 und 3 dürfen (Prio 30 bis 50)
Der Internet-Zugang zum Netz 192.168.11.x sollte vom Router ins 192.168.11.x über Prio 20 laufen.
Aus dem 192.168.11.x ist noch keine ACL definiert, daher auch keine Unterbindung.
So liegt denn der Fehler bei meinem Gedanken?
Alle anderen VLANs haben erst mal kein ACL bekommen, um diese eine zu testen - und es funktioniert nicht.
Meine Idee war:
- dass keine IP aus dem 100er-Netz ins 4er VLAN darf (Prio 10)
- der Internet-Router 192.168.100.100 überall hin darf (außer eben ins 4er Netz), daher Prio 20
- jede Adresse des 100er-Netzes auf die Subnetze 1, 2 und 3 dürfen (Prio 30 bis 50)
Der Internet-Zugang zum Netz 192.168.11.x sollte vom Router ins 192.168.11.x über Prio 20 laufen.
Aus dem 192.168.11.x ist noch keine ACL definiert, daher auch keine Unterbindung.
So liegt denn der Fehler bei meinem Gedanken?
OK wenn diese ACL an das VLAN Interface 100 gebunden ist dann macht aber der Eintrag der Quelladresse "beliebig" ja recht wenig Sinn ?!
Hier ist es doch sinnvoll die Absender IPs auf das VLAN 100, sprich also 192.168.100.0 mit 0.0.0.255 zu limitieren. Wo sollten denn auch von diesem VLAN sonst andere IP Quelladressen herkommen wenn nicht aus dem .100er Netz ?
Vermutlich ist das auch der Fehler der wahrscheinlich einen Side Effect auf die anderen L3 Interfaces hat ?!
Hier ist es doch sinnvoll die Absender IPs auf das VLAN 100, sprich also 192.168.100.0 mit 0.0.0.255 zu limitieren. Wo sollten denn auch von diesem VLAN sonst andere IP Quelladressen herkommen wenn nicht aus dem .100er Netz ?
Vermutlich ist das auch der Fehler der wahrscheinlich einen Side Effect auf die anderen L3 Interfaces hat ?!
ich werde diese Sache mal Testen...
Hoffe, das ist die Lösung!
Hoffe, das ist die Lösung!
Also, ich habe den Tipp umgesetzt und die Einstellungen nach folgender Abbildung ausgeführt:
Das Ergebnis ist jetzt, dass keines der Subnetze mehr ins Internet kommt - die Verbindung innerhalb des Netzwerkes läuft aber.
Erstaunlicherweise bekomme ich aber Antworten bei 'ner ping-Abfrage der Adresse 192.168.100.100 (Internet-Router).
Das Selbe (ebenfalls Antwort auf ping) bekomme ich auch, wenn ich die Anweisung mit der Prio 20 in der ACE lösche und damit eigentlich kein Verkehr mehr vom Router zurück ins VLAN 192.168.2.x gelangen sollte....
ich verstehe es nicht...
Das Ergebnis ist jetzt, dass keines der Subnetze mehr ins Internet kommt - die Verbindung innerhalb des Netzwerkes läuft aber.
Erstaunlicherweise bekomme ich aber Antworten bei 'ner ping-Abfrage der Adresse 192.168.100.100 (Internet-Router).
Das Selbe (ebenfalls Antwort auf ping) bekomme ich auch, wenn ich die Anweisung mit der Prio 20 in der ACE lösche und damit eigentlich kein Verkehr mehr vom Router zurück ins VLAN 192.168.2.x gelangen sollte....
ich verstehe es nicht...
Und ich muss jetzt erstmal das SG-300 Handbuch lesen, denn diese ACLs sind unterschiedlich zu denen vom klassischen Switch IOS bei Cisco 
@ aqui,
hast du denn schon eine Idee?
hast du denn schon eine Idee?
OK...im Grunde sind die ACL und deren Syntax bzw. Verhalten identisch zu IOS ACLs.
Beschrieben ist alles hier ab Seite 479
http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/sf30x_sg30x ...
Dort steht auch ganz klar das die einzelnen Regel Statements der Liste mit der höchsten Priority zuerst abgearbeitet werden.
Die höchste Ziffer kommt also zuerst und dann gehts nach unten was die Reihenfolge betrifft.
Für deine Regel die dann ans 100er VLAN gebunden werden muss bedeutet das dann:
Beschrieben ist alles hier ab Seite 479
http://www.cisco.com/c/dam/en/us/td/docs/switches/lan/csbms/sf30x_sg30x ...
Dort steht auch ganz klar das die einzelnen Regel Statements der Liste mit der höchsten Priority zuerst abgearbeitet werden.
Die höchste Ziffer kommt also zuerst und dann gehts nach unten was die Reihenfolge betrifft.
- Das Filtern wirkt nur Inbound also für alle Pakete die eingehend sind in das L3 Interface des Switches
- Es gilt "First match wins !" Das bedeutet das sowie eine Regel greift also positiv ist alle anderen regeln danch NICHT mehr abgearbeitet werden.
Für deine Regel die dann ans 100er VLAN gebunden werden muss bedeutet das dann:
- dass keine IP aus dem 100er-Netz ins 4er VLAN darf
- deny source 192.168.100.0 0.0.0.255 dest 192.168.4.0 0.0.0.255, Prio 20
- der Internet-Router 192.168.100.100 und jede .100er IP überall hin darf damit auch in die anderen VLANs (außer eben ins 4er Netz)
- permit source 192.168.100.0 0.0.0.255 dest any, Prio 10
- WICHTIG: Diese ACL muss an das VLAN 100 gebunden werden !! Seite 488 "Click Access Control > ACL Binding (VLAN)"
@ aqui, besten Dank erst mal für deine Recherche!
Wenn ich es richtig sehe, war bei meinen ursprünglich erstellten ACEs nur die Prios in der falschen Reihenfolge.
Ich habe gestern Abend die ACLs nach deiner Anleitung neu erstellt (Tausch der Prios), aber leider brachte auch das nicht den gewünschten Erfolg.
hier nochmal kurz meine aktuellen Anpassungen:
- deny source 192.168.100.0 0.0.0.255 dest 192.168.4.0 0.0.0.255, Prio 90
- permit source 192.168.100.100 0.0.0.0 dest any, Prio 80
- permit source 192.168.100.0.0.0.0.255 dest 192.168.1.0 0.0.0.255, Prio 70
- permit source 192.168.100.0.0.0.0.255 dest 192.168.2.0 0.0.0.255, Prio 60
- permit source 192.168.100.0.0.0.0.255 dest 192.168.3.0 0.0.0.255, Prio 50
Und zu guter Letzt die ACL an das VLAN 100 gebunden.
Die Prios 70 bis 50 brauche ich noch, da ich neben den genannten und aufgeführten VLANs noch ein paar andere angelegt habe, welche jedoch keinen Zugriff auf das Internet (192.168.100.100) haben sollen.
Im Ergebnis haben die Anpassungen zur Folge, dass ich weder auf die Switches (im VLAN 192.168.100.x), noch ins Internet komme....
Wenn ich es richtig sehe, war bei meinen ursprünglich erstellten ACEs nur die Prios in der falschen Reihenfolge.
Ich habe gestern Abend die ACLs nach deiner Anleitung neu erstellt (Tausch der Prios), aber leider brachte auch das nicht den gewünschten Erfolg.
hier nochmal kurz meine aktuellen Anpassungen:
- deny source 192.168.100.0 0.0.0.255 dest 192.168.4.0 0.0.0.255, Prio 90
- permit source 192.168.100.100 0.0.0.0 dest any, Prio 80
- permit source 192.168.100.0.0.0.0.255 dest 192.168.1.0 0.0.0.255, Prio 70
- permit source 192.168.100.0.0.0.0.255 dest 192.168.2.0 0.0.0.255, Prio 60
- permit source 192.168.100.0.0.0.0.255 dest 192.168.3.0 0.0.0.255, Prio 50
Und zu guter Letzt die ACL an das VLAN 100 gebunden.
Die Prios 70 bis 50 brauche ich noch, da ich neben den genannten und aufgeführten VLANs noch ein paar andere angelegt habe, welche jedoch keinen Zugriff auf das Internet (192.168.100.100) haben sollen.
Im Ergebnis haben die Anpassungen zur Folge, dass ich weder auf die Switches (im VLAN 192.168.100.x), noch ins Internet komme....
Sorry aber die Regel ist wieder falsch bzw. kann man vereinfachen !!
Du willst ja nur nicht das alles aus dem .100.0er Netz ins .4.0er Netz kommst, oder ?
Durch die fehlende "any" Regel kommt nichts aus dem .100.0er Netz ins Internet ? Soll das so sein ?
Normal würde dann auch ganz einfach folgendes reichen:
deny source 192.168.100.0 0.0.0.255 dest 192.168.4.0 0.0.0.255, Prio 20
permit source 192.168.100.0 0.0.0.255 dest any, Prio 10
Fertig !
Der Host .100.100 ist ja in der Wildcard Maske 0.0.0.255 schon inkludiert und "any" inkludiert alle anderen VLAN IP Netze und das Internet !
Damit sollte es klappen !
permit source 192.168.<vlan>.0 0.0.0.255 dest 192.168.<anderes_vlan>.0 0.0.0.255, Prio 20
--> (die o.a. Regel mehrfach für alle VLANs die du erlauben willst)
deny source 192.168.<vlan>.0 0.0.0.255 dest any, Prio 10
Bedenke das ACLs immer nur inbound wirken also vom Netzwerk Draht (L2) IN das VLAN Interface des Switches !
Du willst ja nur nicht das alles aus dem .100.0er Netz ins .4.0er Netz kommst, oder ?
Durch die fehlende "any" Regel kommt nichts aus dem .100.0er Netz ins Internet ? Soll das so sein ?
Normal würde dann auch ganz einfach folgendes reichen:
deny source 192.168.100.0 0.0.0.255 dest 192.168.4.0 0.0.0.255, Prio 20
permit source 192.168.100.0 0.0.0.255 dest any, Prio 10
Fertig !
Der Host .100.100 ist ja in der Wildcard Maske 0.0.0.255 schon inkludiert und "any" inkludiert alle anderen VLAN IP Netze und das Internet !
Damit sollte es klappen !
noch ein paar andere angelegt habe, welche jedoch keinen Zugriff auf das Internet (192.168.100.100) haben sollen.
Das musst du dann mit entsprechenden separaten ACLs an diesen VLAN Ports definieren ala:permit source 192.168.<vlan>.0 0.0.0.255 dest 192.168.<anderes_vlan>.0 0.0.0.255, Prio 20
--> (die o.a. Regel mehrfach für alle VLANs die du erlauben willst)
deny source 192.168.<vlan>.0 0.0.0.255 dest any, Prio 10
Bedenke das ACLs immer nur inbound wirken also vom Netzwerk Draht (L2) IN das VLAN Interface des Switches !
dann werde ich das nochmal mit deinem Vorschlag probieren.
Eine kurze Frage aber noch zu dem Hinweis inbound:
Bisher habe ich das so verstanden, dass ein Frame beim Eintreffen (inbound) nach den definierten Regeln überprüft und ggf. weitergeleitet bzw. verworfen wird.
Es ist aber schon so, dass nicht nur die source-Angabe in der Regel berücksichtigt sind, sondern auch die dest-Angabe?
Gewissermaßen ist ja die Destination-Angabe der Ausgang (outbound)....
Nur für mein Verständnis....
Danke für die Unterstützung!
Eine kurze Frage aber noch zu dem Hinweis inbound:
Bisher habe ich das so verstanden, dass ein Frame beim Eintreffen (inbound) nach den definierten Regeln überprüft und ggf. weitergeleitet bzw. verworfen wird.
Es ist aber schon so, dass nicht nur die source-Angabe in der Regel berücksichtigt sind, sondern auch die dest-Angabe?
Gewissermaßen ist ja die Destination-Angabe der Ausgang (outbound)....
Nur für mein Verständnis....
Danke für die Unterstützung!
Also ich habe genau die Anweisung von aqui befolgt:
Ergebnis:
ich kommt von meinen Rechnern weder ins Internet (192.168.100.100), noch auf eine andere Adresse im VLAN 192.168.100.x.
Zugriff auf andere VLANs funktioniert.
wenn ich jedoch die Prioritäten tausche (für mich ist Prio 1 irgendwie höher, wie Prio 10...), passiert folgendes:
Ich komme von den anderen VLANs zwar auf die Switches in VLAN 192.168.100.x, jedoch nicht ins Internet (192.168.100.100).
Ergebnis:
ich kommt von meinen Rechnern weder ins Internet (192.168.100.100), noch auf eine andere Adresse im VLAN 192.168.100.x.
Zugriff auf andere VLANs funktioniert.
wenn ich jedoch die Prioritäten tausche (für mich ist Prio 1 irgendwie höher, wie Prio 10...), passiert folgendes:
Ich komme von den anderen VLANs zwar auf die Switches in VLAN 192.168.100.x, jedoch nicht ins Internet (192.168.100.100).
Es ist aber schon so, dass nicht nur die source-Angabe in der Regel berücksichtigt sind, sondern auch die dest-Angabe?
Ja, das ist richtig aber die Prüfung geschieht eben nur inbound nicht outbound also wenn der Frame den Switch wieder verlässt auf dem Interface.Da ist irgendwas faul an der Logik !
Hast du die ACL auch wirklich auf das VLAN gebunden und nicht an einen Port usw. ??
ja, ich habe die ACL ans VLAN 1 (192.168.100.x) gebunden.
Daher sollte es auch keinen Unterscheid machen, dass die Rechner nicht direkt an den Ports des Switches hängen, sondern über einen Trunk-Port an einen L-Switch.
Bin ratlos
Daher sollte es auch keinen Unterscheid machen, dass die Rechner nicht direkt an den Ports des Switches hängen, sondern über einen Trunk-Port an einen L-Switch.
Bin ratlos
Ja, das ist richtig. Mach einen Case bei Cisco auf oder ruf mal die SG Hotline an und klär das ?
Vermutlich ist die ACL Logik mit dem Binding an die ACL eine die nicht so im Handbuch steht.
Vermutlich ist die ACL Logik mit dem Binding an die ACL eine die nicht so im Handbuch steht.
