10
Zugriffe in Cisco SG250-08 über ACL ACE einschränken
Hallo,
nachdem nun seit einigen Wochen mein Netzwerk stabik arbeitet (danke auch an aqui), möchte ich nun die Zugriffe via ACL/ACE weiter einschränken. Mein Netzwerk ist wie folgt aufgebaut:
FB 7490 als Router, SG250-08 als L3-Switch, PI als DHCP/DNS-Server.
VLAN 1 – Default
VLAN 100 – Privat
VLAN 120 – leer
VLAN 140 – Drucker
VLAN 160 – IOT
VLAN 180 – Cloud-Dienste
VLAN 200 – GAST
DHCP/DNS 1 in VLAN 1
DNS 2 in VLAN 180
Geräte in VLAN 200 sollen Zugriff auf VLAN 140, Zugriff auf die DNS/DHCP-Service und Internetzugriff haben.
Der Zugriff aus den diversen VLANs ins VLAN 200 soll verboten sein.
Zu einem späteren Zeitpunkt möchte ich die Zugriffe weiter einschränken (z.B. IOT-VLAN soll keinen Zugriff auf das Privat-VLAN erhalten). Dies muss ich aber noch genauer definieren.
Nun zu meinen Fragen:
1. Sollen alle Regeln in einer ACL-Tabelle definiert sein oder ist es besser mehrere ACL-Tabellen zu definieren.
2. Wie definiere ich am besten die Regeln für die oben genannten Einschränkungen für das VLAN 200?
Viele Grüße
Jürgen
nachdem nun seit einigen Wochen mein Netzwerk stabik arbeitet (danke auch an aqui), möchte ich nun die Zugriffe via ACL/ACE weiter einschränken. Mein Netzwerk ist wie folgt aufgebaut:
FB 7490 als Router, SG250-08 als L3-Switch, PI als DHCP/DNS-Server.
VLAN 1 – Default
VLAN 100 – Privat
VLAN 120 – leer
VLAN 140 – Drucker
VLAN 160 – IOT
VLAN 180 – Cloud-Dienste
VLAN 200 – GAST
DHCP/DNS 1 in VLAN 1
DNS 2 in VLAN 180
Geräte in VLAN 200 sollen Zugriff auf VLAN 140, Zugriff auf die DNS/DHCP-Service und Internetzugriff haben.
Der Zugriff aus den diversen VLANs ins VLAN 200 soll verboten sein.
Zu einem späteren Zeitpunkt möchte ich die Zugriffe weiter einschränken (z.B. IOT-VLAN soll keinen Zugriff auf das Privat-VLAN erhalten). Dies muss ich aber noch genauer definieren.
Nun zu meinen Fragen:
1. Sollen alle Regeln in einer ACL-Tabelle definiert sein oder ist es besser mehrere ACL-Tabellen zu definieren.
2. Wie definiere ich am besten die Regeln für die oben genannten Einschränkungen für das VLAN 200?
Viele Grüße
Jürgen
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: 665369
Url: https://administrator.de/contentid/665369
Ausgedruckt am: 22.11.2024 um 01:11 Uhr
10 Kommentare
Neuester Kommentar
WIE du das organisierst ist erst mal ne Frage des Geschmacks... ich würde aber die Regeln pro VLAN als ACL definieren und die dann entsprechend zuweisen bzw. eine eigene Regelkette definieren für den Shell-Zugriff. So kannst du das später am leichtesten pflegen...
Hallo,
ich habe nun für das GAST-VLAN ein ACL und folgende ACEs definiert:
Allerdings habe ich damit noch keinen Internet-Zugriff. Ich habe schon diverse Möglichkeiten getestet, aber nichts funktioniert. Wie muss dieser korrekt lauten?
VG
Jürgen
ich habe nun für das GAST-VLAN ein ACL und folgende ACEs definiert:
Allerdings habe ich damit noch keinen Internet-Zugriff. Ich habe schon diverse Möglichkeiten getestet, aber nichts funktioniert. Wie muss dieser korrekt lauten?
VG
Jürgen
3 wichtige Grundregeln die für eine ACL gelten solltest du immer im Hinterkopf haben:
Das im Hinterkopf kann man sich jetzt mal deine Regel am Gast WLAN genauer ansehen:
1. Eintrag:
Erlaubt generell den Traffic mit irgendeiner Absender IP (Source any) mit irgendeiner Maske in das .140.0er Netz. Sprich alle Gäste haben freien Zugriff ins 140er VLAN.
Außerdem nutzt du eine völlig falsche Wildcard mask. Du hast diese mit der Subnetzmaske verwechselt. Logisch das das in die Hose geht. Du solltest dazu dringend mal ins Handbuch des 250ers sehen !!
Das wirft 2 Fragen auf:
Source: 192.168.200.0 Wildcard: 0.0.0.255, Destination: 192.168.14.0 Wildcard: 0.0.0.255
2. Eintrag:
Hier darf wieder jegliche Absender IP (Warum wenn da nur Gäste senden können ??) auf einen Host .70.250 mit den UDP Ports 67-68 (DHCP)
Falsch sind folgende Punkte:
Hier darf wieder jegliche Absender IP (Warum wenn da nur Gäste senden können ??) auf 2 Hostadressen .70.250 und .180.50
Falsch sind folgende Punkte:
Du kannst jetzt selber sehen was du da am Gastnetz verzapft hast und wieviel Sinn dein Regelwerk macht. Durch die völlig falsche Wildcard Mask wird eh gar nichts klappen. Was außerdem fehlt ist eine Regel am Schluß die den Gästen den Internet Zugang erlaubt. Die fehlt komplett !!
Logisch also das man aus dem Gastnetz niemals ins Internet gelangt ! Leuchtet sicher auch dir ein wenn du dein Regelwerk noch einmal genau Revue passieren lässt. Denk also immer nach wie IP Pakete aussehen. Sieh dir das immer selber mit einem Wireshark mal live an !!
Richtig wäre also
(DHCP erlauben)
Prio1: PERMIT, Source: any Wmask: any, Dest: any Wmask: any, SourceP: any DestP: 67-68
(DNS erlauben)
Prio2: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: <fb_ip> Wmask: 0.0.0.0, SourceP: any DestP: UDP Domain
Prio3: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: <fb_ip> Wmask: 0.0.0.0, SourceP: any DestP: TCP Domain
(Drucker erlauben)
Prio4: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: 192.168.140.0 Wmask: 0.0.0.255, SourceP: any DestP: any
(Zugriff in alle anderen VLANs verbieten)
Prio5: DENY, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: 192.168.0.0 Wmask: 0.0.255.255, SourceP: any DestP: any
(Gäste ins Internet erlauben)
Prio6: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: any Wmask: any, SourceP: any DestP: any
(Das Verbieten von anderen VLANs in Regel 5 geht davon aus das deine anderen VLANs alle im Bereich 192.168.x.y liegen !)
So wird ein ACL Schuh draus !
- Regeln gelten immer nur inbound, sprich also VOM Netzwerk Draht IN das VLAN Interface HINEIN
- Es gilt: "First match wins !" Bedeutet wenn es einen positiven Hit im Regelwerk gibt wird der Rest NICHT mehr abgearbeitet. Reihenfolge zählt also deshalb die "Prio" Settings in der Regel
- Am Ende gilt ein explizites "DENY any any"
Das im Hinterkopf kann man sich jetzt mal deine Regel am Gast WLAN genauer ansehen:
1. Eintrag:
Erlaubt generell den Traffic mit irgendeiner Absender IP (Source any) mit irgendeiner Maske in das .140.0er Netz. Sprich alle Gäste haben freien Zugriff ins 140er VLAN.
Außerdem nutzt du eine völlig falsche Wildcard mask. Du hast diese mit der Subnetzmaske verwechselt. Logisch das das in die Hose geht. Du solltest dazu dringend mal ins Handbuch des 250ers sehen !!
Das wirft 2 Fragen auf:
- Warum Absender von jeglicher IP obwohl es hier ausschliesslich nur Gäste mit einer .200.x IP geben soll ?
Source: 192.168.200.0 Wildcard: 0.0.0.255, Destination: 192.168.14.0 Wildcard: 0.0.0.255
2. Eintrag:
Hier darf wieder jegliche Absender IP (Warum wenn da nur Gäste senden können ??) auf einen Host .70.250 mit den UDP Ports 67-68 (DHCP)
Falsch sind folgende Punkte:
- Wieder Wildcard Mask falsch !
- DHCP basiert auf Broadcasts also 255.255.255.255 in der Destination IP. Erlauben auf die .70.250 ist also sinnfrei
- Absender Ports sind niemals die Application Ports, die sind immer Random. Pakete mit Absenderport 67 oder 68 wird es nie geben. Regel doppelt sinnfrei
Hier darf wieder jegliche Absender IP (Warum wenn da nur Gäste senden können ??) auf 2 Hostadressen .70.250 und .180.50
Falsch sind folgende Punkte:
- Wieder Wildcard Mask falsch !
- Absender Port any und TCP/UDP 53 stimmt diesmal aber warum sind 2 DNS Hosts eingetragen ?? Es gibt doch normal nur einen einzigen und das ist die FritzBox IP
Du kannst jetzt selber sehen was du da am Gastnetz verzapft hast und wieviel Sinn dein Regelwerk macht. Durch die völlig falsche Wildcard Mask wird eh gar nichts klappen. Was außerdem fehlt ist eine Regel am Schluß die den Gästen den Internet Zugang erlaubt. Die fehlt komplett !!
Logisch also das man aus dem Gastnetz niemals ins Internet gelangt ! Leuchtet sicher auch dir ein wenn du dein Regelwerk noch einmal genau Revue passieren lässt. Denk also immer nach wie IP Pakete aussehen. Sieh dir das immer selber mit einem Wireshark mal live an !!
Richtig wäre also
(DHCP erlauben)
Prio1: PERMIT, Source: any Wmask: any, Dest: any Wmask: any, SourceP: any DestP: 67-68
(DNS erlauben)
Prio2: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: <fb_ip> Wmask: 0.0.0.0, SourceP: any DestP: UDP Domain
Prio3: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: <fb_ip> Wmask: 0.0.0.0, SourceP: any DestP: TCP Domain
(Drucker erlauben)
Prio4: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: 192.168.140.0 Wmask: 0.0.0.255, SourceP: any DestP: any
(Zugriff in alle anderen VLANs verbieten)
Prio5: DENY, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: 192.168.0.0 Wmask: 0.0.255.255, SourceP: any DestP: any
(Gäste ins Internet erlauben)
Prio6: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: any Wmask: any, SourceP: any DestP: any
(Das Verbieten von anderen VLANs in Regel 5 geht davon aus das deine anderen VLANs alle im Bereich 192.168.x.y liegen !)
So wird ein ACL Schuh draus !
Hallo aqui,
vielen Dank für Deine ausführliche Beschreibung. Jetzt vestehe ich auch die ein oder andere Beschreibung aus der Doku
Ich habe die Source-Adresse zum Testen erst einmal "global" für alles gesetzt. Ich gehe davon aus, dass durch die Zuordnung zum VLAN 200 die Regel dann eh nur für diesen Adressbereich gültig ist. Ist das korrekt oder liege ich hier auch falsch?
Den Rest werde ich die nächsten Tage testen. Deny hatte ich schon per Default gesetzt.
Die FB ist nicht der DNS-Server. Ich habe zwei DNS-Server über zwei PI-HOLE definiert, wobei einer auch DHCP-Server ist. Dann müsste es doch so lauten oder ?
(DHCP erlauben)
Prio1: PERMIT, Source: any Wmask: any, Dest: <DHCP-Server-IP?> Wmask: 0.0.0.0, SourceP: any DestP: 67-68
(DNS erlauben)
Prio2: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: <DNS-Server-IP> Wmask: 0.0.0.0, SourceP: any DestP: UDP Domain
Prio3: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: <DNS-Server-IP> Wmask: 0.0.0.0, SourceP: any DestP: TCP Domain
VG
Jürgen
vielen Dank für Deine ausführliche Beschreibung. Jetzt vestehe ich auch die ein oder andere Beschreibung aus der Doku
Ich habe die Source-Adresse zum Testen erst einmal "global" für alles gesetzt. Ich gehe davon aus, dass durch die Zuordnung zum VLAN 200 die Regel dann eh nur für diesen Adressbereich gültig ist. Ist das korrekt oder liege ich hier auch falsch?
Den Rest werde ich die nächsten Tage testen. Deny hatte ich schon per Default gesetzt.
Die FB ist nicht der DNS-Server. Ich habe zwei DNS-Server über zwei PI-HOLE definiert, wobei einer auch DHCP-Server ist. Dann müsste es doch so lauten oder ?
(DHCP erlauben)
Prio1: PERMIT, Source: any Wmask: any, Dest: <DHCP-Server-IP?> Wmask: 0.0.0.0, SourceP: any DestP: 67-68
(DNS erlauben)
Prio2: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: <DNS-Server-IP> Wmask: 0.0.0.0, SourceP: any DestP: UDP Domain
Prio3: PERMIT, Source: 192.168.200.0 Wmask: 0.0.0.255, Dest: <DNS-Server-IP> Wmask: 0.0.0.0, SourceP: any DestP: TCP Domain
VG
Jürgen
dass durch die Zuordnung zum VLAN 200 die Regel dann eh nur für diesen Adressbereich gültig ist.
Nein, das ist Unsinn ! Die Regel verhält sich immer so wie die Regel definiert ist. Hellsehen kann das Regelwerk nicht. Steckt sich also jemand mit einer 172.16.x.y oder anderen Adresse in dein Gastnetz lässt ihn diese laxe Regel passieren !Ich habe zwei DNS-Server über zwei PI-HOLE definiert
Ahh, ok das war nicht bekannt.Übrigens....schon mal Adguard probiert ??
https://github.com/AdguardTeam/AdGuardHome
https://www.heise.de/select/ct/2021/7/2101113595336903136
Das Bessere ist immer Feind des Guten. Adguard ist erheblich besser und hat den PiHole mittlerweile überholt. DoT oder DoH Abfragen schon alles inkludiert. Kann man nur den Wechsel empfehlen ! Wenn du also eine SD Flash Karte über hast unbedingt ausprobieren !
Dann müsste es doch so lauten oder ?
Jepp, das ist richtig. DHCP Relay dann nicht vergessen am 250er Switch zu aktivieren ansonsten gehen die DHCP Requests nicht über einen Router !Den Rest werde ich die nächsten Tage testen.
Wir sind gespannt... 
Aufgrund dieser Info CISCO-Einstellungen
Wenn der Datenverkehr mit einer DHCP-Anfrage in Zusammenhang steht und diese nicht explizit erlaubt ist, wird der Datenverkehr verworfen, da bei der Betrachtung der DHCP-Anfrage in IP die Quelladresse s=0.0.0.0 (Ethernet1/0), d=255.255.255.255, len 604, rcvd 2 UDP src=668, dst = 67. Beachten Sie, dass die Quell-IP-Adresse 0.0.0.0 und die Zieladresse 255.255.255 lautet. Der Quell-Port ist 68 und das Ziel 67. Daher sollten Sie diese Art von Datenverkehr in Ihrer Zugriffsliste zulassen, da der Datenverkehr aufgrund einer impliziten Ablehnung am Ende der Anweisung blockiert wird.
muss die DHCP-Freigabe wie folgt definiert werden:
Prio1: PERMIT, Source: 0.0.0.0 Wmask: 0.0.0.255, Dest: 255.255.255.255 Wmask: 0.0.0.255, SourceP: 68 DestP: 67
Ansonsten habe ich die Source-Adresse brav auf 192.168.200.0 geändert
So hat es bei mir funktioniert
Vielen Dank für Deine sehr hilfreichen Tipps. Kaum hat man einen Tipp (pi-Hole) verstanden, kommst Du mit dem nächsten um die Ecke Auch dieses werde ich die Tage mal testen.
Viele Grüße
Jürgen
Wenn der Datenverkehr mit einer DHCP-Anfrage in Zusammenhang steht und diese nicht explizit erlaubt ist, wird der Datenverkehr verworfen, da bei der Betrachtung der DHCP-Anfrage in IP die Quelladresse s=0.0.0.0 (Ethernet1/0), d=255.255.255.255, len 604, rcvd 2 UDP src=668, dst = 67. Beachten Sie, dass die Quell-IP-Adresse 0.0.0.0 und die Zieladresse 255.255.255 lautet. Der Quell-Port ist 68 und das Ziel 67. Daher sollten Sie diese Art von Datenverkehr in Ihrer Zugriffsliste zulassen, da der Datenverkehr aufgrund einer impliziten Ablehnung am Ende der Anweisung blockiert wird.
muss die DHCP-Freigabe wie folgt definiert werden:
Prio1: PERMIT, Source: 0.0.0.0 Wmask: 0.0.0.255, Dest: 255.255.255.255 Wmask: 0.0.0.255, SourceP: 68 DestP: 67
Ansonsten habe ich die Source-Adresse brav auf 192.168.200.0 geändert
So hat es bei mir funktioniert
Vielen Dank für Deine sehr hilfreichen Tipps. Kaum hat man einen Tipp (pi-Hole) verstanden, kommst Du mit dem nächsten um die Ecke
Auch dieses werde ich die Tage mal testen.Viele Grüße
Jürgen
So hat es bei mir funktioniert
Glückwunsch, alles richtig gemacht ! 👏Bleibt ja dann nur noch:
Wie kann ich einen Beitrag als gelöst markieren?
Hallo aqui,
jatzt habe ich doch noch eine Frage:
Ist es empfehlenswert, wenn ich eine "globale" ACL-Tabelle für den DHCP/DNS-Zugriff defininiere oder sollte die doch besser per VLAN-ACL-Tabelle erfolgen?
Ich habe jetzt mal eine "globale" ACL-Tabelle definiert und dort alle IPs aus meinem Netzbereich (192.168.0.0) für die DHCP/DNS-Zugriffe auf die entsprechenden Geräte zugelassen.
Wie ist es mit der Prio bei der Definition mehrerer ACL-Tabellen, wenn ich mehrere ACL-Tabellen einem VLAN zuordne?
Bsp.:
ACL-1, Regel 1 - Prio 1, Regel 2 - Prio 2
ACL-2, Regel 1 - Prio 1, Regel 2 - Prio 2
Wenn ich nun ACL-2 zuerst dem VLAN100 zuordne und dann ACL-1, müssten doch die Regeln aus ACL-2 zuerst ziehen?
Die Frage ist nonsens, da es technisch nicht möglich ist mehrere ACL-Tabellen zuzuweisen
.
Ich habe immer wieder das Problem, dass bei der Pflege der ACE-Regeln im Web-Frontend, die Meldung erscheint "Entry already exists." obwohl aus meiner Sicht diese Regel (in der dazugehörigen ACL-Tabelle) nicht vorhanden ist. Wenn ich dann die Regel "globaler" definiere, funktioniert es meistens. Nachträglich kann ich dann die Einstellungen anpassen. Manchmal ist der Eintrag aber auch einfach weg. Nach ein paar Minuten kann ich dann den Eintrag hinzufügen.
Was mache ich hier falsch?
und noch eine Frage
Kann ich durch die Regel
Prio100: DENY, Source: 192.168.0.0 Wmask: 0.0.255.255, Dest: 192.168.200.0 Wmask: 0.0.0.255, SourceP: any DestP: any
den Zugriff auf dieses VLAN verhindern und macht das Sinn? Das gilt dann auch für andere VLANs.
Viele Grüße
Jürgen
jatzt habe ich doch noch eine Frage:
Ist es empfehlenswert, wenn ich eine "globale" ACL-Tabelle für den DHCP/DNS-Zugriff defininiere oder sollte die doch besser per VLAN-ACL-Tabelle erfolgen?
Ich habe jetzt mal eine "globale" ACL-Tabelle definiert und dort alle IPs aus meinem Netzbereich (192.168.0.0) für die DHCP/DNS-Zugriffe auf die entsprechenden Geräte zugelassen.
Wie ist es mit der Prio bei der Definition mehrerer ACL-Tabellen, wenn ich mehrere ACL-Tabellen einem VLAN zuordne?
Bsp.:
ACL-1, Regel 1 - Prio 1, Regel 2 - Prio 2
ACL-2, Regel 1 - Prio 1, Regel 2 - Prio 2
Wenn ich nun ACL-2 zuerst dem VLAN100 zuordne und dann ACL-1, müssten doch die Regeln aus ACL-2 zuerst ziehen?
Die Frage ist nonsens, da es technisch nicht möglich ist mehrere ACL-Tabellen zuzuweisen
.Ich habe immer wieder das Problem, dass bei der Pflege der ACE-Regeln im Web-Frontend, die Meldung erscheint "Entry already exists." obwohl aus meiner Sicht diese Regel (in der dazugehörigen ACL-Tabelle) nicht vorhanden ist. Wenn ich dann die Regel "globaler" definiere, funktioniert es meistens. Nachträglich kann ich dann die Einstellungen anpassen. Manchmal ist der Eintrag aber auch einfach weg. Nach ein paar Minuten kann ich dann den Eintrag hinzufügen.
Was mache ich hier falsch?
und noch eine Frage
Kann ich durch die Regel
Prio100: DENY, Source: 192.168.0.0 Wmask: 0.0.255.255, Dest: 192.168.200.0 Wmask: 0.0.0.255, SourceP: any DestP: any
den Zugriff auf dieses VLAN verhindern und macht das Sinn? Das gilt dann auch für andere VLANs.
Viele Grüße
Jürgen
Die Frage ist dann auf welches Interface eine "globale" ACL wirkt bzw. wie der Switch diese intern anwendet ??
Auf einem Layer 3 Switch sind die ACLs in der Regel ja immer Interface bezogen. Gut wenn eine "globale" ACL quasi als "Schrotschuss" für alle VLAN L3 Interface gilt kann man das sicher so machen wenn es sich um Regeln hält die für alle IP Interfaces gelten wie DHCP. Wobei das Interface an dem der DHCP selber hängt wieder nicht betroffen ist, denn der muss natürlich keinerlei Broadcasts weiterleiten. Braucht also diese Regel nicht und darf auch kein DHCP Relay definiert haben. Völlig gleiche Regeln für alle gibts also nicht wirklich...
Die Regel generell bewirkt das ALLES was aus dem Interface Segment kommt und eine Absender IP von 192.168.x.y hat und als Ziel IP eine 192.168.200.x IP geblockt wird.
Das bewirkt dann das KEINERLEI Traffic mit 192.168er IPs an dem Interface mehr durchkommt. Daraus folgt wiederum das das Interface dann eine IP aus einem der anderen RFC 1918 Netzen 172.16.0.0/12er oder 10.0.0.0/8er haben muss um überhaupt durchzukommen.
Wie gesagt...die Frage ist sinnfrei wenn man das Interface nicht kennt an dem diese ACL wirkt und was du im Endeffekt damit bezwecken willst.
Ein Zugangspolicy überlegt man sich erst in Ruhe und bringt diese zu Papier um sie dann später umzusetzen. Regelwerke wild beim Konfigurieren raten ist generell keine gute Idee...!
Auf einem Layer 3 Switch sind die ACLs in der Regel ja immer Interface bezogen. Gut wenn eine "globale" ACL quasi als "Schrotschuss" für alle VLAN L3 Interface gilt kann man das sicher so machen wenn es sich um Regeln hält die für alle IP Interfaces gelten wie DHCP. Wobei das Interface an dem der DHCP selber hängt wieder nicht betroffen ist, denn der muss natürlich keinerlei Broadcasts weiterleiten. Braucht also diese Regel nicht und darf auch kein DHCP Relay definiert haben. Völlig gleiche Regeln für alle gibts also nicht wirklich...
Was mache ich hier falsch?
Klingt etwas komisch. ACL mit "Wartezeit" im GUI klingt etwas exotisch. Vielleicht solltest du besser das CLI dazu verwenden. Ansonsten ähnliche Regeln ggf. vorher immer entfernen und dann die neue Regel setzen.Kann ich durch die Regel den Zugriff auf dieses VLAN verhindern
Sorry, die Frage ist etwas wirr, denn du sagst leider nicht WELCHES deiner zahllosen VLAN Interfaces du meinst ?? Die ACL sind ja immer IP Interface bezogen !!Die Regel generell bewirkt das ALLES was aus dem Interface Segment kommt und eine Absender IP von 192.168.x.y hat und als Ziel IP eine 192.168.200.x IP geblockt wird.
Das bewirkt dann das KEINERLEI Traffic mit 192.168er IPs an dem Interface mehr durchkommt. Daraus folgt wiederum das das Interface dann eine IP aus einem der anderen RFC 1918 Netzen 172.16.0.0/12er oder 10.0.0.0/8er haben muss um überhaupt durchzukommen.
Wie gesagt...die Frage ist sinnfrei wenn man das Interface nicht kennt an dem diese ACL wirkt und was du im Endeffekt damit bezwecken willst.
Ein Zugangspolicy überlegt man sich erst in Ruhe und bringt diese zu Papier um sie dann später umzusetzen. Regelwerke wild beim Konfigurieren raten ist generell keine gute Idee...!
Hallo aqui,
ja nachdem ich länger darüber nachgedacht habe, habe ich auch festgestellt, dass die Idee nicht durchdacht war. Ich baue nun gerade pro VLAN meine Regeln. Das ist doch einfacher als ich dachte.
Das mit den Problemen im Web-Interface hat sich auch wieder gelegt.
Die nächsten Fragen kommen aber bestimmt Vielen Dank für Deine Unterstützung.
Viele Grüße
Jürgen
ja nachdem ich länger darüber nachgedacht habe, habe ich auch festgestellt, dass die Idee nicht durchdacht war. Ich baue nun gerade pro VLAN meine Regeln. Das ist doch einfacher als ich dachte.
Das mit den Problemen im Web-Interface hat sich auch wieder gelegt.
Die nächsten Fragen kommen aber bestimmt
Vielen Dank für Deine Unterstützung.Viele Grüße
Jürgen
