17
ACE-Definitionen zwischen zwei VLANs (Cisco SG250-08)
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
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.
permit tcp 192.168.160.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8701 ace-priority 170
und
permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 any ace-priority 140Nun 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:
permit tcp 192.168.160.0 0.0.0.255 8701 192.168.180.50 0.0.0.0 8701 ace-priority 170
und
permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 8701 ace-priority 140Viele Grüße
Jürgen
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: 666312
Url: https://administrator.de/contentid/666312
Printed on: April 23, 2024 at 23:04 o'clock
17 Comments
Latest comment
ü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 !!
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.
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 !! 😉
Hallo aqui,
der Satz "...wie du sicher selber als guter Netzwerker weisst ..." war gut
. 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
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
Viele Grüße
Jürgen
der Satz "...wie du sicher selber als guter Netzwerker weisst ..." war gut
. 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 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
permit tcp 192.168.180.50 0.0.0.0 8701 192.168.160.0 0.0.0.255 8701 ace-priority 140permit tcp 192.168.160.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8701 ace-priority 170Das 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
Viele Grüße
Jürgen
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 !
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... 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...
Hallo aqui,
es ist immer wieder erfrischend Deine Kommentare und Tipps zu lesen
Ich hatte mich schon gewundert, warum Cisco die Definitionen so "quer" vorgenommen hat, dabei war meine Denke "quer"
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
Viele Grüße
Jürgen
es ist immer wieder erfrischend Deine Kommentare und Tipps zu lesen
Ich hatte mich schon gewundert, warum Cisco die Definitionen so "quer" vorgenommen hat, dabei war meine Denke "quer"
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
Viele Grüße
Jürgen
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... noch einmal drüber schauen lassen.
Immer gerne...Zitat von @aqui:
Ja! Es war wirklich ernst gemeint.es ist immer wieder erfrischend Deine Kommentare und Tipps zu lesen
Ich hoffe das ist positiv gemeint ?! 🧐noch einmal drüber schauen lassen.
Immer gerne...Dann werde ich gleich mal loslegen
Für das Gast-VLAN (VLAN200) habe ich nun folgende Einträge in der VLAN200-ACL vorgesehen:
ip access-list extended VLAN200-ACL (Gast-LAN)
permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10 DHCP-Antworten zulassen
permit udp 192.168.70.250 0.0.0.0 any 192.168.200.0 0.0.0.255 53 ace-priority 20 DNS-Antworten 1. DNS-Server
permit udp 192.168.70.250 0.0.0.0 any 192.168.200.0 0.0.0.255 1024-65535 ace-priority 30 DNS-Antworten 1. DNS-Server
permit tcp 192.168.70.250 0.0.0.0 any 192.168.200.0 0.0.0.255 53 ace-priority 40 DNS-Antworten 1. DNS-Server
permit tcp 192.168.70.250 0.0.0.0 any 192.168.200.0 0.0.0.255 1024-65535 ace-priority 40 DNS-Antworten 1. DNS-Server
permit udp 192.168.180.50 0.0.0.0 any 192.168.200.0 0.0.0.255 53 ace-priority 50 DNS-Antworten 2. DNS-Server
permit udp 192.168.180.50 0.0.0.0 any 192.168.200.0 0.0.0.255 1024-65535 ace-priority 60 DNS-Antworten 2. DNS-Server
permit tcp 192.168.180.50 0.0.0.0 any 192.168.200.0 0.0.0.255 53 ace-priority 70 DNS-Antworten 2. DNS-Server
permit tcp 192.168.180.50 0.0.0.0 any 192.168.200.0 0.0.0.255 1024-65535 ace-priority 80 DNS-Antworten 2. DNS-Server
deny ip 192.168.0.0 0.0.255.255 192.168.200.0 0.0.0.255 ace-priority 400 Alle internen Zugriffe sperren, sofern vorher nicht erlaubt
permit ip any 192.168.200.0 0.0.0.255 ace-priority 500 Alle Zugriffe aus dem Internet erlauben
exit "Default: Deny Any" 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
Viele Grüße
Jürgen
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.
- 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.
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
Gut das ich nachgefragt habe
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
Ich melde mich morgen mit den nächsten Versuch.
Viele Grüße
Jürgen
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
Ich melde mich morgen mit den nächsten Versuch.
Viele Grüße
Jürgen
und hätte nur die Outbound-Regeln löschen müssen.
Richtig ! 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... 
Ich melde mich morgen mit den nächsten Versuch.
Wir sind gespannt...
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
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.
ip access-list extended VLAN100-ACL (Verwaltungs-Lan)
permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10 DHCP-Anfragen zulassen
permit udp 192.168.100.0 0.0.0.255 any 192.168.70.250 0.0.0.0 domain ace-priority 20 DNS-Anfragen 1. DNS-Server
permit tcp 192.168.100.0 0.0.0.255 any 192.168.70.250 0.0.0.0 domain ace-priority 30 DNS-Anfragen 1. DNS-Server
permit udp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 40 DNS-Anfragen 2. DNS-Server
permit tcp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 50 DNS-Anfragen 2. DNS-Server
permit icmp 192.168.100.0 0.0.0.255 192.168.160.80 0.0.0.0 echo-reply any ace-priority 90 Ping-Anfrage FHEM beantworten
permit ip 192.168.100.0 0.0.0.255 192.168.70.0 0.0.0.255 ace-priority 100 uneingeschränkter Zugriffe in das VLAN 1 (192.168.70.0/24) erlauben
permit ip 192.168.100.0 0.0.0.255 192.168.120.0 0.0.0.255 ace-priority 200 uneingeschränkter Zugriff in das VLAN 120 (192.168.120.0/24) erlauben
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 80 ace-priority 300 Zugriffe per http aus das Drucker-VLAN erlauben
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 443 ace-priority 310 Zugriffe per https aus das Drucker-VLAN erlauben
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 427 ace-priority 320 Zugriffe per SLP aus das Drucker-VLAN erlauben
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 515 ace-priority 330 Zugriffe per LPD aus das Drucker-VLAN erlauben
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 613 ace-priority 340 Zugriffe per IPP aus das Drucker-VLAN erlauben
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 9100 ace-priority 350 Zugriffe per RAW aus das Drucker-VLAN erlauben
permit ip 192.168.100.0 0.0.0.255 192.168.160.0 0.0.0.255 ace-priority 400 uneingeschränkter Zugriff auf IOT VLAN
permit udp 192.168.100.0 0.0.0.255 echo 192.168.180.50 0.0.0.0 echo ace-priority 510 Zugriff auf Cloud VLAN (Echo)
permit tcp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 6690 ace-priority 520 Cloud Station
permit tcp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8701 ace-priority 530 https
permit tcp 192.168.100.0 0.0.0.255 any 192.168.180.50 0.0.0.0 8888 ace-priority 540 pi-hole - Docker
deny ip 192.168.0.0 0.0.255.255 192.168.100.0 0.0.0.255 ace-priority 800 Alle internen Zugriffe sperren, sofern vorher nicht erlaubt
permit ip 192.168.100.0 0.0.0.255 any ace-priority 900 Alle Zugriffe in das Internet erlauben
exit "Default: Deny Any" 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.
ip access-list extended VLAN140-ACL (Drucker)
permit udp 0.0.0.0 0.0.0.0 68 255.255.255.255 0.0.0.0 67 ace-priority 10 DHCP-Anfragen zulassen
permit udp 192.168.140.0 0.0.0.255 any 192.168.70.250 0.0.0.0 domain ace-priority 20 DNS-Anfragen 1. DNS-Server
permit tcp 192.168.140.0 0.0.0.255 any 192.168.70.250 0.0.0.0 domain ace-priority 30 DNS-Anfragen 1. DNS-Server
permit udp 192.168.140.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 40 DNS-Anfragen 2. DNS-Server
permit tcp 192.168.140.0 0.0.0.255 any 192.168.180.50 0.0.0.0 domain ace-priority 50 DNS-Anfragen 2. DNS-Server
permit icmp 192.168.140.0 0.0.0.255 192.168.160.80 0.0.0.0 echo-reply any ace-priority 90 Ping-Anfrage FHEM beantworten
deny ip 192.168.140.0 0.0.0.255 192.168.0.0 0.0.255.255 ace-priority 800 Alle internen Zugriffe sperren, sofern vorher nicht erlaubt
exitIch hoffe das passt so.
Viele Grüße
Jürgen
Ich hoffe das passt so.
Jupp, das sieht erheblich besser aus ! Ü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 !
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
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.
permit tcp 192.168.140.1 0.0.0.0 80 192.168.100.0 0.0.0.255 any ace-priority 200Wo liegt mein Denkfehler?
Aus meiner Sicht fehlt bei meinen Definitionen aktuell jeweils der "Antwort-Port".
Viele Grüße
Jürgen
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 !
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. 😉
Und wieder kommt etwas Licht in meine Geankengänge
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 Ich hoffe, dies für meine Bedürfnisse noch einfacher möglich ist
Viele Grüße
Jürgen
Gibt es eine Regel, welcher Port für die "Antworten" genutzt wird?
In meinem Beispiel erfolgt die Anfrage in der ACE-100 über
permit tcp 192.168.100.0 0.0.0.255 192.168.140.0 0.0.0.255 80 ace-priority 300und die Antwort in der ACE-140 über
permit tcp 192.168.140.1 0.0.0.0 80 192.168.100.0 0.0.0.255 any ace-priority 200Ich 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
Ich hoffe, dies für meine Bedürfnisse noch einfacher möglich ist Viele Grüße
Jürgen
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.
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.
Ich habe die Möglichkeit zwischen "Set", "Unset" und "Don't care" (default).
Ich habe diese Möglichkeiten:
Urg:
Set
Unset
Don't care
Ack:
Set
Unset
Don't care
Psh:
Set
Unset
Don't care
Rst:
Set
Unset
Don't care
Syn:
Set
Unset
Don't care
Fin:
Set
Unset
Don't care Ich werde das mal mit Port 80 testen.
Ich werde das mal mit Port 80 testen.
Mit diesen Einstellungen funktioniert es.
permit tcp 192.168.140.0 0.0.0.255 any 192.168.100.0 0.0.0.255 any match-all +ack ace-priority 300
permit udp 192.168.140.0 0.0.0.255 any 192.168.100.0 0.0.0.255 any ace-priority 310Allerdings würde ich gerne noch die UDP-Freigabe (Abfrage Druckerstatus) noch weiter einschränken. Ist das möglich/sinnvoll?
Viele Grüße
Jürgen
