ACE-Definitionen zwischen zwei VLANs (Cisco SG250-08)

Mitglied: juemuc

juemuc (Level 1) - Jetzt verbinden

02.05.2021 um 14:34 Uhr, 633 Aufrufe, 17 Kommentare

Hallo,

wenn ich es richtig verstanden habe, erlaube oder verbiete ich mit der ACE-Definition nur den eingehenden Datenverkehr. Wenn nun die Kommunikation zwischen zwei VLANs über einen definierten Port erfolgen darf, habe ich dies bisher immer wie folgt definiert:

Im nachfolgenden Beispiel dürfen alle Geräte aus dem VLAN 160 (192.168.160.0/24) mit der IP 192.168.180.50 (VLAN180) über Port 8701 Daten austauschen.


Nun frage ich mich, ob es nicht sinnvoller ist, anstatt für die Ports any : 8701 bzw. 8701 : any immer 8701 : 8701 anzugeben. Wie ist hier Eure Empfehlung.

Es würde dann so aussehen:



Viele Grüße

Jürgen
Mitglied: aqui
02.05.2021, aktualisiert um 15:47 Uhr
über Port 8701 Daten austauschen....
Wenn du mit dem Port "TCP" meinst ist das richtig. Allerdings ist das "UND" etwas unsinnig in der Regel, denn wenn diese nur inbound gilt ist das zusätzliche Regelwerk:
"permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 8701 ace-priority 140"
mit der höheren Priority Blödsinn, denn am VLAN 160 IP Interface kann es inbound ja niemals IP Pakete mit einer Absender IP 192.168.180.x geben ! Das wäre völlig unsinnig. Diese Regel stört zwar nicht hat aber keinerlei Effekt weil sie völlig sinnfrei ist, da diese Regel Bedingungen dort niemals eintreten.
Hier kann einmal ein Blick mit dem Wireshark wie so der Paket Flow einer solchen Verbindung aussieht sehr sehr erhellend sein !! ;-) face-wink
Wie ist hier Eure Empfehlung.
Das Regelwerk ist unsinnig, denn wie du sicher selber als guter Netzwerker weisst ist der Source Port im TCP immer Random, also zufällig !
Wenn du jetzt sowas angibst wie "permit tcp 192.168.160.0 0.0.0.255 8701 ..." erlaubst du nur noch Absender Pakete mit einem Source Port von TCP 8701. Da kannst du dann vermutlich warten bis du schwarz bist bevor so ein Paket mal an der Filterregel vorbeikommt. 6 Richtige im Lotto plus Zusatzzahl sind da sicher häufiger. 🤣
Diese Regel wird dir dann natürlich den gesamten Traffic blockieren.
Die 2te Regel ist wie oben auch wieder überflüssig da nutzlos.
Zeigt leider das du nicht so richtig blickst wie eine TCP Kommunikation im Netz funktioniert. :-( face-sad
Deshalb nochmals der dringende Rat dir so eine Connection mal mit dem Wireshark anzusehen. Das bewirkt Wunder im Durchblick wie IP Pakte sich im Netzwerk bewegen !! 😉
Bitte warten ..
Mitglied: juemuc
02.05.2021 um 19:45 Uhr
Hallo aqui,

der Satz "...wie du sicher selber als guter Netzwerker weisst ..." war gut :-) face-smile. Alles was ich über den Netzwerkkommunikation weiß, habe ich aus den Infos von Dir. Ich hoffe, dass ich in knapp einem Jahr, wenn ich dann in den Ruhestand gehe, alles wichtige von Dir gelernt habe ;-) face-wink

Ich hätte vieleicht dazu schreiben sollen, dass die beiden Regeln natürlich in zwei unterschiedlichen ACE-Tabellen enthalten sind und jeweils dem dazugehörigen VLAN zugeordnet sind.
Wenn ich Dich richtig verstanden habe, sorgt die Regel
dafür, dass ich per https aus dem IP-Bereich 192.168.160.0/24 über den Port 8701 Webseiten auf dem Gerät 192.168.180.50 aufrufen kann. Da kein "request" vom Gerät 192.168.180.50 erfolgt, funktioniert es. Die Regel
ist somit nutzlos.
Das bedeutet doch dann, dass die Kommunikation aus dem VLAN immer funktioniert, aber in das VLAN nur was erlaubt wurde.
Dann muss ich meine Regeln noch etwas überarbeiten. Ich bin erstaunt, dass trotzdem bisher so viel funktionier hat :-) face-smile

