26.04.2022 um 14:06:56 Uhr

3231

Zweite Fritzbox im Subnetz

Hallo,

ich brauche nochmal eure Hilfe.

Mein Vorhaben: WOL-Server im Subnetz installieren.

Ich habe 2 Subnetze verbunden durch einen Cisco Business Switch 250 - der Switch routet zwischen den beiden VLANs (Layer 3)

VLAN 1 = Produktiv-LAN mit Internet-Router (FB 7390), Server und Clients IP-Bereich 192.168.0.x
VLAN10 = Backup-LAN mit einer NAS die zeitgesteuert Pull-Backups von Server und Clients aus dem anderen Subnetz zieht IP-Bereich 192.168.10.x

Funktioniert alles wunderbar - da die NAS nur angeschaltet wird wenn ein Backup gemacht werden muss (Zeitsteuerung) suchte ich nach einer zusätzlichen Möglichkeit die NAS zu starten - per WOL.

Nach allem was ich hier im Forum nun gefunden habe ist WOL von einem ins andere Subnetz über den Cisco 250 schwer realisierbar (fehlender directed Broadcast-Unterstützung) ...korrigiert mich wenn das falsch ist....

Ich habe dann (auch hier im Forum entdeckt) die Idee aufgegriffen, einfach eine alte Fritzbox (FB 7362 SL) ins Subnetz zu hängen und über Weboberfläche der FB ein Magic Packet an die "schlafende" NAS innerhalb des gleichen Subnetz zu versenden.

Hier scheiterte ich aber bis jetzt: Hab der FB eine feste IP verpasst (192.168.10.160) und sie an einem Netzwerkport des Switches (VLAN 10, Interface 192.168.10.254, Access-Mode, untagged) gehängt.

Ping vom Client-PC (VLAN 1) zur FB 7362 SL (VLAN 10) funktioniert nicht
Ping vom Client-PC (VLAN 1) zur NAS (VLAN 10) funktioniert
Ping vom Switch zur FB 7362 SL (VLAN 10) funktioniert
Ping vom Client-PC (VLAN 1) zum Switch funktioniert

Die Fritzbox ist als Internetrouter konfiguriert (nicht als IP-Client) da nur hier die WOL-Funktion in der Weboberfläche verfügbar ist. Was mir auffiel, ist dass man der Fitzbox als Internet-Router nur IP-Adresse und Teilnetzmaske zuweisen kann....jedoch besteht nicht die Möglichkeit ein Gateway einzutragen (im Gegensatz zur IP-Client-Konfiguration). Vielleicht liegt daran? Was mache ich falsch?

Grüße Rainer

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

Content-ID: 2606213085

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

Ausgedruckt am: 22.11.2024 um 07:11 Uhr

46 Kommentare

Neuester Kommentar

Servus Rainer,

um welches NAS System handelt es sich denn?

Wenn deine Backups zeitgesteuert laufen und das NAS dazwischen ausgeschaltet sein soll aktiviere doch einfach auch die Zeitsteuerung die regelt wann sich das NAS ein-/ausschalten soll falls das vorhanden ist. (Wobei mir kein NAS System einfällt dass sowas nicht hat)

Eine Synology Diskstation ...die wird zeitgesteuert nachts angeschaltet - zieht dann das Backup - und schaltet sich danach wieder aus.

Ich suche einfach einen Weg sie per Remote wieder anzuschalten - ggf. mal zwischendrin - da bietet sich WOL ja an

Moin,

im schlimmsten Fall nen kleinen RPi mit Etherwake drauf:
https://www.computerbild.de/artikel/cb-Tipps-PC-Hardware-Raspberry-Pi-Wa ...

Auf den per SSH verbinden und von dort das Paket absenden

Alternativ via Arduino-Board:
https://www.arduino.cc/reference/en/libraries/wakeonlan/

Hab der FB eine feste IP verpasst (192.168.10.160) und sie an einem Netzwerkport des Switches (VLAN 10, Interface 192.168.10.254, Access-Mode, untagged) gehängt.

Welches Default Gateway hast du der FritzBox denn verpasst ?? IP Adresse ist bekanntlich ja nur die halbe Miete. Ohne Gateway wird sie logischerweise unereichbar bleiben aus anderen IP Netzen.
Lies mal etwas über Routing Grundlagen!!

@aqui

Lies mal im letzten Absatz meines Posts...hier kannst du sehen das sich in der Internet-Konfiguration der FB nirgendwo das Gateway eintragen lässt (es sei denn man verwendet DHCP)

