Securepoint Support Forum

Christian Beyer hat geschrieben:

cjp hat geschrieben:Und schon sind die nächsten zwei davon betroffen, eine gestern eine heute

Ist ein Update vorgesehen für dieses Problem?

Wann?

Jede Woche beschweren sich immer mehr und mehr Kunden

Hallo cjp,

ja wir arbeiten aktuell an einem Update.
Wurde bereits der CLAMD auf den betroffenen Maschinen deaktiviert ?

Der CLAMD wurde auf allen UTM v11 deaktiviert, zeigte aber keinen Erfolg!
Es ist einfach ärgerlich das die UTMs nach der Reihe "ausfallen"

Eine Lösung wäre dringend notwendig!

Hallo,

dann sollten wir uns einmal Ihre Maschinen anschauen.
Geben Sie mir doch bitte eine Rückmeldung wann es Ihnen am besten passt.

Hallo,
bei mir waren es in der letzten Woche 2x BlachDwarf, 1x RC100.
Ganz aktuell von heute morgen dann die nächste BlackDwarf.

Die Version 11 ist einfach nicht für den Produktivbetrib geeignet.
... Freeze alle 2 Wochen, besch* Spamfilter, IPSec Deamon instabil...

Wie soll das weitergehen??
Wieder auf V10 zurück? Wer zahlt den Einsatz bei den Kunden?
Auf Grund dieser Bugs zahle ich zur Zeit drauf!

MfG
Sebastian Koscholke

Wir haben inzwischen auch zwei Kunden mit dem Problem:
Beim ersten war eine RC300 betroffen, beim zweiten ein Black Dwarf
Versionen sind die aktuellen V11

Einen Kunden von uns hat es auch wieder erwischt.

Firmware: v11.3.1.2
Hardware: Black Dwarf, v10 Hardware (Mai 2012)

An die Anmeldemaske vom Web-Interface kommt man noch ran, aber es ist keine Anmeldung möglich (Meldung: Der angegebene Benutzername oder das Passwort ist falsch.).
Beim Versuch sich per ssh zu verbinden, wird die Verbindung getrennt.

Interessanterweise kommt man per TeamViewer noch auf die Kunden-Systeme.
Wiederum eine Verbindung via SSL-VPN ist nicht möglich.

ClamAV wurde, nachdem es empfohlen wurde, bereits deaktiviert.

Dieses Verhalten ist mir leider sehr vertraut...
Ebenfalls mit deaktivirtem ClamAV...

Der CommtouchAV ist aktiv.

MfG
Sebastian Koscholke