Viele Grüße
Jürgen
Bitte warten ..
Mitglied: aqui
03.05.2021, aktualisiert um 09:38 Uhr
alles wichtige von Dir gelernt habe
Oha...das wird ein hartes Stück Arbeit dann bis dahin ! 🤣
Ich hätte vieleicht dazu schreiben sollen
Oha, ja. Dann wären wir alle nicht so blindlinks in dein offenes ACL Messer gerannt. Es ist IMMER essentiell wichtig zu wissen auf WELCHEM IP Interface diese ACL definiert ist !!!
dass ich per https aus dem IP-Bereich 192.168.160.0/24 über den Port 8701 Webseiten auf dem Gerät 192.168.180.50 aufrufen kann
Nein das ist falsch. Wenn man davon ausgeht das HTTPS immer TCP 443 ist. Aber auch sonst stimmen deine Schlussfolgerungen nicht da du hier immer Source und Destination IP verwechselst.
Die Regel ist so ausgebaut:
permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 8701
Sprich also
permit <protokoll> <source_ip> <source_mask> <source_port> <destination_ip> <destination_mask> <desination_port>
Also besagt diese Regel:
"Erlaube eingehend ein TCP Paket mit der Absender IP 192.168.180.50 und dem Absenderport TCP 8701 und der Ziel IP 192.168.160.x (alles im Netzwerk .160.x ist erlaubt) und Zielport TCP 8701
Aus mehreren Gründen wird diese Regel scheitern wenn sie INBOUND am IP Interface .160.x definiert ist.
  • Im .160.x VLAN Netz wird es niemals ein Gerät geben was eine Absender IP 192.168.180.50 hat, denn das ist eine IP aus dem .180er VLAN
  • Niemals hat ein TCP Packet den gleichen Source und Destination Port
  • der Source Port eines TCP Paketes ist immer Random also eine Zufallszahl !
Du erkennst vermutlich selber wie sinnfrei diese Regel ist.
Da sie eine völlig falsche Logik hat und diese .180.50er IP Adresse dort niemals auftreten wird, wird sie auch niemals greifen. Sie schadet also glücklicherweise nicht ist aber vollkommen nutzlos.
Deshalb greift hier primär immer deine Regel: "permit tcp 192.168.160.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8701 auch wenn sie eine höhere Regelpriorität hat, also in der Regelwerk Reihenfolge hinter der ersten steht die ja niemals wirken wird.
Diese erlaubt dann allen TCP Traffic mit jeder Absender IP aus dem .160er VLAN Netz und jedem Absender Port (richtig, denn der ist ja Zufall) auf die Zieladresse 192.168.180.50 mit dem Zielport TCP 8701.
Diese Regel greift also weil sie logisch richtig ist und folglich können die TCP Pakete mit der der Ziel IP und Port 8701 passieren.
Die andere mit der höheren Prio ist nur ein reiner, überflüssiger Durchlauferhitzer die niemals einen positiven Hit ergibt. Das kannst du auch am Hit Counter der ACL ablesen.
Das bedeutet doch dann, dass die Kommunikation aus dem VLAN immer funktioniert, aber in das VLAN nur was erlaubt wurde.
Absolut richtig.
Aus dem VLAN Segment .160.0 können so nur TCP 8701 Pakete zum Host .180.50 durchkommen mit Zielport TCP 8701 sollte das deine einzige Regel sein inbound am .160er IP Interface.
Dann muss ich meine Regeln noch etwas überarbeiten.
Das wäre anzuraten... ;-) face-wink
Ich bin erstaunt, dass trotzdem bisher so viel funktionier hat
Das liegt daran das einige der Regeln wie z.B. die mit der .180er Absender IP zwar syntaktisch vollkommen falsch sind aber auch nicht schaden. Der PERMIT würde ja niemals eintreten und dann gilt weiter des implizite DENY was du ohne diese ja Regel auch hättest. In sofern richtet die Regel also nie einen merkbaren Schaden an weil sie gänzlch ohne jegliche Funktion ist an der Stelle.
Hast also Glück gehabt... ;-) face-wink
Bitte warten ..
Mitglied: juemuc
04.05.2021 um 21:00 Uhr
Hallo aqui,