Die Fritzbox ist als Internetrouter konfiguriert

Ich verstehe Deinen Aufbau noch nicht. Heißt obiger Satz, die FB 7362 hängt an ihrem WAN-Port am Switch? Von dort dürftest Du die Oberfläche normal nicht erreichen können. Selbst wenn Du die Oberfläche von "außen" freigeben kannst (ich erinnere da dunkel eine Funktion), darf das nicht sein, denn das hieße, Du kämst von VLAN 1 in VLAN 10, was Dein Setup zum Schutz des Backups ja gerade vermeiden soll (Sinn des Aufbaus war ja lt. dem anderen Thread ein geschütztes Pull-Backup).

Wenn das hier funktioniert:

Ping vom Client-PC (VLAN 1) zur NAS (VLAN 10) funktioniert

ist Dein VLAN-Schutz ebenso für die Tonne. Da darf Verkehr im Netz nur von NAS ausgelöst werden können, nicht aus dem VLAN 1 heraus.

Beschreib gern mal, ob und wie Du aus dem VLAN 1 auf die Oberfläche der 7362 SL kommst (kommen willst). Aber: Nur, wenn Dir das gelingt, solltest Du auch einen WOL auslösen können und genau das unterläuft den gewünschten Schutz.

Fazit: Wenn ich nichts falsch verstanden habe ist die Fritzbox-Lösung für diesen Zweck ungeeignet.

die Idee aufgegriffen, einfach eine alte Fritzbox (FB 7362 SL) ins Subnetz zu hängen

Man kann nicht einfach mehrere Forumschnipsel einfach kombinieren, ohne sein eigenes Setup zu verstehen und zu erkennen, ob das passt. Also klar kann man, man macht dann eben ein paar Erfahrungen - und das ist ja gut

Eine Arztpraxis (sorry, da bin ich naturgemäß etwas empfindlich - gilt an sich für jedes Business) verdient aber ein einigermaßen professionelles Setup. Deshalb ist ein Gefrickel mit zwei Fritzboxen jetzt wirklich nicht nötig. Statt des (nur fürs Backup erworbenen (?)) VLAN-Switches hättest Du für kleines Geld einen (z.B. Mikrotik) VLAN-Router erwerben können, mit dem Du bequem WOL in den einzelnen VLANs auslösen kannst. Zugleich würdest Du damit über Netzwerke hinzu lernen (können) und mit der großartigen Transparenz dieser Geräte Überblick im Netzwerk bekommen. Auch der von der KBV-IT-Sicherheitsrichtlinie geforderte (noch nicht zwingende) Einsatz einer Firewall wäre damit gleich abgehakt.

Viele Grüße, commodity

hier kannst du sehen das sich in der Internet-Konfiguration der FB nirgendwo das Gateway eintragen lässt (es sei denn man verwendet DHCP)

Dann solltest du als gestandener Netzwerk Profi aber auch wissen das dann eine Erreichbarkeit aus anderen IP Netzen damit dann technisch unmöglich ist! Wie sollte das auch gehen ohne Gateway Eintrag?!
Zum Rest hat Kollege @commodity oben schon alles gesagt.

Ein kleiner Raspberry Pi Zero für 10 Euro wäre da dann deutlich sinnvoller gewesen. Z.B. hier oder hier.
Alt, aber immer noch lesenswert zu dem Thema:
https://www.heise.de/ct/artikel/Wake-on-WAN-221718.html

Ich verstehe Deinen Aufbau noch nicht. Heißt obiger Satz, die FB 7362 hängt an ihrem WAN-Port am Switch?

Ich hab die FB über einen ihrer LAN-Ports mit dem Switch verbunden. Ich dachte sie wäre dann ein wie die NAS ein Netzwerk-Client mit fester IP, über die ich ich dann WOL-Signale ins Subnetz senden kann.

Das funktioniert offensichtlich im Internet-Router-Modus der FB nicht - es gäbe den IP-Client-Modus (hier wäre auch die Möglichkeit ein Gateway einzutragen)....aber dieser Modus unterstützt die WOL-Funktion nicht.

Somit hast du recht ....die FB ist für dieses Vorhaben nicht geeignet.

da ich eben KEIN gestandener Netzwerk-Profi bin freue ich mich sehr über deine kompetenten Ratschläge (sowie von @aqui)

