Securepoint Manager und die explorer.exe

[M Goeres]

Hallo Support,
sry heute schreibe ich mir so einiges der letzten Wochen von der Seele und darunter faellt auch die aktuelle Version des SP-Managers.
An "boesen" Tagen muss ich 2-3 mal den Rechner neustarten, wenn ich mehrere Appliances parallel (VPN-Konfig) oder getrennt konfiguriert habe.

Nach z.B. "Speichern" geht die Explorer.exe des Systems an die Decke und nichts geht mehr.....doch ausschalten, da auch abwarten nichts bringt.

Gleiches des oefteren beim Realtime-Monitoring.....Plattenaktivitaet bis zur Decke....System steht....und keine Moeglichkeit ausser der Ausschalter = Dampfhammer fuers OS (XP SP2 mit aktuellem Patchstand *raeusper*).

Auch bei der VPN-Konfiguration kommen immer wieder "dolle" Sachen.
Appliance A connected. Appliance B auch. VPN konfiguriert und aktualisiert = Alles Super.
Komisch wird es z.B. beim Regelwerk:

- Von B nicht abgemeldet, zeigt ein leeres Regelwerk.
- A ist aber OK

Mhhh...mal alle "disconnecten"

Ergebnis A =OK
Ergebnis B = Leer *gruebel*

SP-Manager neu gestartet und direkt zum "Problemkind" = OK

Da laeuft auch noch was "quer"....

Gruss

M.Goeres

[carsten]

Hallo,

ja da scheint noch was schief zu laufen. Um das Problem aber erst einmal zu umgehen das Regelwerk seperat von dem VPN konfigurieren!

FW1 anmelden: Regelwerk erstellen -> Speichern
FW1 abmelden:
FW2 anmelden: Regelwerk erstellen -> Speichern

Jetzt die beiden FWs auf die VPN-Karte ziehen und auf "Alle Verbinden" klicken. Danach kann das VPN eingerichtet werden.

Im R3 wird auch einen neue Konfiguratin des VPNs implementiert werden. Wir hoffen es wird damit etwas besser.

Zum Logclient:

Ich habe seit den 4 Monaten im Support noch nie mein Windows neu starten müssen weil mein System nicht mehr wollte und ich habe zum Teil bis zu 10 Logclients gleichzeitig geöffnet. Klar hab ich da auch mal 100% Systemlast aber der gute alte Task-Manager löst auch das Problem

Noch ein Tipp bei zu vielen Logmeldung. Setzen sie hier unbedingt einen Filter im Logclient: Erweitert -> Aktiv + Invertiert;
Suchspalte=Dienst;
Suchmuster="Proxy" -> ok

Dies filtert alle Proxy-Dienst heraus! :roll:

[M Goeres]

Hut ab, aber arbeiten sie parallel noch mit anderen Applikationen?

4 Monate ohne Probleme finde ich Rekord-Verdaechtig.

Zwischendurch bleibt das Status-Fenster "pappen" und muss per Taskmanager getoetet werden (Ursache zuviel Traffic zum Log-Client oder DB voll)

Das ich filtern kann ist mir bewusst.....ganz sicher.....(btw. invertiert geht das im Spaminterface auch nicht)....aber was hilft es?!

Ich warte dann mal auf die R3 und den neuen Manager (der sicher kommen wird).....denn das Release scheint schon sehr nah zu sein, wenn bereits von R4 und R5 "gemunkelt" wird.

Gruss

M.Goeres

[A. Rietz]

Nabend alle zusammen,

da kann ich mich nur dem Herrn Goeres anschließen!
Bei mir muss im Verlauf von 2 Std. mehrmals der SSM neu gestartet werden. Dabei ist es egal ob auf einem Server BS oder auf einem Client, egal ob bei der Konfiguration von einer SP oder von der VPN Konfiguration.
Dies tritt auch auf wenn das logging nicht aktiviert ist.