es ist immer wieder erfrischend Deine Kommentare und Tipps zu lesen :-) face-smile

Ich hatte mich schon gewundert, warum Cisco die Definitionen so "quer" vorgenommen hat, dabei war meine Denke "quer" :-( face-sad

Wenn ich die Regeln neu augebaut habe, werde ich Dich aber zur Sicherheit noch einmal drüber schauen lassen. Ich will ja noch vor dem Renteneintritt fertig werden :-) face-smile

Viele Grüße
Jürgen
Bitte warten ..
Mitglied: aqui
05.05.2021 um 11:20 Uhr
es ist immer wieder erfrischend Deine Kommentare und Tipps zu lesen
Ich hoffe das ist positiv gemeint ?! 🧐
warum Cisco die Definitionen so "quer" vorgenommen hat, dabei war meine Denke "quer"
Es ist immer eine Frage des Standpunktes... ;-) face-wink
noch einmal drüber schauen lassen.
Immer gerne...
Bitte warten ..
Mitglied: juemuc
05.05.2021 um 20:20 Uhr
Zitat von @aqui:

es ist immer wieder erfrischend Deine Kommentare und Tipps zu lesen
Ich hoffe das ist positiv gemeint ?! 🧐
Ja! Es war wirklich ernst gemeint.
noch einmal drüber schauen lassen.
Immer gerne...

Dann werde ich gleich mal loslegen :-) face-smile

Für das Gast-VLAN (VLAN200) habe ich nun folgende Einträge in der VLAN200-ACL vorgesehen:


Jetzt zu meinen Fragen:

Passen aus Deiner Sicht diese Einträge?
Kommen die "DNS-Antworten" wirklich über diese Ports? Es gibt zwei DNS-Server DNS2 = Backup.

Wäre es nicht sinnvoller nur bestimmte Ports für die IPs aus dem Internet freizugeben? Wenn ja, was wäre den sinnvoll?
Was benötige ich? Ich greife per Cisco-VPN-Client auf das Firmennetzwerk zu. Ansonsten sollen noch die Webseiten aufrufbar sein.

Wireshark habe ich noch nicht genutzt. Ich befürchte aber, dass hier meine Fragen noch unverständlicher klingen werden :-) face-smile