Das Problem liegt daran das die FB am LAN Port kein Gateway eingetragen hat bzw. das nicht supportet. Damit ist dann logischerweise der Zugang aus anderen IP Netzen auf die FB unmöglich.
Die Lösung ist aber ganz einfach sein sofern die FB das supportet und zwar indem du ihr statische Routen in diese anderen IP Netze einträgst.
Wenn diese Routen am LAN Port greifen (was sie sollten) wird das dein Problem lösen.

Beispiel:
FritzBox ist mit abgeschaltetem DHCP Server am LAN Port im 192.168.1.0 /24er Netz (IP: 192.168.1.1) und das Gateway in dem Netz ist die 192.168.1.254
Zugegriffen werden soll auf die Fritzbox aus den Netzen .2.0 und .3.0
Dann trägst du 2 statische Routen in die FB ein:

Ziel 192.168.2.0, Maske: 255.255.255.0, Gateway: 192.168.1.254
Ziel 192.168.3.0, Maske: 255.255.255.0, Gateway: 192.168.1.254

Das sollte dann ggf. dein Problem lösen.

@aqui

Dem ist nichts hinzuzufügen !!! Funktioniert einwandfrei

Vielen Dank !!!

👍 Works as designed ! 😉

Works as designed !

Wer kann, der kann!

Allerdings: Der Zugriff funktioniert.
Nur leider ist der schöne VLAN-Schutz für das Pull-Backup jetzt futsch, weil die Fritzbox das ja nicht firewallt

Mit diesem Design hätte er auch bei einer Fritzbox und einem Netz bleiben können...

Viele Grüße, commodity

Allerdings: Der Zugriff funktioniert.
Nur leider ist der schöne VLAN-Schutz für das Pull-Backup jetzt futsch, weil die Fritzbox das ja nicht firewallt

Mit diesem Design hätte er auch bei einer Fritzbox und einem Netz bleiben können...

Da hast du natürlich recht!!

Mal zum Grundverständnis: Ist es möglich über den Switch eine Route von der BackupNAS (VLAN10) ins VLAN 1 auf einen Client zu legen ? also von VLAN10 -> nach VLAN1. Damit - wie du schon zurecht gesagt hast - nur Traffic ensteht wenn das Pull-Backup akktiv ist ??? Benötige ich hierfür eine Firewall? Die Syno NAS hat ein Firewall....

Ich bitte um Nachsicht wenn diese Frage hier für all die Profis zu trivial ist...aber ich arbeite mich gerade erst in das Thema ein

Du benötigst dafür keine Route, denn beide VLAN Netze sind ja direkt an deinem Switch dran und damit "kennt" der Switch diese IP Netze ja so das eine Route unsinnig, da überflüssig, wäre.
Du betreibst ja ein Layer 3 VLAN Konzept mit dem routenden Switch. Details dazu findest du hier was dir den IP Traffic Flow im Detail erklärt.
Verständnissproblem Routing mit SG300-28

OK. Dann ist das vorhandene Konzept (Auslagerung einer NAS in ein anderes Subnetz aus Sicherheitsgründen) an sich mit dem routenden Switch ungeeignet - den durch den routenden Switch besteht ja eine Verbindung zwischen beiden Subnetzen....es besteht dann ja eine Situation als wäre nur ein einziges LAN vorhanden

Mir schwebte eine Situation vor, durch die Aufteilung in 2 Subnetze die BackupNAS im anderen Subnetz vor Zugriff zu schützen (also praktisch von VLAN 1 aus nicht auffindbar zu machen).

Man müsste dann praktisch eine Layer-2 Situation herstellen damit die beiden VLANs wriklich getrennt sind - und nur wenn ein Pull-Backup gezogen wird müsste während des Backups die Routing-Funktion des Switches (Layer-3) aktiviert werden. Ist so etwas realisierbar?

den durch den routenden Switch besteht ja eine Verbindung zwischen beiden Subnetzen

Das ist richtig, aber dein routendender Switch gibt dir ja gleichzeitig auch IP Accesslisten als Werkzeug an die Hand um das Zugriffsverhalten entsprechend zu steuern!

"IP Accesslisten" - da hab ich ja mal Lesestoff fürs Wochenende. Danke für deine Geduld

Zitat von @fishrain:
... an sich mit dem routenden Switch ungeeignet - den durch den routenden Switch besteht ja eine Verbindung zwischen beiden Subnetzen

Nein, Verbindung brauchst Du ja immer irgendwie. Routing muss schon sein. Dieses muss nur, wie der geschätzte Kollege @aqui schon ausgeführt hat, durch ACLs gefiltert werden, mit denen nur der Backup-Server ins Netz des zu sichernden Gerätes darf und nicht (wie bislang) umgekehrt.

