Firewall erzeugt Timeouts bei Client-Thunderbird

[mseele 10]

Hi,

ich bin gerade am Einrichten eines SBS 2011 Essentials und habe folgendes Problem:

Auf dem Server läuft ein hMailServer der eMails an die Clients per SMTP verteilen soll.

Wenn ich die Windows Firewall an habe, ist die Verbindung von Thunderbird zum Mailserver extrem langsam (ich kann meist erst nach dem 2. oder 3. Versuch senden, davor läuft er in ein Timeout). Die Ports für SMTP, POP3 & IMAP sind alle freigegeben, das ist also nicht das Problem.

Ist die Firewall aus, funktioniert es rasend schnell (so wie es sein sollte).

Ich habe auch Tests mit telnet gemacht (telnet <SERVERNAME> <SMTP-PORT>) und da habe ich das gleiche Ergebnis.

Das es an der Route liegen kann ist auch ausgeschlossen, tracert liefert nur einen Eintrag zurück, hat also eine "direkte" Verbindung.

Gibt es noch irgendwelche erweiterten Einstellungen in der Firewall die ich noch einrichten muss? Woran könnte das liegen bzw. wie komm ich hinter den Fehler?

Ich weiß echt nicht mehr weiter :(

 

Vielen Dank schonmal!

[mseele 10]

Was mir noch dazu einfällt:

Die Windows Remoteverbindung zum Server funktioniert auch mit Firewall einwandfrei von den Clients. Vielleicht hilft das ja was bei der Fehleranalyse!?

[iDiddi 27]

Auf dem Server läuft ein hMailServer der eMails an die Clients per SMTP verteilen soll.

Und sagst Du uns auch, welcher das ist?

 

Wenn ich die Windows Firewall an habe, ist die Verbindung von Thunderbird zum Mailserver extrem langsam (ich kann meist erst nach dem 2. oder 3. Versuch senden, davor läuft er in ein Timeout). Die Ports für SMTP, POP3 & IMAP sind alle freigegeben, das ist also nicht das Problem.

Ist die Firewall aus, funktioniert es rasend schnell (so wie es sein sollte).

Dann schalte mal das Logging ein (zumindest für blockierte Verbindungen) und sieh in der pfirewall.log nach, welche Ports evtl. noch geblockt werden.

 

Lässt Du denn sowohl eingehenden als auch ausgehenden Verkehr durch?

[Dukel 457]

Und sagst Du uns auch, welcher das ist?

 

Hat er doch:

hMailServer - Free email server for Microsoft Windows

[iDiddi 27]

@Dukel: Ups. Hab gedacht, das is'n Schreibfehler :o

Von dem hab ich ja noch nie gehört

[mseele 10]

Dann schalte mal das Logging ein (zumindest für blockierte Verbindungen) und sieh in der pfirewall.log nach, welche Ports evtl. noch geblockt werden.

 

Lässt Du denn sowohl eingehenden als auch ausgehenden Verkehr durch?

 

Das Logging ist an. Die Ports die nötig sind werden nicht blockiert.

 

Wir sind auch schon nen Schritt weiter. Wenn ich nen Linux Client ranhäng funktioniert es ohne Probleme.

Vielleicht hat es was mit dem Windows 7 des Clients zu tun!? Oder mit IPv6!?

Das sind die nächsten zu testenden Punkte...

[iDiddi 27]

Das Logging ist an. Die Ports die nötig sind werden nicht blockiert.

OK. Hätte jetzt noch den MySQL-Port (3306) genannt, aber das hat sich ja erübrigt, da die Probleme dann auch mit dem Linux-Client aufgetreten wären.

 

Poste mal ein

ipconfig /all

 

und ein

nslookup

 

Ändere auch mal die DNS-Einstellungen wie in diesem Beitrag ab:

 

http://www.mcseboard.de/windows-server-forum-78/problem-dns-server-177315.html#post1092732

 

Vielleicht hilft's :)

 

Wobei ich echt nicht verstehe, was die Windows Firewall damit zu tun haben könnte :suspect:

[mseele 10]

Ich habe heut das Problem gelöst. Für alle die es interessiert, daran lags:

 

Es war kein Fehler in der Firewallkonfiguration, sondern ein Fehler im DNS. Irgendwas mit IPv6 hat nicht gepasst. Wenn ich IPv6 auf dem Server ausgeschaltet habe, hat es mit und ohne Firewall funktioniert, mit IPv6 nicht.

Wir sind dann durch einen nslookup vom Client dahinter gekommen das er die DNS nicht richtig auflöst. Ein einrichten einer Zone im DNS Server hat das Problem dann behoben.

Vielen Dank trotzdem für eure Mühe.

[iDiddi 27]

Danke für Deine Rückmeldung :)

 

Es war kein Fehler in der Firewallkonfiguration, sondern ein Fehler im DNS. Irgendwas mit IPv6 hat nicht gepasst.

Was ich ja auch vermutet hatte ;) . Könntest Du uns denn trotzdem noch mitteilen, was genau "nicht gepasst" hat und was ihr jetzt genau dagegen gemacht habt?

 

Wenn bei einem nslookup am Client ein DNS-Server mit ::1 geantwortet hat und das Euer Problem war, hätte es die Lösung aus dem verlinktem Beitrag auch getan ;)

[mseele 10]

Könntest Du uns denn trotzdem noch mitteilen, was genau "nicht gepasst" hat und was ihr jetzt genau dagegen gemacht habt?

 

Wenn bei einem nslookup am Client ein DNS-Server mit ::1 geantwortet hat und das Euer Problem war, hätte es die Lösung aus dem verlinktem Beitrag auch getan ;)

 

Nein dein verlinkter Beitrag war nicht die Lösung. Trotzdem Danke! ;)

 

Wir mussten eine Reverse-Lookup Zone einrichten: Reverse-Lookup

 

Ohne Die hat der Server seinen eigenen Namen nicht auflösen können (heißt <NAME> nicht in <IP> umwandeln können, und irgendwie hat das mit IPv6 Ärger bereitet), keine Ahnung warum das nötig ist aber jetzt tut alles wunderbar :)

[iDiddi 27]

Ohne Die hat der Server seinen eigenen Namen nicht auflösen können (heißt <NAME> nicht in <IP> umwandeln können

Und für was sollte er das können müssen?

 

und irgendwie hat das mit IPv6 Ärger bereitet

Das ist ja mal 'ne klare Aussage ;)

 

Sorry, aber ich verstehe nur Bahnhof. Es gibt für mich keine logische Erklärung, warum eine Reverse-Lookup-Zone erforderlich sein sollte. Aber da Du scheinbar selbst nicht genau weißt, was ihr da gemacht habt, werden wir es wohl nie erfahren.

 

Aber die Hauptsache ist ja, dass es läuft