Viele Grüße
Jürgen
Bitte warten ..
Mitglied: aqui
05.05.2021, aktualisiert um 21:09 Uhr
habe ich nun folgende Einträge in der VLAN200-ACL vorgesehen:
WAS für ein IP Netz hat das 200er VLAN ?? .70.0 ??
Wenn es .70.0 ist dann ist die Hälfte dieser Regeln wieder Unsinn. :-( face-sad
  • Erste Regel (Prio 10) ist OK für DHCP
  • Die .70.x Regeln stimmen auch weil dort ja nur Absender IP aus .70.x kommen
  • Die Regeln die Absender IPs von .180.0 betreffen sind wieder Unsinn, denn die können da ja niemals auftauchen.
Ich befürchte das du weiterhin einen fatalen Denkfehler machst. :-( face-sad
Das Regelwerk greift INBOUND also alle Pakete vom VOM Netzwerk Draht IN das VLAN IP Interface hineingehen.
Gehen wir also mal logisch davon aus das dein VLAN 200 auch die IP .200.0 hat. Folglich haben also ALLE Absender IPs immer eine 192.168.200.x Adresse.
Wenn das Regelwerk nun so funktioniert:
PERMIT|DENY <protokoll> <ABSENDER_ip> <source_mask> <source_port> <ZIEL_ip> <destination_mask>

und du am 200er Interface sagst
"Filter alles was hier reinkommt und eine Absender IP von ....70.x hat und....
Filter alles was hier reinkommt und eine Absender IP von ....180.x hat und..."

dann fragt man sich WIE du auf die Idee kommst das am 192.168.200er IP Interface jemals Absenderpakete mit der Adresse .70.x oder .180.x ankommen soll wie du es definiert hast ???
Diese Regeln sind wieder völlig wirkungslos. Wenn du sie so implementierst wird lediglich DHCP funktionieren alles andere wird weiter geblockt weil du nach völlig falschen Absender IPs blockst.
Das ist doch vollkommen unmöglich ! Es können doch nur Absender IPs aus dem 200er VLAN dort ankommen.
Du hast wieder nicht geschnallert das das Regelwerk INBOUND gilt.

Der zweite Kardinalsfehler ist das du gleiche Priorities vergeben hast. Wie soll das bitte gehen wenn das Regelwerk eine strike Hierarchie haben muss (Reihenfolge). Priority Werte sollten dann in 3er oder 5er Schritten inkrementieren. Der intelligente Netzwerk Admin lässt Zwischenschritte damit er später in jedem Punkt des Regelwerkes Regeln zwischenschieben kann OHNE das er die ganzen Prio Werte neu ordnen muss.

Hier mal ein Beispiel wie ein Regelwerk an VLAN 200 auszusehen hat was nur DHCP, DNS, HTTP und HTTPS nach Überall durchlässt:
permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10
permit udp 192.168.200.0 0.0.0.255 any any 53 ace-priority 15
permit tcp 192.168.200.0 0.0.0.255 any any 53 ace-priority 20
permit tcp 192.168.200.0 0.0.0.255 any any 80 ace-priority 25
permit tcp 192.168.200.0 0.0.0.255 any any 443 ace-priority 30

Beispiel wenn VLAN 200 Traffic nur DHCP und DNS nach Überall durchlässt und HTTP und HTTPS nur in die VLANs .70.0 und .180.0

permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10
permit udp 192.168.200.0 0.0.0.255 any any 53 ace-priority 15
permit tcp 192.168.200.0 0.0.0.255 any any 53 ace-priority 20
permit tcp 192.168.200.0 0.0.0.255 any 192.168.70.0 0.0.0.255 80 ace-priority 25
permit tcp 192.168.200.0 0.0.0.255 any 192.168.180.0 0.0.0.255 443 ace-priority 30


Ich denke mal nun hast du vermutlich diese einfache Logik durchschaut, oder ?
Tip:
Tu dir doch wirklich mal selber den Gefallen und installier dir mal den Wireshark auf dem Rechner und sieh dir damit mal deine Pakete im Netz an. Das wird Wunder und mit einmal verstehst du sofort wie die Pakete mit Absneder und Ziel IP ausgebaut sind !!! 😉
https://www.heise.de/ct/artikel/Fehler-erschnueffeln-221587.html
Bitte warten ..
Mitglied: juemuc
05.05.2021 um 22:52 Uhr
Gut das ich nachgefragt habe :-( face-sad

Dann hatte ich es doch am Anfang richtig verstanden und hätte nur die Outbound-Regeln löschen müssen. Ich habe noch einmal meinen ersten Thread gelesen. Jetzt ist mir auch klar, warum Du das nicht verstehen konntest und mich damit dann auch wieder verwirrt hast. Die erste Zeile war immer in der ACL-160 und die 2. Zeile in der ACL-180.

Ich baue noch einmal um.

Das Thema Prio war nur ein Tipp-Fehler. Ich habe die Regeln ja aktuell nur auf "Papier" also in einem Dokument. Ich habe ja Deinen Tipp befolgt, das man das ganze erst einmal aufschreiben soll. Umgesetzt ist noch nichts :-) face-smile

Ich melde mich morgen mit den nächsten Versuch.

Viele Grüße
Jürgen
Bitte warten ..
Mitglied: aqui
06.05.2021 um 10:24 Uhr
und hätte nur die Outbound-Regeln löschen müssen.
Richtig ! ;-) face-wink
Die erste Zeile war immer in der ACL-160 und die 2. Zeile in der ACL-180.
Genau DAS hatte wohl alle verwirrt. Du hast gedacht das du den Rückweg auch angeben musst, war aber Unsinn, denn das wäre dann Outbound was das regelwerk gar nicht beachtet...
Ich baue noch einmal um.
Besser iss das... :-D face-big-smile
Ich melde mich morgen mit den nächsten Versuch.
Wir sind gespannt...
Bitte warten ..
Mitglied: juemuc
08.05.2021 um 14:31 Uhr
Hallo aqui,

hier nun mein Ergebnis:

Aus dem VLAN 100 möchte ich auf alle VLANs zugreifen. Manche Zugriffe sind eingeschränkt. Die dedizierten DNS-Zugriffe sind zwar überflüssig, aber als Vorlage für die anderen VLANs auch hier definiert.


Aus dem Drucker-VLAN soll nur der "Ping" beantwortet werden. Allerdings vermute ich, dass ich noch noch weitere Ports frei geben muss, dass der Drucker auch die "Druckergebnisse" zurückmelden kann. Hier bitte ich um Hilfe.


Ich hoffe das passt so.

Viele Grüße
Jürgen
Bitte warten ..
Mitglied: aqui
08.05.2021 um 15:59 Uhr
Ich hoffe das passt so.
Jupp, das sieht erheblich besser aus ! ;-) face-wink