Ich würde das nicht mit ACLs machen, sondern lieber zentral in einem geeigneten Router verwalten. Ist übersichtlicher, finde ich und das WOL-Thema ist damit auch gelöst. Und zwar ohne Sicherheitslücke. Mit einem Mikrotik bist Du mit (je nach Backup-Umfang) zwischen 50 und 200 EUR dabei. Und einer Menge neuem Lernstoff

Wenn Du statt WOL das NAS zeitgesteuert starten kannst, ist die ACL-Lösung aber sicher ausreichend.

Viele Grüße, commodity

danke @commodity....ich wollte es jetzt erst mal mit dem Switch probieren

@aqui: Ich hab mich mit den ACLs jetzt etwas befasst, jedoch funktioniert mein Vorhaben nocht nicht

VLAN 10 (192.168.10.0 /24) - in welchem sich die Backup-NAS befindet wollte ich vom VLAN 1 komplett abschotten

Hierzu habe ich eine ACL erstellt auf VLAN 10 default deny

damit dürften doch keine Pakete in VLAN 10 kommen !?

in der ACL habe ich jetzt versuchweise eine einzige Regel gestellt welche mir den Zugriff von einem konkreten Client aus VLAN 1 auf die Backup NAS (in VLAN 10) erlaubt

Jedoch funktioniert ping von dem Rechner auf die backupNAS nicht !

Was mache ich falsch?

ACLs greifen immer nur inbound! Also VOM Netzwerk Draht IN das VLAN IP Interface hinein.
Deine ACL ist syntaktisch richtig aber du hast sie ans falsche VLAN Interface gebunden weil du mit der falschen Logik gedacht hast. .0.x vlan1 Traffic (Absender IP) kommt inbound am vlan1 Interface an und nicht vlan10.
Es macht doch auch keinerlei Sinn diesen nicht gewollten Traffic in den Switch zu lassen, ihn damit zu belasten und dann erst outbound zu filtern.
Fazit:
Lege die ACL auf das VLAN 1 Interface von wo aus der Traffic initiiert wird, dann greift deine ACL auch sofort.

Hätte dir an der Logik der ACL aber auch selber sofort auffallen müssen..
Sie filtert Pakete mit der Absender IP 192.168.0.85 (vlan1) auf die Ziel IP 192.168.10.164 (vlan10).
Wie sollen denn am VLAN 10 Interface jemals Absender IPs mit 192.168.0.x ankommen wenn es dort nur Absender IPs 192.168..10.x geben kann??
Deine ACL erlaubt also etwas am VLAN 10 Interface an Traffic was da niemals ist und es gilt am Ende immer ein deny any any so das dann dein Ping verständlicherweise in die Hose geht. Die ACL macht also im Gegensatz zu dir alles richtg!

Works as designed...
Einfache Logik...

Lege die ACL auf das VLAN 1 Interface von wo aus der Traffic initiiert wird, dann greift deine ACL auch sofort.

Das hab ich gestern schon versucht...mit dem (katastrophalen) Ergebnis dass ich mir den (Remote-)Ast, auf dem ich saß abgeschnitten habe (ich habe Zugriff auf das VLAN 1 von extern über VPN auf die Fritzbox) . Das liegt an der Architektur unseres Netzes ...in VLAN1 liegt ja der Internet-Router (gateway 192.168.0.253).

Ich habe dann das ACL-binding an VLAN 1 mit default deny angelegt...danach war erst mal kein Zugriff mehr von extern auf den Switch möglich....aber dann auch vorort war kein Zugriff mehr zwischen den Clients möglich...das war echt fatal...musste den switch resetten und die Backup-Konfiguration neu einspielen.

Wahrscheinlich wäre es besser den Internet-Router aus VLAN 1 rauszunehmen....so wie in dem Layer-3-Schema von dir

Na ja, man sollte sich schon vorher überlegen WAS man mit ACLs macht.

Was auch immer geht wenn man von remote mit ACls arbeitet ist den Reboot des Switches zu starten aber mit einem Timer z.B. 30 Min.
Sägt man sich den Ast ab wartet man halt einfach nur 30 Minuten und der Switch rebootet wieder in die ursprüngliche Konfig und fertisch ist der Zugang wieder da. 😉
So spart man sich die unnötige Frickelei mit dem Resett und Backup.

Ein bisschen intelligent nachdenken hilft da also auch wenn man mit sowas von remote arbeitet!