Wir hoffen auf Besserung in der R3. (In der Hoffnung das das nicht mehr alzu lang dauert)

Grüße
Dallas

[carsten]

Hallo,

natürlich arbeit ich noch mit anderen Anwendungen. Mein windows läuft sogar nur in einer VirtuellMaschine und bekommt von meinem GastSystem sogar nur 512MB Ram.

[M Goeres]

Jo dann mach ich das auch mal.

Ne kleine VMWare und entsprechend nur die Securepoint-Tools rein.
Wenns dann lueppt, habe ich zwar ein Problem weniger, aber denke das dies auch keine wirkliche Problemloesung sein kann.

Gruss

M.Goeres

[carsten]

Benutze VirtualBox

[achim]

also, wenn's denn ums "bug"-listing geht - just my 2cents:

ich arbeite zwangsweise auch sehr viel mit dem ssm und habe auch des öfteren probleme.

zuerst: der ssm hat bei mir noch nie irgendein hostsysteme lahmgelegt. :shock:

probleme mit dem ssm gibt es jedoch häufiger insbesondere bei der arbeit mit "F to F" vpn's und den "alten" roten appliances:
(beim arbeiten mit vpn)
- ich bin angemeldet an fw.123.local (grün hinterlegt) und öffne den log-client, gehe dann auf die vpn-seite und melde mich dort ebenso an fw.456.local an (ist nun gelb hinterlegt), um die "F to F" verbindung zu bearbeiten -> folge: manchmal (!) ist sehe ich nun im log-client die logs von fw.456.local
- ebenso verhält es sich mit der rulebase etc. mal bleibt es dabei, dass die einstellungen von fw.123.local angezeigt werden, mal aber nicht...
- spannender wird es hierbei, wenn man nun die einstellungen des veränderten vpn-tunnels abspeichert und sich spätestens beim nächsten einloggen auf der appliance fragt, auf welcher firewall wurde nun welche vpn-einstellung gespeichert: der tunnel steht evtl. noch, aber beim öffnen der verbindung ist eine seite leer ...(?)
- wenn mit so einer leeren anzeige zu kämpfen ist, erscheint diese firewall in der "liste" auf einmal mit dem roadwarrior-symbol

(alte rote boxen - ich glaube zumindest, dies auf die "alten beschränken zu können" )
- bei den "alten" roten boxen insbesondere den piranjas scheint ein unbekannter timeout zu existieren, da der ssm in unregelmäßigen abständen meldet: die verbindung wurde unterbrochen, melden sie sich bitte erneut an...
- auch spannend: beim ersten einlesen der lizenz trennt der ssm einfach die verbindung und erst beim zweiten anmelden und einlesen der lizenz wird man mit erfolg belohnt.
- das gleiche phänomen tritt beim einlesen einer (aktuell gepatchten) konfigurationsdatei in eine jungfäuliche appliance auf: speichern als "ichweissdasklapptnicht" -> verbindung unterbrochen -> anmelden speichern als "nunaber" -> danke, jetzt habe ich gespeichert...


wirklich ärgerlich (ich habe mich schon öfter beherrscht und nicht die "roten", sondern nur die "silbernen frisbees" an die wand geschmissen) ist jedoch:

jungfräuliche appliance -> (aktuell gepatchten) konfigurationsdatei einlesen -> neustart -> anmelden per ssm geht nicht oder meldet etwas von "namensproblemen" -> anmelden an der cli (...ewig warten) -> herzlich willkommen, sie sind angemeldet an "i.have.no.name" -> hilft nur noch ??? halt irgendetwas anderes probieren...

ok, vielleicht war ja die konf-datei im ...... -> default konf laden - "i.have.schonwieder.no.name"

also, vielleicht stimmte ja der patchlevel der appliance nicht -> neuinstallation mit aktuellem iso-image -> usw. -> i.have...

