75068
Oct 27, 2009
13774
8
1
Funkwerk BinTec R1200 Firewall-Problem
Guten Tag,
würde mich freuen wenn ihr mir bei folgendem Problem helfen könnt:
Ausgangssituation:
LAN A besteht aus:
PC A:
IP: 192.168.80.111
Subnetzmaske: 255.255.255.0
Gateway: 192.168.80.121
Router A:
Hersteller: Funkwerk
Modell: BinTec R1200
Firmware: 7.8. Rev. 7 (aktuelle vom 25.08.09)
IP Port 2: 192.168.80.121 > Verbindung zu PC A
IP Port 3: 192.168.60.2 > Verbindung zu Router B
Bedienungsanleitung: http://www.funkwerk-ec.com/portal/downloadcenter/dateien/r1200/doku/man ...
LAN B besteht aus:
PC B:
IP: 192.168.21.11
Subnetzmaske: 255.255.255.0
Gateway: 192.168.21.111
Router B:
Hersteller: Funkwerk
Modell: BinTec R1200
Firmware: 7.8. Rev. 7 (aktuelle vom 25.08.09)
IP Port 2: 192.168.21.111 > Verbindung zu PC B
IP Port 3: 192.168.60.1 > Verbindung zu Router A
Bedienungsanleitung: http://www.funkwerk-ec.com/portal/downloadcenter/dateien/r1200/doku/man ...
Alle Verbindungen sind FastEthernet mittels Twisted-Pair-Leitungen.
Das Routing funktioniert einwandfrei. PC A und PC B können sich jeweils problemlos „anpingen“.
Nun zum Problem:
Es soll die interne SIF (Stateful Inspection Firewall) genutzt werden um die Kommunikation auf ICMP und TCP/UDP Port 8001 bis 8004 sowie TCP/UDP Port 40001 – 40002 zu beschränken. Außerdem darf diese Kommunikation nur zwischen PC A (bzw. dessen IP) und PC B (bzw. dessen IP) und andersherum stattfinden. Alle anderen IPs sollen vollständig geblockt werden.
Momentan habe ich die Möglichkeit beide Router sowohl über Telnet- als auch über deren eigene Weboberfläche zu konfigurieren. Einfachheitshalber habe ich bis jetzt über die grafische Weboberfläche konfiguriert, da ich kaum Konfigurationsbefehle für die BinTec-Geräte kenne.
Die Firewall-Einstellungen gliedern sich in drei relevante Unterpunkte:
- Richtlinien
- Adressen
- Dienste
Bei „Richtlinien“ werden die einzelnen Regeln festgelegt, welche Quell-Adressen mit welchen Ziel-Adressen über welche Dienste (& Ports bei TCP/UDP) kommunizieren dürfen.
Zu diesem Zweck werden vorher im Unterpunkt „Adressen“ alle für die Kommunikation benötigten Adressen eingetragen.
Außerdem werden im Unterpunkt „Dienste“ die relevanten Dienste (& Ports bei TCP/UDP) erstellt.
Meine momentane Konfiguration (von unten nach oben):
Dienste:
ICMP (jegliche Typen, siehe Internet Control Message Protocol ? Wikipedia )
TCP/UDP (Port 8001 bis 8004)
TCP/UDP (Port 40001 bis 40002)
Adressen:
192.168.21.11 / 255.255.255.0
192.168.80.111 / 255.255.255.0
Richtlinien:
Quelle Ziel Dienst Aktion
192.168.21.11 192.168.80.111 ICMP Zugriff
192.168.21.11 192.168.80.111 TCP/UDP (P. 8001-8004) Zugriff
192.168.21.11 192.168.80.111 TCP/UDP (P. 40001-40002) Zugriff
192.168.80.111 192.168.21.11 ICMP Zugriff
192.168.80.111 192.168.21.11 TCP/UDP (P. 8001-8004) Zugriff
192.168.80.111 192.168.21.11 TCP/UDP (P. 40001-40002) Zugriff
Alle Quell- und Ziel-Adressen haben die Subnetzmaske 255.255.255.0
Laut der Bedienungsanleitung des Routers sind alle nicht explizit zugelassenen Verbindungen grundsätzlich gesperrt. Somit dürfte es nicht nötig sein alle sonstigen Dienste bzw. Ports über alle sonstigen IPs manuell als blockiert einzutragen.
Wenn ich die Firewall nun mit der beschriebenen Konfiguration einschalte, ist kein Ping mehr zwischen PC A und PC B (und andersherum) möglich.
Aber: bei folgender Konfiguration gelingt der Ping-Test:
Quelle Ziel Dienst Aktion
F/E 2 F/E 3 ICMP Zugriff
F/E 2 F/E 3 TCP/UDP (P. 8001-8004) Zugriff
F/E 2 F/E 3 TCP/UDP (P. 40001-40002) Zugriff
F/E 3 F/E 2 ICMP Zugriff
F/E 3 F/E 2 TCP/UDP (P. 8001-8004) Zugriff
F/E 3 F/E 2 TCP/UDP (P. 40001-40002) Zugriff
Allerdings stellt letztere Konfiguration ja ein Sicherheitsrisiko dar, weil so jegliche Quell- und Ziel-IPs über die genannten aufgeführten Ports (+ ICMP) kommunizieren dürfen.
Habt ihr eine Idee wo die Ursache dafür liegen kann, dass bei der Angabe der konkreten Adressen die Firewall den Ping blockt?
Sorry für die unübersichtlichen Richtlinien - der Editor hier kennt leider weder Tabs noch mehrmalige Blanks.
Vielen Dank im Voraus!
Gruß,
Kolja
LAN A besteht aus:
PC A:
IP: 192.168.80.111
Subnetzmaske: 255.255.255.0
Gateway: 192.168.80.121
Router A:
Hersteller: Funkwerk
Modell: BinTec R1200
Firmware: 7.8. Rev. 7 (aktuelle vom 25.08.09)
IP Port 2: 192.168.80.121 > Verbindung zu PC A
IP Port 3: 192.168.60.2 > Verbindung zu Router B
Bedienungsanleitung: http://www.funkwerk-ec.com/portal/downloadcenter/dateien/r1200/doku/man ...
LAN B besteht aus:
PC B:
IP: 192.168.21.11
Subnetzmaske: 255.255.255.0
Gateway: 192.168.21.111
Router B:
Hersteller: Funkwerk
Modell: BinTec R1200
Firmware: 7.8. Rev. 7 (aktuelle vom 25.08.09)
IP Port 2: 192.168.21.111 > Verbindung zu PC B
IP Port 3: 192.168.60.1 > Verbindung zu Router A
Bedienungsanleitung: http://www.funkwerk-ec.com/portal/downloadcenter/dateien/r1200/doku/man ...
Alle Verbindungen sind FastEthernet mittels Twisted-Pair-Leitungen.
Das Routing funktioniert einwandfrei. PC A und PC B können sich jeweils problemlos „anpingen“.
Nun zum Problem:
Es soll die interne SIF (Stateful Inspection Firewall) genutzt werden um die Kommunikation auf ICMP und TCP/UDP Port 8001 bis 8004 sowie TCP/UDP Port 40001 – 40002 zu beschränken. Außerdem darf diese Kommunikation nur zwischen PC A (bzw. dessen IP) und PC B (bzw. dessen IP) und andersherum stattfinden. Alle anderen IPs sollen vollständig geblockt werden.
Momentan habe ich die Möglichkeit beide Router sowohl über Telnet- als auch über deren eigene Weboberfläche zu konfigurieren. Einfachheitshalber habe ich bis jetzt über die grafische Weboberfläche konfiguriert, da ich kaum Konfigurationsbefehle für die BinTec-Geräte kenne.
Die Firewall-Einstellungen gliedern sich in drei relevante Unterpunkte:
- Richtlinien
- Adressen
- Dienste
Bei „Richtlinien“ werden die einzelnen Regeln festgelegt, welche Quell-Adressen mit welchen Ziel-Adressen über welche Dienste (& Ports bei TCP/UDP) kommunizieren dürfen.
Zu diesem Zweck werden vorher im Unterpunkt „Adressen“ alle für die Kommunikation benötigten Adressen eingetragen.
Außerdem werden im Unterpunkt „Dienste“ die relevanten Dienste (& Ports bei TCP/UDP) erstellt.
Meine momentane Konfiguration (von unten nach oben):
Dienste:
ICMP (jegliche Typen, siehe Internet Control Message Protocol ? Wikipedia )
TCP/UDP (Port 8001 bis 8004)
TCP/UDP (Port 40001 bis 40002)
Adressen:
192.168.21.11 / 255.255.255.0
192.168.80.111 / 255.255.255.0
Richtlinien:
Quelle Ziel Dienst Aktion
192.168.21.11 192.168.80.111 ICMP Zugriff
192.168.21.11 192.168.80.111 TCP/UDP (P. 8001-8004) Zugriff
192.168.21.11 192.168.80.111 TCP/UDP (P. 40001-40002) Zugriff
192.168.80.111 192.168.21.11 ICMP Zugriff
192.168.80.111 192.168.21.11 TCP/UDP (P. 8001-8004) Zugriff
192.168.80.111 192.168.21.11 TCP/UDP (P. 40001-40002) Zugriff
Alle Quell- und Ziel-Adressen haben die Subnetzmaske 255.255.255.0
Laut der Bedienungsanleitung des Routers sind alle nicht explizit zugelassenen Verbindungen grundsätzlich gesperrt. Somit dürfte es nicht nötig sein alle sonstigen Dienste bzw. Ports über alle sonstigen IPs manuell als blockiert einzutragen.
Wenn ich die Firewall nun mit der beschriebenen Konfiguration einschalte, ist kein Ping mehr zwischen PC A und PC B (und andersherum) möglich.
Aber: bei folgender Konfiguration gelingt der Ping-Test:
Quelle Ziel Dienst Aktion
F/E 2 F/E 3 ICMP Zugriff
F/E 2 F/E 3 TCP/UDP (P. 8001-8004) Zugriff
F/E 2 F/E 3 TCP/UDP (P. 40001-40002) Zugriff
F/E 3 F/E 2 ICMP Zugriff
F/E 3 F/E 2 TCP/UDP (P. 8001-8004) Zugriff
F/E 3 F/E 2 TCP/UDP (P. 40001-40002) Zugriff
Allerdings stellt letztere Konfiguration ja ein Sicherheitsrisiko dar, weil so jegliche Quell- und Ziel-IPs über die genannten aufgeführten Ports (+ ICMP) kommunizieren dürfen.
Habt ihr eine Idee wo die Ursache dafür liegen kann, dass bei der Angabe der konkreten Adressen die Firewall den Ping blockt?
Sorry für die unübersichtlichen Richtlinien - der Editor hier kennt leider weder Tabs noch mehrmalige Blanks.
Vielen Dank im Voraus!
Gruß,
Kolja
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: 128003
Url: https://administrator.de/contentid/128003
Printed on: April 20, 2024 at 08:04 o'clock
8 Comments
Latest comment
Hallo,
also über die Web-Oberfläche kenne ich mich da auch nicht aus.
Aber ich würde mich an deiner Stelle per Telnet mit dem Router verbinden und dort "debug all" eingeben.
Dann solltest du alle Meldungen sehen und dir fällt hoffentlich direkt auf was falsch läuft.
Ansonsten arbeitet ein funkwerk-Router weniger mit Befehlen als dem Setup-Tool.
Dieses ruft du per Telnet mit "setup" auf.
Auch verstehe ich deine Darstellung nicht, was heißt den "F/E 3 F/E 2 ICMP Zugriff" ???
Ach so, den Debug beendest du mit Strg+c
VG
deepsys
also über die Web-Oberfläche kenne ich mich da auch nicht aus.
Aber ich würde mich an deiner Stelle per Telnet mit dem Router verbinden und dort "debug all" eingeben.
Dann solltest du alle Meldungen sehen und dir fällt hoffentlich direkt auf was falsch läuft.
Ansonsten arbeitet ein funkwerk-Router weniger mit Befehlen als dem Setup-Tool.
Dieses ruft du per Telnet mit "setup" auf.
Auch verstehe ich deine Darstellung nicht, was heißt den "F/E 3 F/E 2 ICMP Zugriff" ???
Ach so, den Debug beendest du mit Strg+c
VG
deepsys
Das mit dem debug-Befehl werde ich gleich probieren, dafür schonmal vielen Dank ;)
In dem Setup über Telnet war ich auch schon, hat mir allerdings leider auch nicht weiter geholfen ^^.
Ja, die Darstellung ist aufgrund der verkehrten Formatierung etwas missglückt, das gebe ich zu. Die fett geschriebenen Begriffe "Quelle", "Ziel", "Dienst" und "Aktion" sind als Überschriften zu verstehen. Somit wäre "F/E 3" (FastEthernet 3) die Quelle, "F/E 2" (FastEthernet 2) das Ziel, "ICMP" der Dienst und "Zugriff" die Aktion. Vielleicht so verständlich:
Quelle: F/E 3 (FastEthernet 3)
Ziel: F/E 2 (FastEthernet 2)
Dienst: ICMP
Aktion: Zugriff
Vielen Dank
Gruß,
Kolja
In dem Setup über Telnet war ich auch schon, hat mir allerdings leider auch nicht weiter geholfen ^^.
Ja, die Darstellung ist aufgrund der verkehrten Formatierung etwas missglückt, das gebe ich zu. Die fett geschriebenen Begriffe "Quelle", "Ziel", "Dienst" und "Aktion" sind als Überschriften zu verstehen. Somit wäre "F/E 3" (FastEthernet 3) die Quelle, "F/E 2" (FastEthernet 2) das Ziel, "ICMP" der Dienst und "Zugriff" die Aktion. Vielleicht so verständlich:
Quelle: F/E 3 (FastEthernet 3)
Ziel: F/E 2 (FastEthernet 2)
Dienst: ICMP
Aktion: Zugriff
Vielen Dank
Gruß,
Kolja
Hi,
ach so.
Mit ist gerade noch was aufgefallen.
Du willst doch nur die eine Adressen erlauben, oder ??
Dan wäre 192.168.21.11 / 255.255.255.0 falsch, es müsste 192.168.21.11 / 255.255.255.255 (oder /32) sein.
VG
Markus
ach so.
Mit ist gerade noch was aufgefallen.
Du willst doch nur die eine Adressen erlauben, oder ??
Dan wäre 192.168.21.11 / 255.255.255.0 falsch, es müsste 192.168.21.11 / 255.255.255.255 (oder /32) sein.
VG
Markus
Richtig, was Deepsys anmerkt ist korrekt ! Deine Subnetzmaske stimmt bei einem Host Filter nicht, denn die die muss in der tat 32 Bit lang sein.
Was nochvollkommen unklar ist an der Beschreibung ist das bei jedem handelsüblichen Router du :
Zu diesen beiden, für eine ACL, essentiellen Fragen äußerst du dich gar nicht bzw. gibt auch die o.a. Konfig keinerlei Hinweise
Nur mal so als Beispiel wie das bei einem Cisco Router gelöst ist mit deiner IP Adressierung:
Router A:
interface Ethernet 0
description Routerverbindung A -> B
ip address 192.168.60.2 255.255.255.0
!
interface Ethernet 1
description Lokales Ethernet LAN A
ip address 192.168.80.121 255.255.255.0
ip access-group 103 in
access-list 103 permit icmp host 192.168.80.111 host 192.168.21.11
access-list 103 permit tcp host 192.168.80.111 host 192.168.21.11 range 8001 8004
access-list 103 permit tcp host 192.168.80.111 host 192.168.21.11 range 40001 40002
access-list 103 deny ip any any
OK, logisch zu verstehen: Die ACL Nummer 103 erlaubt ICMP und TCP Traffic zwischen den Hosts 192.168.80.111( Quelle) und 192.168.21.11 (Ziel) wie definiert und die ACL Nummer 103 ist auf dem LAN Interface eingehend (in) gemeint.
Der Parameter host steht für eine 32 Bit Maske ist also analog zur Konfig Zeile "access-list 103 permit icmp 192.168.80.111 255.255.255.255 192.168.21.11 255.255.255.255" )
Alles logisch verständlich, sauber den Interfaces zugeordnet und funktioniert auch so wunderbar !
Analog dazu dann die andere Seite:
Router B:
interface Ethernet 0
description Routerverbindung B -> A
ip address 192.168.60.1 255.255.255.0
!
interface Ethernet 1
description Lokales Ethernet LAN B
ip address 192.168.21.111 255.255.255.0
ip access-group 103 in
access-list 103 permit icmp host 192.168.21.11 host 192.168.80.111
access-list 103 permit tcp host 192.168.21.11 host 192.168.80.111 range 8001 8004
access-list 103 permit tcp host 192.168.21.11 host 192.168.80.111 range 40001 40002
access-list 103 deny ip any any
Auch einfach und logisch zu verstehen diese ACL und funktioniert ebenso wunderbar !!
Analog müsste das doch so auch auf dem Bintec umsetzbar sein, oder ??
Was nochvollkommen unklar ist an der Beschreibung ist das bei jedem handelsüblichen Router du :
- a.) angeben musst auf WELCHEM Interface und...
- b.) angeben musst ob auf diesem Interface die Accessliste inbound (eingehend) oder (outbound) ausgehend gelten soll ?!
Zu diesen beiden, für eine ACL, essentiellen Fragen äußerst du dich gar nicht bzw. gibt auch die o.a. Konfig keinerlei Hinweise
Nur mal so als Beispiel wie das bei einem Cisco Router gelöst ist mit deiner IP Adressierung:
Router A:
interface Ethernet 0
description Routerverbindung A -> B
ip address 192.168.60.2 255.255.255.0
!
interface Ethernet 1
description Lokales Ethernet LAN A
ip address 192.168.80.121 255.255.255.0
ip access-group 103 in
access-list 103 permit icmp host 192.168.80.111 host 192.168.21.11
access-list 103 permit tcp host 192.168.80.111 host 192.168.21.11 range 8001 8004
access-list 103 permit tcp host 192.168.80.111 host 192.168.21.11 range 40001 40002
access-list 103 deny ip any any
OK, logisch zu verstehen: Die ACL Nummer 103 erlaubt ICMP und TCP Traffic zwischen den Hosts 192.168.80.111( Quelle) und 192.168.21.11 (Ziel) wie definiert und die ACL Nummer 103 ist auf dem LAN Interface eingehend (in) gemeint.
Der Parameter host steht für eine 32 Bit Maske ist also analog zur Konfig Zeile "access-list 103 permit icmp 192.168.80.111 255.255.255.255 192.168.21.11 255.255.255.255" )
Alles logisch verständlich, sauber den Interfaces zugeordnet und funktioniert auch so wunderbar !
Analog dazu dann die andere Seite:
Router B:
interface Ethernet 0
description Routerverbindung B -> A
ip address 192.168.60.1 255.255.255.0
!
interface Ethernet 1
description Lokales Ethernet LAN B
ip address 192.168.21.111 255.255.255.0
ip access-group 103 in
access-list 103 permit icmp host 192.168.21.11 host 192.168.80.111
access-list 103 permit tcp host 192.168.21.11 host 192.168.80.111 range 8001 8004
access-list 103 permit tcp host 192.168.21.11 host 192.168.80.111 range 40001 40002
access-list 103 deny ip any any
Auch einfach und logisch zu verstehen diese ACL und funktioniert ebenso wunderbar !!
Analog müsste das doch so auch auf dem Bintec umsetzbar sein, oder ??
Vielen Dank für eure Antworten!
Habe auf euren Rat hin die Subnetzmasken korrigiert und siehe da: Der Ping geht durch =). Dass es Sinn macht, per Subnetzmaske 255.255.255.255 den Hostanteil pro Subnetz auf 1 zu begrenzen, leuchtet mir ein.
Allerdings müsste doch auch bei einem Hostanteil von 256 (also bei der Subnetzmaske 255.255.255.0) der Ping durchgehen, oder nicht? Mal abgesehen davon, dass dann auch andere Hosts in dem Subnetz pingen können dürften - was natürlich vermieden werden sollte.
Tatsächlich kann man nur entweder ein Interface als Quelle bzw. Ziel angeben oder eine IP - allerdings nicht eine bestimmte IP an/über ein bestimmtes Interface. Zumindest habe ich keinerlei Möglichkeit dafür gefunden.
Ob die ACL inbound oder outbound gelten soll, scheint mir auch nirgends einstellbar zu sein.
Habe auf euren Rat hin die Subnetzmasken korrigiert und siehe da: Der Ping geht durch =). Dass es Sinn macht, per Subnetzmaske 255.255.255.255 den Hostanteil pro Subnetz auf 1 zu begrenzen, leuchtet mir ein.
Allerdings müsste doch auch bei einem Hostanteil von 256 (also bei der Subnetzmaske 255.255.255.0) der Ping durchgehen, oder nicht? Mal abgesehen davon, dass dann auch andere Hosts in dem Subnetz pingen können dürften - was natürlich vermieden werden sollte.
Tatsächlich kann man nur entweder ein Interface als Quelle bzw. Ziel angeben oder eine IP - allerdings nicht eine bestimmte IP an/über ein bestimmtes Interface. Zumindest habe ich keinerlei Möglichkeit dafür gefunden.
Ob die ACL inbound oder outbound gelten soll, scheint mir auch nirgends einstellbar zu sein.
Wichtig ist es aber schon zu wissen WO an welchem Interface und in WELCHER Richtung die ACL wirken soll, sonst ist eine ACL doch logischerweise vollkommen sinnlos und auch ein Sicherheitsrisiko wenn man als Benutzer nicht mal weiss WO sie wirkt !
Das gilt auch für Bintec !
Zu deiner Anmerkung mit der 24 Bit Maske:
Ja, generell hast du Recht allerdings ist eine Angabe wie "192.168.21.11 255.255.255.0" dann aber Blödsinn, denn allein schon die IP Adresse 192.168.21.11 zeigt an des es sich hier um eine Host IP Adresse handelt die dann eine 32 Bit Maske erzwingt.
Bei einer 24 Bit ACL Maske müsste man logischerweise das IP Netzwerk selber angeben was dann logischerweise 192.168.21.0 lautet. Niemals aber eine Hostadresse wie die obige in diesem Netz, denn damit ist die ACL dann in sich unlogisch und somit falsch !
192.168.21.0 255.255.255.0 wäre dann also der richtige ACL Eintrag wenn du alle IP Hostadressen von 192.168.21.1 bis 192.168.21.254 durch die ACL erlauben willst !!
So wird ein (ACL) Schuh draus !
Das gilt auch für Bintec !
Zu deiner Anmerkung mit der 24 Bit Maske:
Ja, generell hast du Recht allerdings ist eine Angabe wie "192.168.21.11 255.255.255.0" dann aber Blödsinn, denn allein schon die IP Adresse 192.168.21.11 zeigt an des es sich hier um eine Host IP Adresse handelt die dann eine 32 Bit Maske erzwingt.
Bei einer 24 Bit ACL Maske müsste man logischerweise das IP Netzwerk selber angeben was dann logischerweise 192.168.21.0 lautet. Niemals aber eine Hostadresse wie die obige in diesem Netz, denn damit ist die ACL dann in sich unlogisch und somit falsch !
192.168.21.0 255.255.255.0 wäre dann also der richtige ACL Eintrag wenn du alle IP Hostadressen von 192.168.21.1 bis 192.168.21.254 durch die ACL erlauben willst !!
So wird ein (ACL) Schuh draus !
Wichtig ist es aber schon zu wissen WO an welchem Interface und in WELCHER Richtung die ACL wirken soll, sonst ist eine ACL doch logischerweise vollkommen sinnlos und auch ein Sicherheitsrisiko wenn man als Benutzer nicht mal weiss WO sie wirkt !
Das gilt auch für Bintec !
Jo, da gebe ich dir Recht. Vielleicht verhält sich das bei dieser Stateful Inspection Firewall, die in diesem BinTec-Router verbaut ist, etwas anders.
Zu deiner Anmerkung mit der 24 Bit Maske:
Ja, generell hast du Recht allerdings ist eine Angabe wie "192.168.21.11 255.255.255.0" dann aber Blödsinn, denn allein schon die IP Adresse 192.168.21.11 zeigt an des es sich hier um eine Host IP Adresse handelt die dann eine 32 Bit Maske erzwingt.
Bei einer 24 Bit ACL Maske müsste man logischerweise das IP Netzwerk selber angeben was dann logischerweise 192.168.21.0 lautet. Niemals aber eine Hostadresse wie die obige in diesem Netz, denn damit ist die ACL dann in sich unlogisch und somit falsch !
192.168.21.0 255.255.255.0 wäre dann also der richtige ACL Eintrag wenn du alle IP Hostadressen von 192.168.21.1 bis 192.168.21.254 durch die ACL erlauben willst !!
So wird ein (ACL) Schuh draus !
Alles klar, danke für die Aufklärung =)
Das gilt auch für Bintec !
Jo, da gebe ich dir Recht. Vielleicht verhält sich das bei dieser Stateful Inspection Firewall, die in diesem BinTec-Router verbaut ist, etwas anders.
Zu deiner Anmerkung mit der 24 Bit Maske:
Ja, generell hast du Recht allerdings ist eine Angabe wie "192.168.21.11 255.255.255.0" dann aber Blödsinn, denn allein schon die IP Adresse 192.168.21.11 zeigt an des es sich hier um eine Host IP Adresse handelt die dann eine 32 Bit Maske erzwingt.
Bei einer 24 Bit ACL Maske müsste man logischerweise das IP Netzwerk selber angeben was dann logischerweise 192.168.21.0 lautet. Niemals aber eine Hostadresse wie die obige in diesem Netz, denn damit ist die ACL dann in sich unlogisch und somit falsch !
192.168.21.0 255.255.255.0 wäre dann also der richtige ACL Eintrag wenn du alle IP Hostadressen von 192.168.21.1 bis 192.168.21.254 durch die ACL erlauben willst !!
So wird ein (ACL) Schuh draus !
Alles klar, danke für die Aufklärung =)
Bitte, bitte, dafür ist ein Forum ja da...
Wenns das nun war bitte dann auch
How can I mark a post as solved?
nicht vergessen ??
P.S.: "Vielleicht verhält sich das bei dieser Stateful Inspection Firewall, die in diesem BinTec-Router verbaut ist, etwas anders..."
Nein, das ist da auch nicht anders denn diese Handlungsweise gibt die grundlegende Logik von ACLs ja vor, egal ob Bintec, Billig aus Taiwan oder wer auch immer.
Bintec denkt wohl das es diese Tatsache seinen Usern nicht erklären muss oder will...den Rest kann man sich dann denken !
Wenns das nun war bitte dann auch
How can I mark a post as solved?
nicht vergessen ??
P.S.: "Vielleicht verhält sich das bei dieser Stateful Inspection Firewall, die in diesem BinTec-Router verbaut ist, etwas anders..."
Nein, das ist da auch nicht anders denn diese Handlungsweise gibt die grundlegende Logik von ACLs ja vor, egal ob Bintec, Billig aus Taiwan oder wer auch immer.
Bintec denkt wohl das es diese Tatsache seinen Usern nicht erklären muss oder will...den Rest kann man sich dann denken !