Wenn das VLAN so heikel ist dann implementierst du die ACL eben auf der VLAN 10 Interface Seite, das geht ja auch:
permit source 192.168.10.164 0.0.0.0 destination 192.168.0.85 0.0.0.0
Das mappst du dann an das VLAN 10 Interface und gut iss.
Ist zwar kosmetisch und netztechnisch nicht elegant weil du den Traffic vom Client erstmal durch den Switch lässt zum Ziel und nur den Return Traffic dann blockierst.
Nicht schön hat aber den gleichen Effekt nur das es dich vor dem Ast absägen an vlan1 schützt.

permit source 192.168.10.164 0.0.0.0 destination 192.168.0.85 0.0.0.0

das funktioniert gut !!! Danke

Nochmal für mich zum Verständnis - mit dieser ACL bleibt (nur) diese Verbindung zwischen dem PC und der NAS in den unterschiedlichen VLANs offen - alle anderen Verbindungen sind geblockt zwischen den beiden VLANs !? Ist praktisch wie eine Portöffnung in einer Firewall. Ping von einem Gerät zum anderen ist möglich - in beide Richtungen.

Das was ich mir vorgestellt habe, nämlich dass die Verbindung nur von VLAN 10 zu VLAN 1 (praktisch eine Einbahnstrasse) und umgekehrt nicht....das geht ja nicht !!? Entweder ist die Verbindung da (und dann natürlich in beide Richtungen) oder halt dann nicht . Das ist für dich wahrscheinlich alles trivial aber ich muss das erst mal verstehen ....

Gibt es eine Möglichkeit diese ACL zeitgesteuert nur kurze Zeit zu aktivieren....also z.B. nur während der 2 Stunden in der Nacht wo das Backup läuft .

permit source 192.168.10.164 0.0.0.0 destination 192.168.0.85 0.0.0.0

Das ist wieder kein Pull-Backup mehr. Nicht das Ziel aus den Augen verlieren

Deine erste ACL-Rule war doch prima, wenn man davon absieht, dass sie im falschen Netz war und Du vor dem default deny noch eine Regel brauchst, die auch den Zugriff von außen (hier: zurück zu Dir) sicher stellt. Wie genau, da kann Kollege @aqui sicher helfen. Du nutzt Fritzbox-VPN, das ist IPsec, da behältst Du ja Deine IP, dann müsstest Du nach meinem Verständnis den IP-Bereich Deines heimischen Netzes freigeben. Kann mich aber irren.

Viele Grüße, commodity

alle anderen Verbindungen sind geblockt zwischen den beiden VLANs !? Ist praktisch wie eine Portöffnung in einer Firewall

Ja. Es gilt ja nach der Regel immer ein impliziertes deny any any. Über die ACL können einzig nur dieser PC und das NAS kommunizieren.
Du kannst das sogar noch weiter einschränken wenn du z.B. nur SMB/CIFS Traffic zu lässt und sonst nix.

aber ich muss das erst mal verstehen ....

Einfach mal einen Wireshark Sniffer auf deinem rechner installieren und einmal den Traffic auf dem Netz belauschen. Das öffnet Horizonte.

Kollege @commodity hat Recht wenn er sagt das die Lösung der ACL am VLAN1 inbound technisch sauberer ist, denn von dort werden die NAS Zugriffe ja initiiert und diesen Traffic will man dann auch nicht im Switch haben.
Um die Gefahr des Ast Absägens zu minimieren kannst du mit dem zeitgesteuerten Reload von oben arbeiten.
Alternativ kannst du die Default Logik der ACL umdrehen und mit permit any any arbeiten als statt einer Whitelist Logik mit einer Blacklist Logik was dann per se erstmal alles durchlässt und du musst explizit verbieten was du nicht willst. Z.B.
deny tcp source 192.168.0.0 0.0.0.255 destination 192.168.10.164 0.0.0.0 eq 445
Verbietet generell den SMB/CIFS Traffic aus dem gesamten VLAN1 auf das NAS lässt alles andere aber passieren.
ACLs kann man über ein Zeit Schedule auch zeitgesteuert implementieren.

eq 445

das vielleicht noch weglassen? Sieht für mich sonst aus, als ob nur SMB verboten wäre.

Viele Grüße, commodity

Nicht das Ziel aus den Augen verlieren

gut dass du mich immer wieder auf den Weg bringst !!!

Wenn ich dich richtig verstanden habe muss die ACL in VLAN 1 implementiert werden damit es wirklich ein Pull-Backup ist

durch die default deny in VLAN 1 kam es zu zwei Problemen:

