Hallo!
Ich habe ein Problemchen und ich finde keine Lösung.
Folgende Situation liegt vor:
Wir haben einen SMTP Server und dieser sendet und empfängt den ganzen Tag Emails.
Nun gibts plötzlich einen SMTP Server der keine Emails von uns annimmt.
Gut, von meinem SMTP Server eine Telnet Verbindung geöffnet um die SMTP Session zufuss zu testen.
Normalerweise kommt nach "telnet server 25" ein 220 zurück und ich kann mit ehlo beginnen. Hier kommt ewig nix!
Gut von meinem HSDPA Modem mit anderer IP probiert, und da gehts nach 30 Sekunden. Dachte daher, das meine IP geblacklistet ist.
Dann habe ich den Server Admin des verweigernden Zielhosts kontaktiert und mit diesem bisserl getestet.
Dieser verwendet Tarpitting und daher dauert es 30 Sekunden bis die SMTP Session etabliert wird und man zum Handshake kommt.
Laut meinem LANCOM 1711 wird von uns an den Zielhost gesendet, es kommt aber nichts zurück. Interessanter weise meint der Herr des anderen SMTP Servers, er würde antworten, aber wir hätten die Verbindung schon terminiert.
LANCOM Setting: Es gibt einen Portforward vom LANCOM zu meinem SMTP Server. Dem entsprechend gibts 2 Firewall Regeln die eingehenden Trafik zu Port 25 von jedem Quellport aus erlauben bzw. den ausgehenden Trafik von XX auf Port 25 erlauben.
Zusätzlich habe ich mittlerweile 2 Regeln definiert die JEDE Verbinung von dem fremden Server an uns und jede Verbindung von uns an den fremden Server erlauben, diese Regeln haben die höchste Priorität in der Regelliste und kommen garantiert zum Zug!
Gut, ich würde meinen am LANCOM kanns nicht liegen, aber nach einem schon verzweifelten Test konnte ich mit meinem Laptop direkt am Internet hängend ohne LANCOM dazwischen die Telnet Sitzung etablieren und ehlo, mail from etc durchspielen. Also irgendwie pfuscht mir LANCOM da dazwischen, ich habe aber keine Idee wie....
Wir haben das Monat ca 10000 Emails versendet und haben sonst keine Probleme, nur mit diesem einen fremden SMTP Server, aber nur wenn LANCOM Router dazwischen ist.
Am MailServer kann es nicht liegen, da es sonst mit Telnet klappen müßte!
Mein SMTP Log:
06/15/09 17:26:38 127.0.0.2 <system> 0000000013 Debug: Delivery for domain hjf.at - MX lookup succeeded
06/15/09 17:26:38 127.0.0.2 <system> 0000000013 Debug: ==== Attempting connection to mail.www24.at[217.116.188.216]
!Nach diesem Eintrag kommt nichts mehr! Auch keine Terminierung der Session und im Mailserver wird sie im Quee permanent mit Status "sending" angezeigt.
Der SMTP Log des fremden SMTP Servers:
[17/Jun/2009 10:15:17][2232] {smtps} SMTP server session begin; client connected from mail.ago.at:55272
[17/Jun/2009 10:15:17][2232] {smtps} Looking up address 213.229.56.171 in DNS blacklist SpamHaus SBL-XBL...
[17/Jun/2009 10:15:17][2232] {smtps} Address 171.56.229.213.zen.spamhaus.org not found in DNS blacklist SpamHaus SBL-XBL
[17/Jun/2009 10:15:17][2232] {smtps} Delaying SMTP greeting to mail.ago.at:55272 for 30 seconds
[17/Jun/2009 10:15:50][2232] {smtps} Connection to SMTP server mail.ago.at lost: (10054) An existing connection was forcibly closed by the remote host.
[17/Jun/2009 10:15:50][2232] {smtps} SMTP server session end
Hat jemand eine Idee oder vorschlag? DANKE!
Router hat unerklärliches Verhalten in Bezug auf einen Host
Moderator: Lancom-Systems Moderatoren
als workaround senden wir jetzt nicht zustellbare emails an einen smarthost weiter und der übernimmt das dann. es funktioniert dadurch jetzt das Mailversenden wieder, aber es gibt doch ein ungeklärtes Problem...
Ich brauch echt nur Tipps. Mir muss keiner die Lösung vorkauen, aber mir fällt nix mehr ein, das für dieses Symptom verantworlich sein könnte.
Ich brauch echt nur Tipps. Mir muss keiner die Lösung vorkauen, aber mir fällt nix mehr ein, das für dieses Symptom verantworlich sein könnte.
Neues interessantes Detail:
Ich habe insgesammt 3 LANCOM 1711 mit ganz unterschiedlichen Konfigurationen und habe jetzt einen Test gemacht. Ich habe eben ein zweites LANCOM hergenommen und über einen eigenen Internet Anschluss den Zugriff wie oben getestet, es kommt auch hier der gleiche Fehler! Könnte das ein Bug oder Firmware Problem sein?
Bitte testet mal den Zugriff per Telnet über euren LANCOM Router:
> telnet mail.www24.at smtp
und waretet 30 Sekunden ob was kommt. Bei mir nämlich nicht sobald ein LANCOM dazwischen hängt!
Ich habe die aktuellste Firmware installiert: 7.60.0160 / 26.2.2009
Ich habe insgesammt 3 LANCOM 1711 mit ganz unterschiedlichen Konfigurationen und habe jetzt einen Test gemacht. Ich habe eben ein zweites LANCOM hergenommen und über einen eigenen Internet Anschluss den Zugriff wie oben getestet, es kommt auch hier der gleiche Fehler! Könnte das ein Bug oder Firmware Problem sein?
Bitte testet mal den Zugriff per Telnet über euren LANCOM Router:
> telnet mail.www24.at smtp
und waretet 30 Sekunden ob was kommt. Bei mir nämlich nicht sobald ein LANCOM dazwischen hängt!
Ich habe die aktuellste Firmware installiert: 7.60.0160 / 26.2.2009
Die Verzögerung des SMTP Dialogs um 30 Sekunden finde ich etwas viel. Hier würden aus meiner Sicht 3-5 Sekunden vollkommen ausreichen. Ich würde mal behaupten, dass ihm dadurch auch so manches andere gewollte Mail durch die Lappen geht.
Was ich eigentlich fragen wollte:
Hast Du schonmal mit den Session Timeouts unter ip-router -> tcp-aging experimentiert? dreh das mal ordentlich hoch (zb. auf 1.500 sekunden).
Was ich eigentlich fragen wollte:
Hast Du schonmal mit den Session Timeouts unter ip-router -> tcp-aging experimentiert? dreh das mal ordentlich hoch (zb. auf 1.500 sekunden).
Liebe Grüße,
michael
michael
Hi Oliver
das LANCOM schließt halboffene TCP-Sessions nach 30 Sekunden. Wenn der Mailserver also 30 Sekunden wartet, bevor er auf das TCP-SYN antwortet, dann hat er ein Problem mit dem LANCOM...
@tbc233
ein hochstellen des TCP-Agings hilft hier nicht, da dies erst auf einer etablierten TCP-Session wirkt.
Gruß
Backlash
das LANCOM schließt halboffene TCP-Sessions nach 30 Sekunden. Wenn der Mailserver also 30 Sekunden wartet, bevor er auf das TCP-SYN antwortet, dann hat er ein Problem mit dem LANCOM...
@tbc233
ein hochstellen des TCP-Agings hilft hier nicht, da dies erst auf einer etablierten TCP-Session wirkt.
Gruß
Backlash
Danke für den Tipp!
ich habe unter Firewall/QOS die Sitzungswiederherstellung auf "immer erlaubt" gesetzt, Fragmente werden "weitergeleitet".
Unter "IP-Router -> Maskierung" hatte hatte ich zuerst folgende Einstellungen:
TCP 300 Sekunden
UDP 20 Sekunden
ICMP 10 Sekunden
IPSec 2000 Sekunden
Fragment-Aging waren 10 Sekunden
Ich habe jetzt alle Einstellungen außer IPSec auf 1500 Sekunden und Fragment-Aging auf 255 Sekunden umgestellt.
Den Router habe ich auch einmal aus- und eingeschalten.
Leider hat sich am Verhalten nix geändert. Ich kann andere externe SMTP Server über Telnet erreichen, den mail.www24.at nicht!
--------------------------
Ich muss sagen, ich finde 30 Sekunden auch kritisch, vorallem da manche Mail Admins ein Timeout von 30 Sekunden auf eingehende Sessions aktivieren... aber ich möchte das mein Mailserver seine Mails loswerden kann egal wie der andere Server konfiguriert ist.
Funktioniert der Zugriff auf dem Server bei euch über euer LANCOM Device?
ich habe unter Firewall/QOS die Sitzungswiederherstellung auf "immer erlaubt" gesetzt, Fragmente werden "weitergeleitet".
Unter "IP-Router -> Maskierung" hatte hatte ich zuerst folgende Einstellungen:
TCP 300 Sekunden
UDP 20 Sekunden
ICMP 10 Sekunden
IPSec 2000 Sekunden
Fragment-Aging waren 10 Sekunden
Ich habe jetzt alle Einstellungen außer IPSec auf 1500 Sekunden und Fragment-Aging auf 255 Sekunden umgestellt.
Den Router habe ich auch einmal aus- und eingeschalten.
Leider hat sich am Verhalten nix geändert. Ich kann andere externe SMTP Server über Telnet erreichen, den mail.www24.at nicht!
--------------------------
Ich muss sagen, ich finde 30 Sekunden auch kritisch, vorallem da manche Mail Admins ein Timeout von 30 Sekunden auf eingehende Sessions aktivieren... aber ich möchte das mein Mailserver seine Mails loswerden kann egal wie der andere Server konfiguriert ist.
Funktioniert der Zugriff auf dem Server bei euch über euer LANCOM Device?
Zuletzt geändert von Oliver am 24 Jun 2009, 09:14, insgesamt 1-mal geändert.
Hi Oliver,
bei genauerer Überlegung sollte es eigentlich nicht an dem Timeout liegen, denn derjenige, der eine TCP-Verbindung aufbaut, wiederholt die SYN-Pakete regelmäßig, wodurch der Timeout auch jedesmal zurückgesetzt wird. Daher hält das LANCOM eine solche halboffene Session i.A. auch mindestens eine Minute offen...
Ein Problem könnte darin liegen, daß die "Teergrube" das SYN/ACK zwar sofort schickt, aber auf das nächste ACK zu lange nicht reagiert. Hier befindet sich die Firewall des LANCOM in der Protokoll-Erkennung für z.B. FTP und es läuft immer noch der Timeout für halboffene Verbindungen. In diesem Fall gibt es auch keine weiteren Wiederholungen, die den Timeout zurücksetzen könnten
In der nächsten Firmware wird schon in der Protokoll-Erkennung der normale Timeout laufen, um dieses Problem zu umgehen. Bis dahin kannst du als Workarround für den Server eine spezielle Regel aufnehmen, bei der du das Häkchen bei "Die Regel hält die Verbindungszustände nach" entfernst. In diesem Fall gilt die Session für die Firewall vom ersten Paket an als offen und es läuft der normale TCP-Timeout (im Default 5 Minuten).
Gruß
Backslash
bei genauerer Überlegung sollte es eigentlich nicht an dem Timeout liegen, denn derjenige, der eine TCP-Verbindung aufbaut, wiederholt die SYN-Pakete regelmäßig, wodurch der Timeout auch jedesmal zurückgesetzt wird. Daher hält das LANCOM eine solche halboffene Session i.A. auch mindestens eine Minute offen...
Ein Problem könnte darin liegen, daß die "Teergrube" das SYN/ACK zwar sofort schickt, aber auf das nächste ACK zu lange nicht reagiert. Hier befindet sich die Firewall des LANCOM in der Protokoll-Erkennung für z.B. FTP und es läuft immer noch der Timeout für halboffene Verbindungen. In diesem Fall gibt es auch keine weiteren Wiederholungen, die den Timeout zurücksetzen könnten
In der nächsten Firmware wird schon in der Protokoll-Erkennung der normale Timeout laufen, um dieses Problem zu umgehen. Bis dahin kannst du als Workarround für den Server eine spezielle Regel aufnehmen, bei der du das Häkchen bei "Die Regel hält die Verbindungszustände nach" entfernst. In diesem Fall gilt die Session für die Firewall vom ersten Paket an als offen und es läuft der normale TCP-Timeout (im Default 5 Minuten).
Gruß
Backslash