abschließend ist hierzu zu sagen, dass mal dass neuinstallieren der firewall und das einspielen der konfiguration geholfen hat oder auch mal eine andere kombination. des weiteren tritt das problem nur bei den "roten" auf, und nie bei eigener hardware! Manchmal hilft aber auch nur das verwerfen der konf-datei und die komplette neuinstallation - aber man ist ja geübt und mit einer guten kundendoku gesegnet und das ist ja schnell getan... :x

achim

PS: die status.dll kennt wohl jeder :roll:

[Mario]

Das Problem mit dem Verbindungsabbruch beim Einspielen einer Lizenz auf einer frisch installierten Firewall (tritt nur mit bestimmten Lizenzdateien auf, aber dann reproduzierbar) ließ sich bereits nachstellen.

Das Problem mit dem: "i have no name" ebenfalls, dies tritt bei korrupten Konfigurationsdateien auf. Erkennbar sind korrupte Konfigurationsdateien ohne Weiters daran, das sich die Groesse jedesmal unterscheidet, sobald man sie neu exportiert. Mit einer aktuellen Version unserer Firewall und dem aktuellen Manager habe ich dieses Problem aber nicht mehr bemerkt.

Man kann sich in diesem Fall die Datenbanken von der Firewall direkt herunterladen, und sie dann manuell auf der neuen Firewall hochladen. (sftp) Zuvor muss jedoch ein Root-Account bei beiden Firewalls angelegt werden, da man die Datenbanken nicht direkt importieren/exportieren kann. es wird ausserdem bereits an einem Programm gearbeitet, womit sich die Datenbanken direkt herunterladen lassen.

[achim]

danke für den tipp mit dem datenbank-export. ich werde es testen, falls ich mal wieder ein solches problem habe.

wäre es denn nicht möglich, solche bei ihnen bekannten probleme und lösungen irgendwie zu posten (ins forum, in ein user-only/partner-only-forum oder per partner-newsletter etc.)?

dies würde die motivation der partner/admins stark fördern, weiter auf securepoint (auch mal bei größeren/guten kunden) zu setzen.

natürlich kann man auch bei jedem problem anrufen, aber teilweise muss man auf einen rückruf "einige" zeit warten (und meistens hat man ein problem, wenn man beim kunden ist und der hat keine lust, die wartezeit des dienstleisters zu bezahlen...) oder je nachdem welchen supporter man dran hat, bekommt man eine andere antwort. (bsp.: 3x wird einem erzählt, dass site-to-site vpn mit zwei dyndns-securepoints und PSK nicht funktioniert und beim 4. Mal sagt ein supporter: "na klar geht das, benutzen sie doch... das '@' hier... und dort" )

achim

[achim]

Mir ist das Problem mit dem Importieren einer Konfigurationsdatei wieder untergekommen.
Ich kann nicht sagen, ob das "i.have.no.name"-Phänomen wieder aufgetreten wäre, da ich mich gar nicht anmelden konnte...

Beide Firewalls aktuell gepatcht - ebenso der SSM.
Es sollte lediglich die Hardware ausgetauscht werden (baugleiche Systeme, abgesehen vom Raid-Controller).
Export der Konfiguration ergab immer die selbe Größe. Allerdings hatte die Datenbank nach dem Import eine andere Größe als auf der alten Firewall.

Durch das herunter-/hochladen der Datenbank konnte das Problem umgangen werden:
(Für die, die das selbe Problem haben)

- per sftp als root auf der alten Firewall einloggen und die entsprechende Datenbank aus /database herunterladen.
- per ssh als root auf der neuen Firewall einloggen und für den Schreibzugriff folgendes eingeben:

Code: Alles auswählen

mount -o remount,rw /

- per sftp als root auf der neuen Firewall einloggen und die entsprechende Datenbank in /database hochladen.
- per admin im CLI oder per Bootmenü-Auswahl die neue Datenbank als Standardkonfiguration festlegen.

Achim