1. der Remote -Zugang per VPN war versperrt - wenn ich auf der FB als VPN eingeloggt bin erscheint in der Netzwerk-Liste der FB eine "virtuelle IP" 192.168.0.128....falls das immer die gleiche IP ist könnte man ja dem default deny eine regel vorschalten mit permit 192.168.0.128 in VLAN 1

2. das zweite problem nach aktivieren der default deny in VLAN 1 war, dass der switch innerhalb des VLAN 1 keine Pakete mehr weitergeleitet hat, sprich innerhalb von VLAN1 (also ich hatte z.B. von PC1 oder PC2 keinen Zugriff mehr auf den Server - welche innerhalb VLAN 1 alle an verschieden Ports hingen )...wobei das ja eigentlich nicht logisch ist denn die default deny Regel bewirkt doch normalerweise dass kein Verkehr ins VLAN 1 rein- und rausgetragen wird ...bei aktivierter default deny regel müsste doch der traffic innherlab von VLAN 1 flutschen

Alternativ kannst du die Default Logik der ACL umdrehen und mit permit any any arbeiten als statt einer Whitelist Logik mit einer Blacklist Logik was dann per se erstmal alles durchlässt und du musst explizit verbieten was du nicht willst. Z.B.
deny tcp source 192.168.0.0 0.0.0.255 destination 192.168.10.164 0.0.0.0 eq 445
Verbietet generell den SMB/CIFS Traffic aus dem gesamten VLAN1 auf das NAS lässt alles andere aber passieren.

das klingt richtig gut...das werde ich ausprobieren !!!! Danke

ACLs kann man über ein Zeit Schedule auch zeitgesteuert implementieren.

das geht dann aber nur über CLI...über das Webinterface habe ich da keine Eingabemöglichkeit gefunden !?

könnte man ...

ach, klar, ist ja ein client-to-site-VPN. Ob das aber immer die gleiche IP-Adresse ist? Kannst Du sie vielleicht im UI fixieren? Mit "normalen" IP-Adressen geht das in der Fritzbox.

müsste doch ...

Hätte ich als ACL-Ahnungsloser auch gedacht, ist aber nicht so:
"VACLs can provide access control for all packets that are bridged within a VLAN or that are routed into or out of a VLAN or a WAN interface for VACL capture. "
https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2 ...
Musst also auch noch eine Regel für die Netzinterne Kommunikation schaffen.

Sagte ich schon mal, dass das mit einem geeigneten Router...? (schon weg

)

Viele Grüße, commodity

Das Gelbe ist aber derbes Augenpulver!

@aqui:

Wird nach einem Reboot die letzte abgespeicherte "running configuration" geladen ? Also sollte ich meinen Ast absägen ist der switch nicht mehr erreichbar mit der neuen Regel...aber sie wird nicht in die running configuration abgespeichert. Nach dem reboot wird die letzte gespeicherte Konfiguration geladen...und das ist die ohne der fatalen Regel !?

und noch eine Frage zur Priority der Regeln: Die hohen Zahlen werden zuerst abgearbeitet? Also Regel mit Priority 1000 wird als erstes abgearbeitet - Priority 1 wird als vorletztes abgearbeitet - und als letztes kommt dann die default-Regel ?

Das Gelbe ist aber derbes Augenpulver!

War ja auch OT

Vergrößern hilft ganz gut...

Viele Grüße, commodity

@fishrain, ist Kollege @aqui jetzt Dein Handbuch? Wie ich ihn kenne, wird er das beantworten, aber vielleicht magst Du Dir die Antworten selbst erarbeiten? Den Umgang mit dem Handbuch zu können, dient dem Lernfortschritt meist ungemein. Hier handelt es sich ja nicht um technische Probleme, die in dieses Forum gehören, sondern simpelstes RTFM. Und Cisco hat ja nun wirklich vorzügliche Materialien.

Viele Grüße, commodity

Alles klar! Sorry!!!

Danke euch beiden !!! Ihr habt mir wirklich sehr geholfen !!!!

Wenn es dann trotzdem hakt, geht es hier natürlich weiter

Viele Grüße, commodity

Wird nach einem Reboot die letzte abgespeicherte "running configuration" geladen ?

Ja!

aber sie wird nicht in die running configuration abgespeichert.

Das liegt, wie immer, an dir selber! Du solltest natürlich dann nicht den "Save" Button klicken. Wird dir vermutlich so oder so nicht mehr gelingen wenn du die Connectivity verloren hast.