Über die Drucker 800er Regel könnte man kosmetisch diskutieren, denn am Ende der Regel gilt so oder so immer ein impliziertes "DENY any any" was die 800er Regel dann eh inkludiert und überflüssig macht.
Aber sonst...alles Bella ! ;-) face-wink
Bitte warten ..
Mitglied: juemuc
08.05.2021 um 22:18 Uhr
Hallo aqui,

das passt aber leider noch nicht. In dieser Konstellation erreiche ich den Drucker nicht über die Web-Oberfläche (Port 80). Ich vermute, dass ich einen "Antwort-Port" vom 140-VLAN ins 100-VLAN frei geben muss.

Wenn ich hier aber in der ACE-140 diesen Eintrag hinzufüge, geht es. Dies wieder spricht aber Deiner Aussage.

Wo liegt mein Denkfehler?

Aus meiner Sicht fehlt bei meinen Definitionen aktuell jeweils der "Antwort-Port".

Viele Grüße
Jürgen
Bitte warten ..
Mitglied: aqui
09.05.2021 um 12:56 Uhr
erreiche ich den Drucker nicht über die Web-Oberfläche (Port 80)
Ist aber selber so gewollt oder siehst du in deiner VLAN140-ACL oben das irgendwas anderes außer DHCP, DNS und Ping Replies erlaubt ist ??? Ich jedenfalls nicht.
Wie dachtest du dir denn soll da HTTP Traffic durchkommen ?!
Wenn ich hier aber in der ACE-140 diesen Eintrag hinzufüge, geht es
Auch logisch... Das erlaubt dann allen HTTP Traffic vom Drucker mit der .140.1 ins .100.0er Netz wo vermutlich dein Konfig PC steht ?!
Also...Works as designed ! ;-) face-wink
Wenn du nicht willst das ALLE aus dem 100er Netz das können musst du das noch dichtmachen auf deinen Rechner und ggf. HTTP
permit tcp 192.168.140.1 0.0.0.0 80 192.168.100.23 0.0.0.0 any ace-priority 200
Aus meiner Sicht fehlt bei meinen Definitionen aktuell jeweils der "Antwort-Port".
Der Port nicht aber das Netz. Das ist richtig weil ACLs im Gegensatz zu einer Firewall nicht stateful sind. 😉
Bitte warten ..
Mitglied: juemuc
09.05.2021 um 13:30 Uhr
Und wieder kommt etwas Licht in meine Geankengänge :-) face-smile

Gibt es eine Regel, welcher Port für die "Antworten" genutzt wird?

In meinem Beispiel erfolgt die Anfrage in der ACE-100 über

und die Antwort in der ACE-140 über

Ich würde jetzt ungerne per "Gieskanne" alle Ports, über die eine Anfrage kommt, auch als "Antwort-Port" wieder frei geben, wenn dies nicht notwendig ist. Es sei denn, dies ist immer notwendig.

Ich weiß, Du empfiehlst das jetzt mit Wireshark zu prüfen, aber soweit bin ich noch nicht :-) face-smile Ich hoffe, dies für meine Bedürfnisse noch einfacher möglich ist :-) face-smile

