• Bewerte uns auf OMR Reviews: Klick

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

Timeout http://localhost:6060

bldtechnik

New member
Hallo zusammen,

wir haben seit einigen Tagen Probleme mit NoSpamProxy in der Version 13.0.19169.1943. Beim Bedienen der Konsole führt das zu einem Timeout. Die E-Mails werden dann nicht mehr verarbeitet.

Mit netstat ist in diesem Augenblick beim Port 6060 der Status "Schliessen_warten" zu sehen.

Ein Neustart vom Dienst Gateway Role behebt das Problem, aber nur für einige Minuten.

Nachfolgend ein Auszug der Fehlermeldung:
Die HTTP-Anforderung an "http://localhost:6060/NoSpamProxy/ConfigurationController/Windows/" hat das dafür vorgesehene Zeitlimit von 00:01:00 überschritten. Der für diesen Vorgang zugewiesene Zeitraum war möglicherweise ein Teil eines längeren Timeouts.


Hat jemand eine Idee wie das Problem zu lösen ist?


Viele Grüße
 
Hallo,
für mich liest sich das so, als wenn dort eher ein generelles Problem vorliegt. Die Verfügbarkeit von Port 6060 hat mit dem SMTP-Handling nichts zu tun. Wie ist denn die Prozessor- und RAM-Auslastung des Systems zu diesem Zeitpunkt? Verbraucht ggfs. die Gateway Rolle zu viel RAM?

Gruß Stefan
 
Hallo Stefan,

vielen Dank für die Rückmeldung. Wir starten mittlerweile den Dienst der Gateway-Rolle regelmäßig neu, so dass das Problem etwas an Brisanz verloren hat. Die CPU-Auslastung liegt bei 15% und der Ram bei etwa 55%. Es sollte also nicht an einer Überlastung liegen.

Kann es an der "schlechten" Erreichbarkeit zum internen Mailserver liegen? Lässt sich das testen?


Gruß
Pit Bosmann
 
Hallo, 
das ist möglicherweise einer der Gründe. Ich will Deine Punkte gerade mal etwas aufdröseln, um etwas mehr Klarheit zu schaffen. Du schriebst unter anderem folgendes:

[font=Tahoma, Verdana, Arial, sans-serif]"Beim Bedienen der Konsole führt das zu einem Timeout. Die E-Mails werden dann nicht mehr verarbeitet."[/font]

[font=Tahoma, Verdana, Arial, sans-serif]Die Konsole selbst spricht ausschließlich über Port 6060 mit der Intranet Rolle. Jetzt stellt sich die Frage: Sind die Intranet Rolle und die Gateway Rolle auf unterschiedlichen Servern? Oder auf demselben? Ist die Konsole ggfs. auf einem Admin-PC installiert und greift durch eine Firewall auf den Server mit der Intranet Rolle zu?[/font]

[font=Tahoma, Verdana, Arial, sans-serif]Wenn E-Mails nicht mehr verarbeitet werden, wie äußert sich das? Siehst Du sie "nur" nicht mehr in der MMC? Oder bleiben sie irgendwo auf anderen Servern hängen und Du siehst Verbindungsprobleme? Der E-mail-Verkehr wird ausschließlich von der Gateway Rolle verarbeitet. Hier hat die Intranet Rolle keinerlei Einfluss.[/font]

[font=Tahoma, Verdana, Arial, sans-serif]Vielleicht hilft das zur besseren Einordnung.[/font]

[font=Tahoma, Verdana, Arial, sans-serif]Gruß Stefan[/font]
 
Hallo,
auch wenn das Thema schon alt ist, haben wir aktuell genau das gleiche Beschriebene verhalten bei Version 15.1.0 jedoch mit der URL http://localhost:6060/NoSpamProxy/MonitoringController/UserName. Die Verbindung von der Intranetrolle (Zone: LAN) zum Gateway (Zone: DMZ) läuft in ein Timeout. Das Timeout kommt aber nicht immer, in 8 von 10 Fällen aber was sehr seltsam ist.

Man sieht dann in der Firewall (bei uns Sophos), invalid traffic von Gateway Quellport 6060 zu Intranet Port 551xx obwohl wir auch 6060 als Quellport freigebeben haben.
Das Problem lässt sich beheben indem wir in unserer Firewall nicht nur Port 6060 Freigeben sondern alle. Was dabei wiederum noch seltsamer ist, ist das nach der Aktivierung die Einträge von Quellport 6060 nicht mehr Protokolliert werden, nur mit Zielport 6060.
Das verhalten ist bei uns so Reproduzierbar.

Warum der Mailverkehr dann auch Stecken bleibt verstehe ich auch nicht. An der Verbindungsqualität liegt es bei uns nicht.
 
Zuletzt bearbeitet:
Hallo,
ist das nur invalid Traffic wie er öfters vorkommen wenn ggf. gegenseite connection geschlossen hat?

Folgendes mal versuchen wenn XGS oder XG

  1. Login auf Sophos
  2. öffnen von CLI
  3. nr 4 für Device Console
  4. tippen von => show advanced-firewall
    1. Welchen Wert gibt es bei TCP connection Establishement Idle Timeout
  5. Hier ggf. den Wert erhöhen
    1. BSP: set advanced-firewall tcp-est-idle-timeout 21600
      6h
Sonst zwischen den beiden Netzen kein IDS aktiv?
Meint vielleicht "DoS-Einstellungen" aktiv zu werden?

Edit:
Was ich mir noch angewöhnt hatte bei den XGS eine Regel ganz nach unten vor der "alle Verwerfen" Regel
1719919112055.png
und hier das LOG einschalten das man sieht was wird blockiert. Da die Default "darf nix" nicht bearbeitet werden kann
 
Zurück
Oben