Cisco SG550: ACL blockiert trotz "Permit Any"

Hallo zusammen,

ich habe hier ein (aus meiner Sicht) kurioses Phänomen, das mir Kopfzerbrechen bereitet...

Switch ist ein SG550X-48 mit ein paar wenigen ACLs für noch weniger VLANs.

Folgendes Ausgangsszenario:
- VLAN 20 darf NICHT mit VLAN 100 kommunizieren, bis auf eine Ausnahme (192.168.100.11)
- daher gibt es drei Regeln, die in etwa so aussehen:
"permit 192.168.20.0 -> 192.168.100.11"
"deny 192.168.20.0 -> 192.168.100.0"
"permit 192.168.20.0 -> any"

Das funktionierte bisher auch alles wunderbar ohne irgendwelche Probleme. Jetzt ist es notwendig geworden, dass ich den Zugriff aus VLAN 100 in VLAN 80 einschränken muss. Daher habe ich ein paar Regeln erstellt, diese dem VLAN 100 zugewiesen und plötzlich habe ich aus VLAN 20 keinen Zugriff mehr auf VLAN 100 - obwohl die neuen Regeln rein gar nichts mit VLAN 20 zu tun haben...

Ich habe diverse Variationen ausprobiert. Ich habe sogar schon alle Regeln gelöscht und nur eine "permit any -> any" stehen lassen. Sobald ich irgendeine ACL dem VLAN 100 zuweise, wird der Datenverkehr von VLAN 20 zu VLAN 100 blockiert.

Wie kann das sein? Übersehe ich hier irgendetwas?

Danke im Voraus für eure Ratschläge!

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

Content-ID: 642056

Url: https://administrator.de/forum/cisco-sg550-acl-blockiert-trotz-permit-any-642056.html

Ausgedruckt am: 23.12.2024 um 15:12 Uhr

19 Kommentare

Neuester Kommentar

Dann hast du wohl mit der ACL im VLAN 100 nicht bedacht das du den Traffic 192.168.100.11 --> 192.168.20.0 ausnehmen musst und so die Rückroute vom .11er Host ins 20er Netz gleich mitgekillt ?!
Ohne mal dein .100er Regelwerk zu kennen bleibt uns aber auch nur freies Raten mit der Kristallkugel.

Das kann ich (leider) ausschließen. Ich habe aktuell nur eine einzige Regel stehen lassen: "permit any -> any"... Und trotzdem wird der Traffic von VLAN 20 zu VLAN 100 blockiert.

Und trotzdem wird der Traffic von VLAN 20 zu VLAN 100 blockiert.

Das ist ja auch gewollt wenn du am VLAN 20 "deny 192.168.20.0 -> 192.168.100.0" sagst ! Sämtlicher Traffic (und das inkludiert auch Rücktraffic !) von VLAN 100 Hostadressen, außer .11, bleiben an dieser Regel hängen.
Aus VLAN 100 kann also einzig nur der Host .100.11 ins 20er VLAN, alles andere ist ja durch die ACL am VLAN 20 blockiert.

Sorry, da habe ich mich etwas unglücklich ausgedrückt... Ich meine damit, dass plötzlich der gesamte Traffic blockiert wird, sprich inklusive des eigentlich erlaubten Traffics zum Host 192.168.100.11.

Dann hast du einen Bug entdeckt im Cisco ! Aktuellste Firmware geflasht ?!

was sagt dir denn
sh access-lists
Normalerweise zeigt der doch hinten an wie oft eine ACL gematcht hat
Wenn du einen Dauerping laufen lässt könntest du so ja mal schauen welche ACL greift
Könnte helfen falls man doch was übersehen hat

Ja, ist die aktuellste Firmware: 2.5.5.47

Guter Hinweis, das könnte ich interessehalber mal ausprobieren.

Ein show run mit Auszug der ACLs würde hier auch helfen ohne immer ins Blaue schiessen zu müssen.

Ich habe jetzt mal das ACL-Logging auf beiden Seiten aktiviert, also im VLAN 20 und im VLAN 100. Der ausgehende Traffic im VLAN 20 wird geloggt und das sieht alles gut aus - aber im VLAN 100 scheint nichts anzukommen, gähnende Leere im Log. Egal ob "permit any -> any" oder "deny any -> any"...

Sieht im ersten Moment wie ein Routing-Problem aus. Aber das müsste ja dann generell bestehen und nicht erst, sobald die ACLs dem VLAN 100 zugewiesen sind.

Sieht im ersten Moment wie ein Routing-Problem aus.

Kann es sein das du schlicht und einfach die Switch IP Adresse vergessen hast zu konfigurieren im VLAN 100 ??!
Wie gesagt ein show run der aktuellen Switch Konfig in Code Tags hier wäre hilfreich für alle Beteiligten um nicht immer raten und ins Blaue schiessen zu müssen.

Es gibt ja aktuell nur eine einzige Regel im VLAN 100, die das Scheunentor ganz weit öffnet: "permit any -> any"

Es könnte auch sein dass du in deiner ACL einen Fehler hast
Dein permit würde nicht greifen und dadurch greift das implezierte deny any any das am Schluss der ACL steht automatisch
aber wie @aqui schon sagte ohne Auszug deiner running config ist dass alles raten im Nebel

Übrigens die implezierten deny any any werden nicht bei sh access-lits in den matches hochgezählt dass lässt mich vermuten das es auch nicht im log auftauchen würde

Es könnte auch sein dass du in deiner ACL einen Fehler hast

Dazu müsste man aber einmal die aktuelle ACL kennen was ja bis dato nicht der Fall ist.

Anbei der relevante Part der Config:

ip access-list extended vlan_twenty
permit ip 192.168.20.0 0.0.0.255 192.168.100.11 0.0.0.0 ace-priority 10
deny ip 192.168.20.0 0.0.0.255 192.168.100.0 0.0.0.255 ace-priority 20
exit
ip access-list extended vlan_onehundred
permit ip any any ace-priority 10
exit
!
interface vlan 20
 name twenty
 ip address 192.168.20.1 255.255.255.0 
 service-acl input vlan_twenty default-action permit-any 
!
interface vlan 100
 name onehundred 
 ip address 192.168.100.1 255.255.255.0 
 service-acl input vlan_onehundred default-action permit-any 
!

Soweit ist das OK.
Gut, die VLAN 100 Regel ist etwas unsinnig wenn die Default Action eh permit-any ist, dann könnte man das "Scheunentor" Regelwerk an VLAN 100 auch komplett entfernen. Das wäre nochmal einen Test wert.
Die betreffenden Endgeräte haben auch wirklich als Default Gateways jeweils die .20.1 und die .100.1 definiert ?
Ansonsten hast du wohl wirklich einen Bug gefunden.

Interessant wäre dann nochmal mit dem Wireshark rauszufinden WO genau die Pakete hängenbleiben. An VLAN 20 oder VLAN 100.

Zitat von @aqui:

Gut, die VLAN 100 Regel ist etwas unsinnig wenn die Default Action eh permit-any ist, dann könnte man das "Scheunentor" Regelwerk an VLAN 100 auch komplett entfernen. Das wäre nochmal einen Test wert.

Da gebe ich dir Recht, die ist tatsächlich etwas sinnfrei.

Aber zum Testen hatte ich die jetzt einfach mal stehen lassen. Ursprünglich wollte ich dort ja ein paar sinnvolle Regeln hinterlegen, aber das kann ich jetzt leider vergessen.

An dieser Stelle Danke für eure Einschätzungen und Hilfestellungen! Ich werde morgen mal Wireshark anwerfen und ggfs. Cisco kontaktieren...