Viele Grüße
Jürgen
Bitte warten ..
Mitglied: aqui
09.05.2021, aktualisiert um 14:00 Uhr
Ich würde jetzt ungerne per "Gieskanne" alle Ports, über die eine Anfrage kommt, auch als "Antwort-Port" wieder frei geben,
Da musst du mal checken ob du im Regelwerk TCP Pakete mit gesetztem ACK Bit passieren lassen kannst ala:
permit tcp 192.168.140.1 0.0.0.0 any 192.168.100.0 0.0.0.255 any established ace-priority 200
Bei Catalysten geht das.
Das würde dann quasi stateful sein und allen Paketen die nach einer Connection auf den Drucker .140.1 wieder ins .100er Netz rauskommen UND ein gesetztes TCP ACK Bit haben den Weg freimachen. Das wäre dann zumindestens für TCP die "Giesskanne" die du benötigst. ;-) face-wink
Bitte warten ..
Mitglied: juemuc
09.05.2021 um 14:55 Uhr
Ich kann die Flags zumindest setzen.
Ich habe die Möglichkeit zwischen "Set", "Unset" und "Don't care" (default).
Ich habe diese Möglichkeiten:

Ich werde das mal mit Port 80 testen.
Bitte warten ..
Mitglied: juemuc
09.05.2021 um 19:38 Uhr
Ich werde das mal mit Port 80 testen.

Mit diesen Einstellungen funktioniert es.

Allerdings würde ich gerne noch die UDP-Freigabe (Abfrage Druckerstatus) noch weiter einschränken. Ist das möglich/sinnvoll?

Viele Grüße
Jürgen
Bitte warten ..
Heiß diskutierte Inhalte
Hyper-V
Spricht was gegen die Virtualisierung mit Hyper-V?
bauinformatikerVor 1 TagFrageHyper-V32 Kommentare

Seit 10 Jahren betreiben mein Kollege und ich 2 Hosts mit ESXi. Nun sollen die neu beschafft und neu installiert werden. Bis auf einen ...

Off Topic
Vom IT-Systemelektroniker zurück zur "IT"
xsheynVor 1 TagFrageOff Topic8 Kommentare

Schönen guten Abend, vor einigen Wochen hatte ich schonmal einen Thread erstellt, dass ich IT-Systemelektroniker bin aber kaum Erfahrung in der "Typischen IT" habe. ...

Entwicklung
Plattformübergreifende Programmierung mit Visual Studio
gelöst nagitaVor 1 TagAllgemeinEntwicklung11 Kommentare

Hallo ich habe mir vor einiger Zeit die aktuellste Version von Visual Studio installiert und bin eigentlich auch recht zufrieden damit. Ich habe vor, ...

Datenbanken
Liste als PDF ausdrucken
jensgebkenVor 1 TagFrageDatenbanken6 Kommentare

Hallo Gemeinschaft, Ich habe eine Access Datenbank und darin eine Abfrage in der Kunden Adressen und Kosten angezeigt werden pro Kunde. Nun möchte ich, ...

Video & Streaming
Netzwerkspeicher IPTV
uridium69Vor 1 TagFrageVideo & Streaming8 Kommentare

Hallo Ich möchte gerne meine beiden Android IPTV Receiver das NAS als Netzwerkspeicher und als Aufnahmemedium hinzufügen, ich habe unter den Optionen "Netzwerkspeicher hinzufügen" ...

Exchange Server
Postfach für öffentliche Ordner ist voll
gelöst Tommy525600Vor 23 StundenFrageExchange Server6 Kommentare

Hallo an alle, ich habe folgendes Problem: Mein primäres Postfach für öffentliche Ordner ist voll (99,58 GB) (und ja, ich kann auch nix dafür). ...

Netzwerke
PFSense und Transferprobleme
Xaero1982Vor 22 StundenFrageNetzwerke8 Kommentare

Moin Zusammen, leidiges Thema PFSense - ich hab mich mal wieder ran gewagt. Ich hab hier so ein paar VLANs laufen und nen ESX. ...

Outlook & Mail
Outlook export to PST schlägt fehl - Alternativen?
gelöst StefanKittelVor 1 TagFrageOutlook & Mail3 Kommentare

Hallo, ich versuche gerade ca. 20 Postfächer von einem Hosted Exchange-Anbieter in PST-Dateien zu sichern/archivieren. Bei 3 Postfächer schläft dies mit "unbekannter Fehler" fehl. ...