136423
Jan 07, 2019, updated at 11:52:36 (UTC)
2423
14
0
Probleme mit ACL
Liebe Community,
ich konfiguriere derzeit die ACL und ACE auf unserem Cisco Layer-3-Switch Router und ich habe ein Verständnissproblem.
Im Allgemeinen haben wir 4 VLANs.
VLAN 1: 192.168.1.0/24
VLAN 22: 10.0.2.0/24
VLAN 33: 10.0.3.0/24
VLAN 44: 10.0.4.0/24
Mir geht es konkret um das Beispiel eines Pings vom VLAN 22 Netz ins VLAN 33 Netz (als Beispiel).
Wenn ich die ACL einem VLAN Interface beifüge wähle ich die Option "Deny by default", weswegen nach meinem Verständnis ja erstmal ALLE eingehende und ausgehende Verbindungen geblockt sein sollten. Zudem habe ich folgende zwei Regeln
Priorität | Mode | Protokoll XXX Source IP | Wildcard Maske | Port XXX Dest IP | Wildcard Maske | Port
1 | Permit | any XXX 10.0.3.0 | 0.0.0.255 | any XXX any | any | any => damit sollte das Netz 10.0.3.0/24 ja erst einmal kompletten Zugriff auf alle anderen VLAN haben (für das Pong)
2 | Permit | any XXX 10.0.2.0 | 0.0.0.255 | any XXX 10.0.3.0 | 0.0.0.255 | any => damit sollte das Netz 10.0.2.0/24 ja erst einmal kompletten Zugriff auf die 10.0.3.0/24 haben (für das Ping)
Diese ACL wird dem VLAN 33 Interface hinzugefügt.
Alle andere Verbindungen, aus allen anderen Netzen sollten ja gesperrt sein. Trotzdem kann ich von einem Host aus dem 10.0.4.0/24 einen Server im 10.0.3.0/24 Netz pingen (10.0.4.254 mit dem Cisco-Layer-3 Ping-Tool). Warum? Für mich macht das keinen Sinn.
Zwar sind ausgehende Verbindungen von 10.0.3.0/24 zu 10.0.4.0/24 offen, sollten eingehende Verbindungen aber nicht gesperrt sein?
Mit besten Grüßen,
niLuxx
ich konfiguriere derzeit die ACL und ACE auf unserem Cisco Layer-3-Switch Router und ich habe ein Verständnissproblem.
Im Allgemeinen haben wir 4 VLANs.
VLAN 1: 192.168.1.0/24
VLAN 22: 10.0.2.0/24
VLAN 33: 10.0.3.0/24
VLAN 44: 10.0.4.0/24
Mir geht es konkret um das Beispiel eines Pings vom VLAN 22 Netz ins VLAN 33 Netz (als Beispiel).
Wenn ich die ACL einem VLAN Interface beifüge wähle ich die Option "Deny by default", weswegen nach meinem Verständnis ja erstmal ALLE eingehende und ausgehende Verbindungen geblockt sein sollten. Zudem habe ich folgende zwei Regeln
Priorität | Mode | Protokoll XXX Source IP | Wildcard Maske | Port XXX Dest IP | Wildcard Maske | Port
1 | Permit | any XXX 10.0.3.0 | 0.0.0.255 | any XXX any | any | any => damit sollte das Netz 10.0.3.0/24 ja erst einmal kompletten Zugriff auf alle anderen VLAN haben (für das Pong)
2 | Permit | any XXX 10.0.2.0 | 0.0.0.255 | any XXX 10.0.3.0 | 0.0.0.255 | any => damit sollte das Netz 10.0.2.0/24 ja erst einmal kompletten Zugriff auf die 10.0.3.0/24 haben (für das Ping)
Diese ACL wird dem VLAN 33 Interface hinzugefügt.
Alle andere Verbindungen, aus allen anderen Netzen sollten ja gesperrt sein. Trotzdem kann ich von einem Host aus dem 10.0.4.0/24 einen Server im 10.0.3.0/24 Netz pingen (10.0.4.254 mit dem Cisco-Layer-3 Ping-Tool). Warum? Für mich macht das keinen Sinn.
Zwar sind ausgehende Verbindungen von 10.0.3.0/24 zu 10.0.4.0/24 offen, sollten eingehende Verbindungen aber nicht gesperrt sein?
Mit besten Grüßen,
niLuxx
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 397388
Url: https://administrator.de/contentid/397388
Printed on: April 23, 2024 at 16:04 o'clock
14 Comments
Latest comment
Mal noch eine blöde Frage. Ergänzen sich die ACL, selbst wenn sie verschiedenen VLAN-Interfaces zugeordnet sind?
Wenn ich also bei meinem Upstream Interface sowas wie:
Permit any any | any any habe, würde sich das auf meine Subnetze auswirken oder nur auf das Upstream interface?
Wenn ich also bei meinem Upstream Interface sowas wie:
Permit any any | any any habe, würde sich das auf meine Subnetze auswirken oder nur auf das Upstream interface?
Blöde Fragen jibbet nich nur blöde Antworten ! 
Das VLAN 33 hat ja wohl kaum 2 IP Netze auf einem Draht ! Folglich ist diese Regel doch dann Unsinn, denn es kann ja niemals beide Absender IPs aus diesem VLAN geben ?!
Denn wenn das VLAN die IP 10.0.3.0 /24 hat, woher sollten denn Absender IPs mit 10.0.2.0 /24 aus diesem Segment kommen. Das wäre dann also Quatsch.
Grundregeln wie immer bei den ACLs:
Kein Wunder das das klappt, denn....
Hast du mal an die Absender IP gedacht ?! Der L3 Switch kann ja frei wählen ober er mit seiner Absender IP aus dem .3.0er VLAN Netz oder dem .4.0er VLAN Netz pingt.
Normal nimmt er immer die IP die er selber im Zielnetz liegen hat. Sprich deine ACL kann hier gar nicht wirken.
Das hast du sicher im Eifer des Gefechts übersehen, oder ? Absender IP ist also wichtig.
Entweder nutzt du dann die Extended Ping Options des Tools wo du die Absender IP vorgeben kannst oder...
Du nutzt explizit einen Client im .3.0er Netz der einen Client im .4.0er Netz anpingt !
Dann greift auch deine ACL sofern sie denn syntaktisch richtig ist ?!
damit sollte das Netz 10.0.3.0/24 ja erst einmal kompletten Zugriff auf alle anderen VLAN haben (für das Pong)
Ja, richtig. Aber was bitte ist ein "Pong" ? (Gab in den 70ern mal ein TV Spiel mit dem Namen ?!)Diese ACL wird dem VLAN 33 Interface hinzugefügt.
Da ist schon der erste Fehler !!Das VLAN 33 hat ja wohl kaum 2 IP Netze auf einem Draht ! Folglich ist diese Regel doch dann Unsinn, denn es kann ja niemals beide Absender IPs aus diesem VLAN geben ?!
Denn wenn das VLAN die IP 10.0.3.0 /24 hat, woher sollten denn Absender IPs mit 10.0.2.0 /24 aus diesem Segment kommen. Das wäre dann also Quatsch.
Grundregeln wie immer bei den ACLs:
- Regeln gelten nur INBOUND. Also alles was IN das VLAN Interface vom Draht reinkommt.
- First match wins ! Sobald eine Regel greift werden folgende NICHT mehr abgearbeitet.
mit dem Cisco-Layer-3 Ping-Tool
Mit dem Ping Tool im L3 Switch ??Kein Wunder das das klappt, denn....
Hast du mal an die Absender IP gedacht ?! Der L3 Switch kann ja frei wählen ober er mit seiner Absender IP aus dem .3.0er VLAN Netz oder dem .4.0er VLAN Netz pingt.
Normal nimmt er immer die IP die er selber im Zielnetz liegen hat. Sprich deine ACL kann hier gar nicht wirken.
Das hast du sicher im Eifer des Gefechts übersehen, oder ? Absender IP ist also wichtig.
Entweder nutzt du dann die Extended Ping Options des Tools wo du die Absender IP vorgeben kannst oder...
Du nutzt explizit einen Client im .3.0er Netz der einen Client im .4.0er Netz anpingt !
Dann greift auch deine ACL sofern sie denn syntaktisch richtig ist ?!
Hallo Aqui,
(mal wieder) besten Dank für deine Antwort.
Zu deinen Kommentaren:
Das ist jetzt neu für mich. Dass im VLAN 33 nur 10.0.3.0/24 IPs sind ist klar, aber ich dachte ACE filtert auch OUTBOUND. Das heißt letztlich, dass Source in meinem Fall die 10.0.2.0/24 wäre und Destination immer innerhalb des VLAN liegt? (Wir haben Inter-Vlan Routing aktiviert)
ACL würde also niemals OUTBOUND traffic verhindern?
Bei dem Cisco Ping kann man die Interface IPs auswählen. Ich hatte also 4 verschiedene IP-Sources für den Ping:
10.0.2.254
10.0.3.254
10.0.4.254
192.168.1.254
Liebe Grüße,
niLuxx
(mal wieder) besten Dank für deine Antwort.
Zu deinen Kommentaren:
Ja, richtig. Aber was bitte ist ein "Pong" ? (Gab in den 70ern mal ein TV Spiel mit dem Namen ?!)
=> Ich dachte die Rückantwort heißt ganz offiziell Pong ^^ Hatte das mal auf einer Internetseite gelesen und innerlich schon gelacht.Denn wenn das VLAN die IP 10.0.3.0 /24 hat, woher sollten denn Absender IPs mit 10.0.2.0 /24 aus diesem Segment kommen. Das wäre dann
also Quatsch.
Grundregeln wie immer bei den ACLs:
Regeln gelten nur INBOUND. Also alles was IN das VLAN Interface vom Draht reinkommt.
First match wins ! Sobald eine Regel greift werden folgende NICHT mehr abgearbeitet.
also Quatsch.
Grundregeln wie immer bei den ACLs:
Regeln gelten nur INBOUND. Also alles was IN das VLAN Interface vom Draht reinkommt.
First match wins ! Sobald eine Regel greift werden folgende NICHT mehr abgearbeitet.
Das ist jetzt neu für mich. Dass im VLAN 33 nur 10.0.3.0/24 IPs sind ist klar, aber ich dachte ACE filtert auch OUTBOUND. Das heißt letztlich, dass Source in meinem Fall die 10.0.2.0/24 wäre und Destination immer innerhalb des VLAN liegt? (Wir haben Inter-Vlan Routing aktiviert)
ACL würde also niemals OUTBOUND traffic verhindern?
Hast du mal an die Absender IP gedacht ?! Der L3 Switch kann ja frei wählen ober er mit seiner Absender IP aus dem .3.0er VLAN Netz oder dem > .4.0er VLAN Netz pingt.
Normal nimmt er immer die IP die er selber im Zielnetz liegen hat. Sprich deine ACL kann hier gar nicht wirken.
Normal nimmt er immer die IP die er selber im Zielnetz liegen hat. Sprich deine ACL kann hier gar nicht wirken.
Bei dem Cisco Ping kann man die Interface IPs auswählen. Ich hatte also 4 verschiedene IP-Sources für den Ping:
10.0.2.254
10.0.3.254
10.0.4.254
192.168.1.254
Liebe Grüße,
niLuxx
Ich habe gerade diese Aussage in der Cisco Community gefunden.
Es scheint doch so zu sein, dass beide Richtungen konfiguriert werden müssen:
"This is really a more complicated issue than it might appear on the surface. Communication needs to be 2 way, If vlan 2 needs to communicate with vlan 3 and sends a packet to vlan 3 then vlan 3 needs to be able to send a response. ACL 103 prevents this by denying anything being sent from 3 to 2."
=> Dann aber wahrscheinlich in verschiedenen ACL. Das könnte auch der Grund sein, weswegen mein Ping dann manchmal nicht funktioniert.
Es scheint doch so zu sein, dass beide Richtungen konfiguriert werden müssen:
"This is really a more complicated issue than it might appear on the surface. Communication needs to be 2 way, If vlan 2 needs to communicate with vlan 3 and sends a packet to vlan 3 then vlan 3 needs to be able to send a response. ACL 103 prevents this by denying anything being sent from 3 to 2."
=> Dann aber wahrscheinlich in verschiedenen ACL. Das könnte auch der Grund sein, weswegen mein Ping dann manchmal nicht funktioniert.
Hatte das mal auf einer Internetseite gelesen und innerlich schon gelacht.
Da hat dich einer verar... Das ist jetzt neu für mich.
Wissen viele nicht, deshalb gibts hier so viele Threads dazu Billige Switches können immer nur inbound ACLs. Bessere natürlich auch Outbound aber da muss man sehr vorsichtig sein, denn viele können outbound dann oft nur in Software mit Performance Verlusten dann.
Die meisten Premium Switches machen das in Silizium....aber eben Premium Segment ala Catalyst.
Du schreibst ja leider nicht ob du Cisco Catalysten mit IOS hast oder deren billige SoHo Serie SG-xyz. Da müssen wir dann leider wieder raten.
Letztere macht nur inbound.
aber ich dachte ACE filtert auch OUTBOUND.
Nein !In der Regel nicht und wenn musst du im Regelwerk explizit das mit einem Parameter konfigurieren ob du das "in" oder "out" verstanden haben willst. Bei IOS basierten Switches geht das mit dem "ip access-group xyz <in>/<out>" Kommando.
ACL würde also niemals OUTBOUND traffic verhindern?
Ja, wenigstens nicht auf den preiswerteren Switches die nur inbound können. Das musst du dann mit einer geschickten ACL Regel umgehen.Outbound Regeln machen in der Regel auch sehr wenig Sinn und sollte man wenn möglich immer vermeiden. Denn damit lässt du ja Traffic immer schon in einen Router oder Switch rein der diesen Traffic verarbeiten muss um ihn dann später zu löschen. Das ist meist unsinnig. Deshalb also besser immer vorher filtern wo man nicht will wo der Traffic reinkommt
Bei dem Cisco Ping kann man die Interface IPs auswählen
Wenn der Ping dann immer noch durchkommt ist deine ACL falsch ! Vielleicht schilderst du mal kurz was du mit einer ACL an einem VLAN Interface als Beispiel erreichen willst, dann erarbeiten wir hier die entspr. Regel ?!
Hi,
ich habe wahrscheinlich einen der 0815 Switches
(Cisco SG-300).
Wir können gerne über den konkreten UseCase sprechen, allerdings stimmt mich das Ping nach wie vor nachdenklich.
Als Beispiel. Ich habe 2 ACL erstellt:
acl_vlan1 mit ACE Einträgen aus Bild 1 für VLAN 1 (192.168.1.0/24).
[das obere]
acl_vlan22 mit ACE Einträgen aus Bild 2 für VLAN 22 (10.0.2.0/24).
[das untere]
Ich habe einen Ping von 192.168.1.103 (=vlan 1) gestartet und er ist erfolgreich. Entferne ich aus acl_vlan22 den ACE Nr. 2 (da ja outbound nicht verwendet wird) bricht der Ping sofort ab und es kommt kein Response. Daher schätze ich, dass ich wahrscheinlich schon auch die Outbounds irgendwie definieren muss.
Oder missverstehe ich etwas Grundlegendes? Verwechsle ich "Source" vielleicht mit "Destination"? Source ist schon alles was außerhalb des VLAN liegt oder?
ich habe wahrscheinlich einen der 0815 Switches
(Cisco SG-300).Wir können gerne über den konkreten UseCase sprechen, allerdings stimmt mich das Ping nach wie vor nachdenklich.
Als Beispiel. Ich habe 2 ACL erstellt:
acl_vlan1 mit ACE Einträgen aus Bild 1 für VLAN 1 (192.168.1.0/24).
[das obere]
acl_vlan22 mit ACE Einträgen aus Bild 2 für VLAN 22 (10.0.2.0/24).
[das untere]
Ich habe einen Ping von 192.168.1.103 (=vlan 1) gestartet und er ist erfolgreich. Entferne ich aus acl_vlan22 den ACE Nr. 2 (da ja outbound nicht verwendet wird) bricht der Ping sofort ab und es kommt kein Response. Daher schätze ich, dass ich wahrscheinlich schon auch die Outbounds irgendwie definieren muss.
Oder missverstehe ich etwas Grundlegendes? Verwechsle ich "Source" vielleicht mit "Destination"? Source ist schon alles was außerhalb des VLAN liegt oder?
ich habe wahrscheinlich einen der 0815 Switches
Einfach mal lesen was draufsteht Ja, denn Profi Switches haben kein Klicki Bunti GUI !
Verwechsle ich "Source" vielleicht mit "Destination"?
Ja kann sein ! Source kommt logischerweise zuerst. Eine ACL: permit ip 10.2.0.0 0.0.0.255 192.168.1.0 0.0.0.255
Erlaubt z.B. an dem Interface nur Traffic der vom 10.2.0.0er Netz ins 192.168.1.0er Netz geht nichts anderes sonst. Deny any any ist immer Default.
Ist z.B. das VLAN 10 dein 10.2.0.0 /24 und das VLAN 20 die 192.168.1.0 /24 kommt diese ACL an das VLAN 10 Interface. Am 20er Interface hätte sie logischerweise keinerlei Wirkung. Wie gesagt Traffic nur INBOUND
Warum käme die ACL dann ans VLAN 10?
Ich würde ja die Sachen (als scheinbar unwissender, wie folgt definieren).
VLAN 10
INBOUND => alles was von außen ins VLAN 10 hineingeht
OUTBOUND => alles was von innerhalb des VLAN 10 nach draußen geht
Source => Quelle/Herkunft der Anfrage
Destination => Ziel der Anfrage
Nach diesen Definitionen hätte ich gesagt, dass (wenn SG-300 nur INBOUND rules kennt), als Quelle ein außerhalb des VLAN 10 befindlicher Client eingetragen werden muss. Als Destination ein Ziel, dass innerhalb des VLANs liegt.
Ich würde ja die Sachen (als scheinbar unwissender, wie folgt definieren).
VLAN 10
INBOUND => alles was von außen ins VLAN 10 hineingeht
OUTBOUND => alles was von innerhalb des VLAN 10 nach draußen geht
Source => Quelle/Herkunft der Anfrage
Destination => Ziel der Anfrage
Nach diesen Definitionen hätte ich gesagt, dass (wenn SG-300 nur INBOUND rules kennt), als Quelle ein außerhalb des VLAN 10 befindlicher Client eingetragen werden muss. Als Destination ein Ziel, dass innerhalb des VLANs liegt.
permit ip 10.2.0.0 0.0.0.255 192.168.1.0 0.0.0.255
Das hätte ich dann ehrlich gesagt eher ins 192.168.1.0/24 (VLAN 20) Netz gelegt.
Ich habe wie gesagt keine Ahnung warum, weil die Definitionen mir nicht einleuchtend sind. Wenn ich Source und Dest allerdings vertausche dann geht es
Daher danke!!
Daher danke!!
Warum käme die ACL dann ans VLAN 10?
Ist doch klar, denke mal etwas nach !Das Layer 3 Routing Interface VLAN 10 müssen alle Frames passieren die in andere IP Netze müssen. Folglich muss dort dann auch die ACL hin.
Diese lautet:
permit ip 10.2.0.0 0.0.0.255 192.168.1.0 0.0.0.255
deny ip any any
Letzteres ist Default sei aber Vollständigkeit halber hier erwähnt.
Stell dir vor du bis nun der Grenzbeamte am Schlagbaum (ACL) an diesem Interface.
Die Besucher kommen alle aus dem nahen Hintertupfingen (Source) und wollen irgendwohin (Destination) du hast aber vom König den Befehl und darfs nur Leute durchlassen die nach Posemuckeldorf wollen.
Da kommt jetzt jemand an deinen Schlagbaum und du fragst ihn wo er herkommt. (Inbound VON Hintertupfingen zum Schlagbaum Hintertupfingen)
Der sagt dir: "Von Hintertupfingen (10.2.0.1) und er will nach Posemuckeldorf (192.168.1.1)"
Für den geht der Schlagbaum auf.
Jetzt kommt der Nächste....
Der sagt dir: "Von Hintertupfingen (10.2.0.1) und er will nach Hängetittensiel (172.16.2.1)"
Machst du jetzt den Schlagbaum auf oder bleibt er zu ??
So einfach ist das
Jetzt leuchtet dir vermutlich auch selber ein warum deine ip_acl_mgmt oben ziemlicher Blödsinn ist.
Erstmal hast du da beides drin einmal das Statement für die Pakete die reingehen ins L3 Interface und auch die Antwort Paket die zurückkommen vom anderen VLAN und via Interface wieder auf den (L2) Draht gehen.
Das letzt zu filtern ist völliger Unsinn, denn wie schon mehrfach gesagt greifen die ACL NICHT outbound also alles was vom L3 Interface des Switches zurück auf den Draht zum Ziel geht. Nur andersrum !
Hier liegt vermutlich dein Denkfehler weil du dir völlig falsch vorstellst wie IP Pakete sich bewegen ?!
Du bringst vermutlich die Logik zw. Source und Destination IP Adresse und INBOUND Interfaces durcheinander.
Dazu ein heisser Tip:
Nimm dir mal einen Wireshark und sniffer mal Pakete mit in deinem Netz ! Das wirkt Wunder um die IP Adress und damit ACL Logik zu verstehen
Nabend,
schau dir das mal an:
Access Control Lists - Cisco SG550x
Hatte ich erst kürzlich mit Aqui durchgekaut
schau dir das mal an:
Access Control Lists - Cisco SG550x
Hatte ich erst kürzlich mit Aqui durchgekaut
Sch*#/e ich glaube ich habe es endlich verstanden 
Danke danke danke.
Ich hatte tatsächlich einen Denkfehler in meiner Vorstellung.
Ich habe alle VLANs als "internes", geschütztes Netz angesehen und es deswegen immer als "Endpunkt" betrachtet. Demnach waren alle Verbindungen, die von außerhalb ins VLAN gehen "inbound". Source war für mich daher immer das VLAN-fremde Netz, Destination das VLAN-interne Netz.
Aber scheinbar ist es genau anders herum. Das VLAN-Netz ist das "böse/nicht vertrauenswürdige Außennetz", weswegen die Source in meinem Fall immer mit dem VLAN-Subnetz übereinstimmt. Destination liegt für den Switch daher immer im geschützten inneren Bereich. Es macht jetzt alles Sinn.
Es bleibt nur eine Frage. Wie schütze ich denn dann mein VLAN selbst vor Angriffen aus anderen Netzen?
Mal als Beispiel mit der DMZ (192.168.178.0/24 => Wobei es dort sowieso keine statische Route in die internen Netze gibt). Aber mal angenommen.Die Netzarchitektur wäre folgende
Internet <=> Firewall <=> DMZ
Firewall <=> Layer-3-Switch <=> VLAN 10
Wie gesagt gibt es keine statische Route vom DMZ in Richtung Layer-3-Switch. Sollte sie es aber geben, würde es wohl Sinn machen:
1. Ein ACL am Layer-3-Switch an dem VLAN zu erstellen, das im selben Netz wie der Router ist. Geblockt würde dann das Subnetz der DMZ
=> Eine direkte "Outbound" Restriktion für das VLAN 10 kann ich mit dem SG-300 ja nicht setzen.
Liebe Grüße,
niLuxx
Danke danke danke.
Ich hatte tatsächlich einen Denkfehler in meiner Vorstellung.
Ich habe alle VLANs als "internes", geschütztes Netz angesehen und es deswegen immer als "Endpunkt" betrachtet. Demnach waren alle Verbindungen, die von außerhalb ins VLAN gehen "inbound". Source war für mich daher immer das VLAN-fremde Netz, Destination das VLAN-interne Netz.
Aber scheinbar ist es genau anders herum. Das VLAN-Netz ist das "böse/nicht vertrauenswürdige Außennetz", weswegen die Source in meinem Fall immer mit dem VLAN-Subnetz übereinstimmt. Destination liegt für den Switch daher immer im geschützten inneren Bereich.
Es macht jetzt alles Sinn.Es bleibt nur eine Frage. Wie schütze ich denn dann mein VLAN selbst vor Angriffen aus anderen Netzen?
Mal als Beispiel mit der DMZ (192.168.178.0/24 => Wobei es dort sowieso keine statische Route in die internen Netze gibt). Aber mal angenommen.Die Netzarchitektur wäre folgende
Internet <=> Firewall <=> DMZ
Firewall <=> Layer-3-Switch <=> VLAN 10
Wie gesagt gibt es keine statische Route vom DMZ in Richtung Layer-3-Switch. Sollte sie es aber geben, würde es wohl Sinn machen:
1. Ein ACL am Layer-3-Switch an dem VLAN zu erstellen, das im selben Netz wie der Router ist. Geblockt würde dann das Subnetz der DMZ
=> Eine direkte "Outbound" Restriktion für das VLAN 10 kann ich mit dem SG-300 ja nicht setzen.
Liebe Grüße,
niLuxx
ich glaube ich habe es endlich verstanden
Besser spät als nie ! Aber scheinbar ist es genau anders herum.
Nicht nur scheinbar es ist auch so ! Stelle dir das immer so vor:
Das sollte das Prinzip final klar machen, oder ?
is klar,.. merci