kann leider auch eine RC200 Kundeninstallation mit entsprechendem Verhalten beisteuern ... :-(
Bei uns hieß es allerdings, dass die Ursache beim PPTP-Server-Dienst liegen würde?!?
Weil wir auf diesen nicht verzichten können, haben wir als Übergang seit dem 15.11.13 wieder die alte V10 am laufen.
Support weiß Bescheid, aber das ändert ja auch nix.
MfG
Jens Petersen

soeben wieder ein dwarf, hier ein screenshot vom load (hier im forum kann ich keine bilder hochladen)

https://oc.comple.at/public.php?service ... 5&download

auf allen firewalls ist der clamav deaktiviert

bis wann ist mit einer lösung zu rechnen?

Hallo cjp,

ich würde Ihnen empfehlen sich bitte bei uns im Support zu melden.
Der hohe Load ist keine Auswirkung des hier thematisierten Problems.

Beste Grüße

cjp hat geschrieben:

Aktuelle Firmware (v11.3.1.2), die Auslastung konnte aufgrund dessen, das kein Zugriff mehr möglich war, leider nicht ermittelt werden.
Im aktuellen Fall handelt es sich um eine Black Dwarf von Mai 2012.

Diese Problem gibt es bei uns auch (wieder)
Es machte vorerst den Anschein das dieses Problem mit der 11.3.2.1 gefixt wurde, leider doch nicht.

Kein Zugriff auf die Webadministration
Kein Zugriff via ssh
Kein Aufbau von OpenVPN

Syslogs gibt es leider in den meisten Fällen nicht da die Kunden mit Dwarfs keine dementsprechende Infrastruktur besitzen. (Was nicht heißt das es nur bei Dwarfs vorkommt)

siehe http://support.securepoint.de/viewtopic.php?f=33&t=2749

Genau das gleiche Problem hatte ich übrigens heute auch bei einem Wifi-Zwerg. IPsec-Tunnel waren i.O., Internetzugang war i.O., nur oben zitierte Probleme hatte ich exakt so auf meinem Zwerg. CLAMAV ist deaktiviert.

Jackpot!
Ich hab wieder eine...
BlackDwarf aus Oktober 2013 Wifi&Umts in 11.3.1.2
IPSec Tunnel steht. HttpProxy läuft. SSL-VPN mit lokaler Anmeldung fehlerhaft.
Anmeldung an Webinterface oder via Soc nicht möglich...
Benutzername oder Passwort falsch.
Putty verweigert auch das Login.

Langsam wird es lästig!!!
Die Teile steigen nach und nach aus.

Gruß Sebastian Koscholke

Würde es evtl. helfen, die UTMs regelmässig, z.B. per ssh-Skript, neu zu starten.
Ich denke dabei an irgendwann in der Nacht.

Das löst zwar nicht das Problem, könnte aber ein möglicher workaround sein.
Getreu dem Motto "Ein Boot tut gut".

Wir haben mit unserer UTM die Tage den Eindruck gehabt, das Diese immer langsamer wurde, der konkrete Fehler/Absturz wie hier beschrieben war's aber noch nicht (den hatten wir aber auch schon),
nach einem Neustart lief's dann wieder wie gewohnt.

Bei virtualisierten UTMs hatten wir den Absturz bislang gar nicht, obwohl diese teilweise auch nur mit den Eckdaten eines Zwergs (was CPU-Zahl, RAM-Größe, etc.) betrifft konfiguriert sind.

Wir haben hier grade auf einer RC400 ... Webinterface ist noch erreichbar, Internet geht nicht mehr (ICAP Protocol Error), Anmeldung nicht mehr möglich (Passwort falsch) und den IPSec Dienst scheint es neu getsratet zu haben .. .also Neustart ... so eine Scheisse ... und das mitten am Tag wo ca. 300 Außenstellen auf diese FW zugreifen

Auch wenn die Information nur noch unschöner ist, aber ich hatte nun auch schon das nächste Gerät, welches exakt oben beschriebenen Fehler zeigt (ICAP Protocol Error, kein Login, ...)... es häuft sich, es ist also wohl offenbar kein spezifischer Gerätefehler, sondern ein Firmware-Fehler.

no comment.

Hallo,

wir vermuten momentan, dass das Problem durch zwei Log-Dateien auf der Firewall verursacht wird. Wir empfehlen daher, folgende Schritte durchzuführen:

1. Verbinden Sie sich per Putty auf die Firewall und melden Sie sich als root an.
2. Bearbeiten Sie mir dem Befehl "vi /usr/bin/freshclam.sh" das Script des ClamAV's.
2.1. Wandern Sie mit dem Cursor an den Punkt hinter "freshclam --on-update-execute=EXIT_1" und drücken Sie die Taste "i".
2.2. Nun fügen Sie hier "rm -rf /var/log/wtmp" ein. Das ganze sollte dann so aussehen:
#checklicense
#freshclam --on-update-execute=EXIT_1
#rm -rf /var/log/wtmp
#case $? in
# 0)
2.3. Speichern Sie Ihre Änderungen und schließen Sie den vi-Editor.
2.3.1. Verlassen Sie mit der ESC-Taste den Insert-Modus des Editors.
2.3.2. Geben Sie einen Doppelpunkt ein und speichern Sie die Datei dann, indem Sie "wq" eingeben und den Befehl mit der Enter-Taste bestätigen.
3. Wechseln Sie mit dem Befehl "spcli" auf das Securepoint-CLI.
4. Bearbeiten Sie mit dem Befehl "extc template edit template /etc/nginx/nginx.conf" das Template für den nginx.
4.1. Suchen Sie im Template den Eintrag "error_log off;" und ersetzen Sie diesen durch "error_log /dev/null;".
4.1.1. Bewegen Sie den Cursor an die richtige Stelle.
4.1.2. Drücken Sie die Taste "i".
4.1.3. Bearbeiten Sie den Eintrag wie gewünscht.
4.1.4. Verlassen Sie den Insert-Modus mit der ESC-Taste.
4.1.5. Geben Sie einen Doppelpunkt ein.
4.1.6. Geben Sie den Befehl "wq" ein und bestätigen Sie diesen mit Enter.
5. Starten Sie mit dem Befehl "appmgmt restart application webserver" den Webserver der Firewall neu.
6. Verlassen Sie das Securepoint-CLI mit der Tastenkombinaion STRG+C.
7. Löschen Sie mit dem Befehl "rm -rf /etc/nginx/off" die fälschlich angelegte Log-Datei.
8. Config speichern
9. Fertig!

Bitte beachten Sie, dass die Änderungen in der freshclam.sh bei einem Reboot verloren gehen und dann eventuell neu vorgenommen werden müssten.

Hallo,
ist diese Anleitung verbindlich?

Im Klartext: Wird empfohlen dieses mit allen UTMs zu machen? Versions und Hardware unabhängig?

Werden die händischen Einträge ein Firmwareupdate (Glaskugel: V11.4) beinträchtigen?
Oder ist vorher ein regulärer Neustart zwingend?

Wann wird die V11.4 ausgerollt?
Lohnt sich diese Tipperei oder gibt es evtl. in den nächsten Tagen ein Release?

MfG
Sebastian Koscholke

Hallo,

Wird empfohlen dieses mit allen UTMs zu machen?
Ja, das wird empfohlen.

Werden die händischen Einträge ein Firmwareupdate (Glaskugel: V11.4) beinträchtigen?
Nein, das Update wird nicht beeinträchtigt.

Lohnt sich diese Tipperei oder gibt es evtl. in den nächsten Tagen ein Release?
Ja, die "Tipperei" lohnt sich, da es voraussichtlich kein Release in den nächsten Tagen geben wird.

Kleine Korrektur: appmgmt

Das sieht dann also so aus:

Jens Fuhrmann hat geschrieben:Kleine Korrektur: appmgmt

Das sieht dann also so aus:

Code: Alles auswählen

5. Starten Sie mit dem Befehl "appmgmt restart application webserver" den Webserver der Firewall neu.

Ist oben entsprechend korrigiert. Danke für den Hinweis.

Soll man nach dem Workaround nun den ClamAV wieder einschalten?

Hallo Zusammen,

vielen Dank für die zahlreiche und umfassende Dokumentation des Problems. Wir haben die letzten Tagen intensiv die Ursache gesucht und diese wird mit der 11.4 behoben sein. Entstandene Unannehmlichkeiten bitten wir zu entschuldigen. Bis dahin empfehlen wir allen Nutzern einer 11.3 die im Beitrag http://support.securepoint.de/viewtopic ... =25#p12247 enthaltenen Einstellungen an der 11.3 vorzunehmen. Dies wird keinen Einfluss auf das Update auf die 11.4 haben. Die 11.4 befindet sich derzeit in den Beta Tests - sobald diese abgeschlossen sind wird diese freigegeben. Wir werden darüber sofort informieren. Den ClamAV lassen Sie bitte ausgeschaltet.

Für weitere Unterstützung stehen wir jederzeit zur Verfügung.

Wie sieht's denn so aus, funktioniert dieser Workaround? Ich hatte heute eine RC100, bei der ich alles so eingestellt hatte, und dennoch brauchte sie heute einen Neustart nach ICAP-Fehler...

Nach sieben Tagen ist bei meinem Kunden, trotzdem o.g. Workaround die Firewall wieder komplett eingefroren. Ich warte dringend auf das Update !!!

Ich schließe mich an, unser Zwerg hat gestern trotz aller workarounds wieder gehangen.