Der Switch bootet dann immer die zuletzt gesicherte Konfig mit dem Reboot...wie immer. Steht, wie der Kollege @commodity oben schon zu Recht gesagt hat, alles auch im Handbuch des Switches. Man muss nur einmal lesen...

Die hohen Zahlen werden zuerst abgearbeitet?

Auch das steht im Handbuch... Nein, es ist genau umgekehrt. Niedrige zuerst und es gilt "First match wins". Nach dem ersten positiven Hit wird der Rest der Regeln nicht mehr abgearbeitet.

Ihr habt mir wirklich sehr geholfen !!!!

Immer gerne...

@aqui:

ich möchte dich (hoffentlich) ein letztes mal um Hilfe bemühen:

Wie von dir vorgeschlagen, habe ich die ACL Default logik umgedreht und auf VLAN 1 permit any any (Blacklist-Logik) implementiert

darüber habe ich folgende ACEs eiongerichtet:

ummittelbar über der default regel habe ich erst mal eine regel (priority 60) eingezogen die jeglichen tarffic zwischen VLAN 1 und 10 blockiert

mit höchster priorität (20) habe ich eine Regel für den VPN-Zugang von extern ( permit virtuelle IP 192.168.0.128) eingestellt

und dazwischen woillte ich jetzt versuchsweise mal die Verbindung eines Clients aus VLAN1 mit der NAS in VLAN10 zeitgesteuert erlauben mit Regel priorität 40

Und hier tritt folgendes Problem auf: Die ACE lässt sich mit time range ja problemlos erstellen.
Wenn ich nach Erstellen der ACEs nun diese ACL mit der default logik permit any any an das VLAN1-Interface anbinden will kommt folgende Fehlermeldung:

Im Handbuch steht dass time range auf ACLs angewendet werden kann - evtl. doch nicht ??

darüber habe ich folgende ACEs eiongerichtet:

Wenn deine default Logik "permit any any" ist warum hast du dann noch Permit Statements im Regelwerk der ACL ? Ist ja eigentlich dann überflüssig.

mit höchster priorität (20) habe ich eine Regel für den VPN-Zugang von extern

Wie bereits gesagt: Völlig überflüssig wenn als Grundregel gilt das generell ALLES erlaubt ist was nicht explizit verboten ist. Wo bleibt hier dein logisches Denken...?

versuchsweise mal die Verbindung eines Clients aus VLAN1 mit der NAS in VLAN10 zeitgesteuert erlauben

Wozu, wenn so oder so alles erlaubt ist was nicht explizit verboten ist? Gleiches Spiel wie oben...
Warum die zeitgesteuerte ACL nicht auf ein VLAN Interface angewendet werden kann erschliesst sich mit aktuell auch nicht. Welches Modell ist das ??
Möglich das das Default VLAN davon ausgenommen ist was aber sehr ungewöhnlich wäre. Testweise kannst du es ja mal auf ein anderes VLAN Interface mappen um das auszuschliessen.
Wenn es nicht im Handbuch steht warum, solltest du mal einen Case beim Hersteller dazu aufmachen um den Fehler zu klären.
Auf einem Catalysten mit z.B.
time-range NO_INTERNET
periodic daily 11:00 to 13:00

ip access-list extended NAT
deny ip 10.128.194.0 0.0.0.127 any time-range NO_INTERNET
permit ip host 10.128.193.79 any
permit ip host 10.128.192.219 any
permit ip host 10.128.192.238 any
klappt das fehlerlos.
Ggf. musst du also die Zeitsteuerung nicht an die gesamte ACL hängen sondern nur an das einzelne Filter Statement im Regelwerk der ACL wie bei der o.a. IOS Syntax.

Meine Logik war die folgende:

1. Massnahme: die default Logik lässt erst mal alles durch (ist also erst mal keine wirkliche Barriere)

deshalb setzte ich eine Barriere drauf:

Regel (Priority 60): deny ...0.x zu ...10.x damit wird (zwischen VLAN 1 und VLAN 10 - nix wird mehr durchgelassen)

und jetzt werden noch zwei Regeln (20 und 40) mit höherer Priorität und "permit" darauf gesetzt ...damit die Priority 60 -Regel nicht in Kraft tritt

Warum die zeitgesteuerte ACL nicht auf ein VLAN Interface angewendet werden kann erschliesst sich mit aktuell auch nicht. Welches Modell ist das ??

Ein Cisco Business Switch 250

Möglich das das Default VLAN davon ausgenommen ist was aber sehr ungewöhnlich wäre. Testweise kannst du es ja mal auf ein anderes VLAN Interface mappen um das auszuschliessen.

