Hallo zusammen,
ich habe momentan folgende Zusammenstellung.
Die UTM steht hinter einem Webgate 3 Router von DREI dieser ist auf Bridge gestellt. Und die UTM bezieht die öffentliche IP.
Dies funktioniert auch hervorragend, jedoch muss bei IP wechsel die UTM neu gestartet werden. Kann man hier eventuell noch etwas anpassen?
[Gelöst] UTM hinter Webgate 3 von DREI
Moderator: Securepoint
[Gelöst] UTM hinter Webgate 3 von DREI
LG Neo
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Genau so ist es.
Gerade wieder durchführen müssen. IP wechsel seitens Provider wurde durchgeführt und UTM zeigte an dass ETH0 / LAN1 nicht verbunden sei. Neustart und alles war wieder gut.
Wäre schön wenn es hier seitens Securepoint einen "Trick" geben würde. Fixe IP kann zwar geordert werden ist jedoch nicht wirklich Zielführend, da ich Sie nicht unbedingt benötige.
Gerade wieder durchführen müssen. IP wechsel seitens Provider wurde durchgeführt und UTM zeigte an dass ETH0 / LAN1 nicht verbunden sei. Neustart und alles war wieder gut.
Wäre schön wenn es hier seitens Securepoint einen "Trick" geben würde. Fixe IP kann zwar geordert werden ist jedoch nicht wirklich Zielführend, da ich Sie nicht unbedingt benötige.
LG Neo
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Hallo,
nach einem Gespräch mit dem Securepoint Support konnten wir feststellen dass es sich hierbei um keinen Fehler sondern um eine Sicherheitsrichtlinie handelt welche selbverständlich Sinn macht.
Die neue IP wird von einem anderen Cluster Server vergeben, somit blockt die Firewall den DHCP und bezieht diese nicht. Macht Sinn da ja sonst jeder einfach einen DHCP Ruequest an die Firewall senden könnte und so eventuell dann Daten abgreifen.
Ich hoffe ich konnte dies so halbwegs verständlich ausdrücken
nach einem Gespräch mit dem Securepoint Support konnten wir feststellen dass es sich hierbei um keinen Fehler sondern um eine Sicherheitsrichtlinie handelt welche selbverständlich Sinn macht.
Die neue IP wird von einem anderen Cluster Server vergeben, somit blockt die Firewall den DHCP und bezieht diese nicht. Macht Sinn da ja sonst jeder einfach einen DHCP Ruequest an die Firewall senden könnte und so eventuell dann Daten abgreifen.
Ich hoffe ich konnte dies so halbwegs verständlich ausdrücken
LG Neo
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Hallo Neo,
die Erklärung erscheint mir nicht schlüssig!
Ich dachte immer, das Interface, das per DHCP konfiguriert werden will, sucht per Broadcast nach einem DHCP-Server und bittet diesen dann um Übermittlung der IP-Konfiguration.
DHCPDISCOVER vom Client
DHCPOFFER vom Server
DHCPREQUEST vom Client
DHCPACK vom Server
Deswegen erschließt sich mir momentan nicht, worin das Sicherheitsrisiko besteht und welche Daten abgegriffen werden können, wenn die UTM selbständig detektieren könnte, dass die aktuelle eth0-IP-Konfiguration ins Leere läuft, um sich ggf. neue Konfigurationsdaten von einem (neuen) DHCP-Server (im Cluster) beschaffen zu können.
Vielleicht mag jemand von Securepoint die Sache mal aufklären.
Gruß
Franz
die Erklärung erscheint mir nicht schlüssig!
Ich dachte immer, das Interface, das per DHCP konfiguriert werden will, sucht per Broadcast nach einem DHCP-Server und bittet diesen dann um Übermittlung der IP-Konfiguration.
DHCPDISCOVER vom Client
DHCPOFFER vom Server
DHCPREQUEST vom Client
DHCPACK vom Server
Deswegen erschließt sich mir momentan nicht, worin das Sicherheitsrisiko besteht und welche Daten abgegriffen werden können, wenn die UTM selbständig detektieren könnte, dass die aktuelle eth0-IP-Konfiguration ins Leere läuft, um sich ggf. neue Konfigurationsdaten von einem (neuen) DHCP-Server (im Cluster) beschaffen zu können.
Vielleicht mag jemand von Securepoint die Sache mal aufklären.
Gruß
Franz
Wie genau dies funktioniert kann ich leider nicht sagen.
Die Erklärung vom Support hat sich zumindest logisch angehört. Komischerweise hatte ich heute am SOC in der Firma gesehen dass meine Firewall zuhause offline ging.
Als ich jedoch nach hause gekommen bin war diese wieder online ohne Neustart.
Naja ich habe nun auf jeden Fall eine fixe IP bestellt, werde das Verhalten jedoch weiterhin beobachten.
Die Erklärung vom Support hat sich zumindest logisch angehört. Komischerweise hatte ich heute am SOC in der Firma gesehen dass meine Firewall zuhause offline ging.
Als ich jedoch nach hause gekommen bin war diese wieder online ohne Neustart.
Naja ich habe nun auf jeden Fall eine fixe IP bestellt, werde das Verhalten jedoch weiterhin beobachten.
LG Neo
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Hallo zusammen,
also nun seit 3 Tagen wird die IP automatisch bezogen und die UTM funktioniert einwandfrei.
Wäre echt interessant wieso das so ist.
also nun seit 3 Tagen wird die IP automatisch bezogen und die UTM funktioniert einwandfrei.
Wäre echt interessant wieso das so ist.
LG Neo
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Meine Webprojekt: Stahlstadt Angler
Die Deutsche Sprache ist Freeware und nicht OpenSource!
Das heißt du darfst sie benutzen, aber nicht verändern!
Wenn das Problem wieder mal auftritt, prüfen Sie bitte, wie die externe Schnittstelle in dem Moment konfiguriert ist. Dazu melden Sie sich mit dem root-Benutzer an der Konsole an (per Putty z.b.) und führen dann aus:
Das ganze schicken Sie dann per Mail an support@securepoint.de. Und bitte zensieren Sie keine IPs.
Eine repräsentative (oder so) Umfrage unter den Kollegen hat ergeben, dass solche Symptome mehr oder weniger regelmäßig bei allen Kabel-Anschluss-Besitzern auftauchen. Es war dann so, dass in dem Moment nur eine private IP auf dem externen Interface lag. Und das wiederrum tritt nur auf, wenn das Kabelmodem keine Verbindung mehr zum Provider hat. In dem Fall fängt es dann selber an, IP-Adressen zu verteilen. Bei KDG-Anschlüssen z.b. im Netz 192.168.100.0/24.
Code: Alles auswählen
# ip r
# ip a
# ps faux
# cat /var/lib/dhcp/dhclient4.leases
# cat /var/lib/dhcp/dhclient6.leases
Eine repräsentative (oder so) Umfrage unter den Kollegen hat ergeben, dass solche Symptome mehr oder weniger regelmäßig bei allen Kabel-Anschluss-Besitzern auftauchen. Es war dann so, dass in dem Moment nur eine private IP auf dem externen Interface lag. Und das wiederrum tritt nur auf, wenn das Kabelmodem keine Verbindung mehr zum Provider hat. In dem Fall fängt es dann selber an, IP-Adressen zu verteilen. Bei KDG-Anschlüssen z.b. im Netz 192.168.100.0/24.