Hallo,
ich habe hier eine 1721. Diese Firewall wollte ich im internen Netzwerk so einsetzen, dass ich hier 3 verschiedene LANs zur Verfügung habe. In der 1721 sind zwei Netzwerke schon konfiguriert
- Intranet (Eth-1)
- DMZ (Eth-2)
Jetzt hatte ich den Ethernetanschluss 3 auch aktiviert. Ich habe folgendes gemacht:
Unter Schnittstellen - LAN - Ehternet-Ports - ETH 3 ausgewählt und dort die Interface Verwendung auf LAN-3 gestellt. Den Rest so gelassen.
Dann unter TCP/IP - Allgemein - IP-Netzwerke ein neues Netzwerk hinzugefügt:
Netzwerkname: Verwaltung
IP-Adresse: 192.168.2.254
Netzmasle: 255.255.255.0
Netzwerktyp: Intranet
VLAN-ID: 0
Schnittstellen-Zuordnung LAN-3
Adressprüfung: Flexibel
Schnittstellen-Tag: 0
Die Firewall ist z.Z. leer. Ich kann alles von Eth-1 (Intranet) zu Eth-2 (DMZ) und umgekehrt. Keine Kommunikation ist weder von Eth-1 oder Eth-2 zu Eth-3 (Verwaltung) möglich.
Wo liegt mein Fehler? Hab ich etwas vergessen zu konfigurieren?
Einen dritten LAN-Anschluss hinzufügen
Moderator: Lancom-Systems Moderatoren
Hi RalphT,
eigentlich muß das so funktionieren, wei du es konfiguriert hast - oder hast du dem Intranet und der DMZ ein Interface-Tag gegeben? Eine ganz dumme Frage: Das Verwaltungs-Netz nutzt aber schon andere Adressen, als Intranet und DMZ? Und die PCs im Verwaltungs-Netz wissen auch, daß das 1721 ihr Gateway ist?
Gruß
Backslash
eigentlich muß das so funktionieren, wei du es konfiguriert hast - oder hast du dem Intranet und der DMZ ein Interface-Tag gegeben? Eine ganz dumme Frage: Das Verwaltungs-Netz nutzt aber schon andere Adressen, als Intranet und DMZ? Und die PCs im Verwaltungs-Netz wissen auch, daß das 1721 ihr Gateway ist?
Gruß
Backslash
Erst mal Danke für die Antwort.
Da Du ja gschrieben hattest, dass es eigentlich funktionieren müsste, hatte ich mich auf die Standarddinge konzentriert.
Zuerst hatte ich ein anderes NB angeschlossen. Der Ping lief allerdings nur einseitig. Schnelle hatte ich bemerkt, dass hier noch die Windows-Firewall wirkte. Firewall abgeschaltet und das NB funktionierte.
Anschließend zu meinen NB im Verwaltungsnetz. Ich hatte das Gateway mehrmal kontrolliert. Als ich zum x.ten mal das nochmal kontrollierte (mit IPCONFIG /ALL) ist mir der Fehler erst aufgefallen: Ich habe auf dem NB VMware installiert. VMware hat hier noch 2 virtuelle Netzwerkkarten installiert. Davon war eine im Subnetz 192.168.16.x vorhanden. Eine Änderung in ein anderes Subnetz brachte den gewünschten Erfolg
Zum Schluss doch eine Frage:
Ich habe in der Lancom die Firewall mit einer Regel DENY_ALL bestückt. Alle Rechner im Testnetz pingen sich gegenseitig an. Nachdem ich die Regel hochgeladen habe, erwartet ich eigentlich, dass jetzt jeder Client sich in etwa so meldet: Antwort von 192.168.16.254: Zielhost nicht erreichbar
Nein stattdesssen funktionieren alle Pings noch weiter.
Wenn ich den Ping abbreche und auf einen Rechner pinge den es nicht gibt, dann kommt erst die o.g. Meldung. Pinge dann wieder den Rechner an, der auch vorhanden ist, dann kommt die Meldung Zielhost nicht erreichbar.
Ist nicht weiter schlimm, aber was kann das sein? Wechsel ich den Rechner nicht und lasse in munter weiterpingen, kommt immer eine Antwort.
Vielleicht kann mir ja mal einer dieses Phänomen erklären.
Da Du ja gschrieben hattest, dass es eigentlich funktionieren müsste, hatte ich mich auf die Standarddinge konzentriert.
Zuerst hatte ich ein anderes NB angeschlossen. Der Ping lief allerdings nur einseitig. Schnelle hatte ich bemerkt, dass hier noch die Windows-Firewall wirkte. Firewall abgeschaltet und das NB funktionierte.
Anschließend zu meinen NB im Verwaltungsnetz. Ich hatte das Gateway mehrmal kontrolliert. Als ich zum x.ten mal das nochmal kontrollierte (mit IPCONFIG /ALL) ist mir der Fehler erst aufgefallen: Ich habe auf dem NB VMware installiert. VMware hat hier noch 2 virtuelle Netzwerkkarten installiert. Davon war eine im Subnetz 192.168.16.x vorhanden. Eine Änderung in ein anderes Subnetz brachte den gewünschten Erfolg
Zum Schluss doch eine Frage:
Ich habe in der Lancom die Firewall mit einer Regel DENY_ALL bestückt. Alle Rechner im Testnetz pingen sich gegenseitig an. Nachdem ich die Regel hochgeladen habe, erwartet ich eigentlich, dass jetzt jeder Client sich in etwa so meldet: Antwort von 192.168.16.254: Zielhost nicht erreichbar
Nein stattdesssen funktionieren alle Pings noch weiter.
Wenn ich den Ping abbreche und auf einen Rechner pinge den es nicht gibt, dann kommt erst die o.g. Meldung. Pinge dann wieder den Rechner an, der auch vorhanden ist, dann kommt die Meldung Zielhost nicht erreichbar.
Ist nicht weiter schlimm, aber was kann das sein? Wechsel ich den Rechner nicht und lasse in munter weiterpingen, kommt immer eine Antwort.
Vielleicht kann mir ja mal einer dieses Phänomen erklären.
Hi RalphT
die Erklärung dafür ist recht simpel: Das LANCOM schaut nur beim ersten Paket einer Session in die Firewall-Regeln. Sobald diese die Session zulassen, wird nur noch mit dem Session-Eintrag gearbeitet. Wenn du also bei einer laufenden Session (hier also den pings) die Deny-All-Regel hinzufügst, hat diese nur einen Einfluß auf neue Sessions - die alten, einmal erlaubten, laufen einfach weiter.
Gruß
Backslash
Zum Schluss doch eine Frage:
Ich habe in der Lancom die Firewall mit einer Regel DENY_ALL bestückt. Alle Rechner im Testnetz pingen sich gegenseitig an. Nachdem ich die Regel hochgeladen habe, erwartet ich eigentlich, dass jetzt jeder Client sich in etwa so meldet: Antwort von 192.168.16.254: Zielhost nicht erreichbar
Nein stattdesssen funktionieren alle Pings noch weiter.
Wenn ich den Ping abbreche und auf einen Rechner pinge den es nicht gibt, dann kommt erst die o.g. Meldung. Pinge dann wieder den Rechner an, der auch vorhanden ist, dann kommt die Meldung Zielhost nicht erreichbar.
Ist nicht weiter schlimm, aber was kann das sein? Wechsel ich den Rechner nicht und lasse in munter weiterpingen, kommt immer eine Antwort.
Vielleicht kann mir ja mal einer dieses Phänomen erklären.
die Erklärung dafür ist recht simpel: Das LANCOM schaut nur beim ersten Paket einer Session in die Firewall-Regeln. Sobald diese die Session zulassen, wird nur noch mit dem Session-Eintrag gearbeitet. Wenn du also bei einer laufenden Session (hier also den pings) die Deny-All-Regel hinzufügst, hat diese nur einen Einfluß auf neue Sessions - die alten, einmal erlaubten, laufen einfach weiter.
Gruß
Backslash