schon probiert - auch auf VLAN 10 kommt der gleiche Fehler

Ggf. musst du also die Zeitsteuerung nicht an die gesamte ACL hängen sondern nur an das einzelne Filter Statement im Regelwerk der ACL wie bei der o.a. IOS Syntax.

das tat ich ja nicht - die time range habe ich nur auf eine einzelne Regel angewandt....aber wenn ich die ACL (mit allen Regeln) anhängen will kommt der Fehler ....

Case aufmachen bei Cisco geht nur wenn man einen Servicevertrag hat

und jetzt werden noch zwei Regeln (20 und 40) mit höherer Priorität und "permit" darauf gesetzt

WAS bitte sollen die denn permitten ?? Es ist doch so oder so ALLES weiterhin permitted also ALLES erlaubt. Wozu also noch extra etwas erlauben???
Du hast die Logik immer nicht wirklich nicht gerafft, oder? 🤔

Case aufmachen bei Cisco geht nur wenn man einen Servicevertrag hat

Dann poste das in das Cisco Forum. Da antworten auch Entwickler. Alternativ rufe die SoHo Hotline bei Cisco in München an. Wenn der neu ist hast du ja noch gesetzliche Garantie und auch der Händler sollte dir diese Frage dann beanworten.

Ich möchte keinesfalls dein Kompetenz in Frage stellen nachdem du mir schon so oft geholfen hast, aber ich kann diesesmal nur sagen --> mein Regelwerk macht Sinn:

Ich habs gerade nochmal mit Ping ausprobiert:

Ausgangssituation:
default-Logik mit permit any any + Regel 60 (deny ...0.x zu ...10.x = Barriere zwischen VLAN1 und VLAN 10)

Ping von 192.168.0.85 zu 192.168.10.164 scheitert (logisch !!!)

jetzt kommt zu der Ausgangsituation noch die Permit-Regel (mit höherer Priorität dazu):
default-Logik mit permit any any + Regel 60 + Regel 40 (Permit 192.168.0.85)

Ping von 192.168.0.85 zu 192.168.10.164 funktioniert (diese Regel wird vor 60 abgearbeitet und matched...somit kommt Regel 60 gar nicht zur Anwendung )

Durch die Permit-Regel 40 komme ich auf die NAS im anderen VLAN - ohen die Permit-Regel geht gar nichts zwischen VLAN 1 und VLAN10 (Barriere)

Ich möchte keinesfalls dein Kompetenz in Frage stellen

Das darfst du aber gerne. Fehler macht ja jeder.

Du hast aber natürlich Recht. Wenn du nur ein einziges Statement hast ist das klar das dann alles scheitert was von .0.0 nach .10.0 geht.
Wenn du dann nur die beiden Hosts .0.85 nach .10.164 erlauben willst muss das als permit mit einer höheren Priority davor. Das erzeugt dann den positiven Hit in der ACL.
Sorry, das hatte ich dann missverstanden. Shame on me...

jetzt bleibt nur noch das time range Problem - in der Communitiy hab ich das Problem schon geposted - mal schauen ob sich da wer meldet...oder ich rufe wirklich mal bei der Hotline an

Danke für deine Hilfe !!

Wenn ja, wäre ein Feedback, wie immer, hilfreich.

Ich möchte keinesfalls dein Kompetenz in Frage stellen

Wäre auch zwecklos. Die Fachkompetenz ist einzigartig. Wenn da mal was nicht passt, lag es immer an der Lese...bereitschaft

Das liegt an der wahnsinnigen Geschwindigkeit, mit der der Kollege @aqui hier in beeindruckender Qualität die Threads abarbeitet, nebenbei (mehrsprachig) Tutorials schreibt, Tests aufbaut, Leute in Not per PN unterstützt und wer weiß was er noch so nebenbei macht. Wahrscheinlich joggt er auch noch, während er hier postet oder brät Spiegeleier

Ich bin immer wieder beeindruckt. Und fast froh, wenn dann mal so ein kleiner Verleser passiert, weil das so schön menschlich ist.

Viele Grüße, commodity

gelöst Frage Netzwerke Router, Routing

Mehr von fishrain

Probleme mit RDP über VPN-Zugang zur pfSensefishrain - 20 Kommentare

Cisco Switch 250 - Passwort Recovery per CLIfishrain - 10 Kommentare

DDNS-Dienst für NAS im Subnetzfishrain - 15 Kommentare

Schutz gegen Ransomware - Subnetz erstellenfishrain - 20 Kommentare

Heiß diskutiert