Hallo,
ich habe die Tage einen neuen Exchange Server 2016 aufgesetzt. Der interne E-Mailverkehr funktioniert problemlos. Das gleiche gilt für das Versenden externer E-Mails. Das Empfangen externer E-Mails dauert allerdings extrem lange - zunächst hatte ich eine Latenzzeit von etwa 5 Stunden, später etwa 1 Stunde. Die Tests beziehen sich auf OWA (ohne Outlook Client).
Womit kann das zusammenhängen? Ist vllt ein Greylisting-Filter o.ä. per Default eingestellt? Wie gehe ich bei der Fehlersuche /-einschränkung am besten vor?
Vielen Dank schon mal!
an welcher Stelle treten die Latenzen denn auf? Exchange selbst hat keinen Greylistingfilter und wenn dann würde das ja nicht den Client betreffen.
@norbertfe Ich kann bisher nur sagen, dass eine von extern verschickte E-Mail erst nach >1 Stunde für den Nutzer in OWA angezeigt wird und dass der Queue Viewer leer ist. Hast du vllt eine Idee, wie ich das Problem weiter einschränken kann?
@exchangeAdmin Du könntest die Exchange Mailqueue über Powershell prüfen: MS Anleitung
Des weitern mit dem Tool "checktls" die Konfiguration des Mailservers prüfen.
Du hast nicht geschrieben, ob ein MTA / externer (Spam)Dienstleister die Emails empfängt oder diese direkt an den Exchange Server gesendet werden - diese Info wäre noch wichtig. Hast Du einen Spamfilter von Exchange oder Drittanbieter im Einsatz?
@norbertfe Ich kann bisher nur sagen, dass eine von extern verschickte E-Mail erst nach >1 Stunde für den Nutzer in OWA angezeigt wird und dass der Queue Viewer leer ist. Hast du vllt eine Idee, wie ich das Problem weiter einschränken kann?
Wie in der anderen Antwort erwähnt, solltest du dafür mehr Infos liefern, wie denn die Mails generell von außen zu deinen Usern kommen. Ansonsten ist das nur gerate. ;)
- No _mta-sts DNS record found
- No _smtp._tls DNS record found
- MTA-STS not OK
- Trying TLS on mx0.SERVERNAME --> Cannot contact server (reason: Connection timed out)
Kann die Latenz damit zusammenhängen?
Im Übrigen waren viele Exchange-Services, die eigentlich automatisch hätten starten sollen, nicht gestartet. Dadurch konnte ich z.B. auch MessageTrackingLog zunächst nicht ausführen. Das habe ich nun manuell geändert. Könnte das womöglich die Ursache sein?
Im Übrigen waren viele Exchange-Services, die eigentlich automatisch hätten starten sollen, nicht gestartet
Die Frage ist doch, ob nach dem Start der Dienste die EMails ohne Verzögerung zugestellt werden.
Trying TLS on mx0.SERVERNAME
Hast Du ein Zertifikat für Deinen Exchange Mailserver installiert und dem Dienst SMTP zugewiesen? Die Fehlermeldungen bzgl. "MTA-STS" kannst Du ignorieren. Die Technik MTA-STS ist eine Technik zur Abwehr von Spam - ist aber noch nicht weit verbreitet.
Zum HAREDIRECTFAIL - hast Du auch die Infos aus dem source-context Feld?
| HAREDIRECTFAIL | Eine Shadow-Nachricht konnte nicht erstellt werden. Die Details werden im Feld source-context gespeichert. |
Ist zwar unwahrscheinlich, aber evtl. liegt es am sog. tarpitinterval. Gibt mal auf Exchange Powershell folgenden Befehl ein:
get-ReceiveConnector | select name,tarpitinterval
Sollte per Default auf 5 Sekunden stehen. Setze mal auf 0 Sekunden
set-ReceiveConnector "<Name Receive Connector>" -tarpitinterval 00:00:00
Zum HAREDIRECTFAIL - hast Du auch die Infos aus dem source-context Feld?
HAREDIRECTFAIL Eine Shadow-Nachricht konnte nicht erstellt werden. Die Details werden im Feld source-context gespeichert.
Ich muss mich korrigieren: zwischen SEND und DELIVER gibt es doch keine hohe Latenz. D.h. nach dem Event HAREDIRECTFAIL erfolgt die Zustellung binnen weniger Sekunden. Das Problem muss davor zu verorten sein.
@exsus Der Source-context von HAREDIRECTFAIL lautet: "No suitable shadow servers".
@exsus Das tarpitinterval war auf 5 Sekunden eingstellt. Testweise habe ich den Default-Receiveconnectore auf 0 Sek. gesetzt - aber ohne Effekt.
Ich habe die Konfiguration des Mailservers soeben mit checktls getestet. Es werden vier Fehlermeldungen ausgegeben:
- No _mta-sts DNS record found
- No _smtp._tls DNS record found
- MTA-STS not OK
Kein Problem, weil vermutlich kaum einer MTA-STS bisher konfiguriert.
Das mit dem Dienststart kenn ich seit einiger Zeit bei ein paar Servern. Eine Lösung dafür hab ich nicht (außer Task der das prüft)
Wenn Ihr einen Standalone-Exchange Server betreibt dann wird der Fehler bzgl. HAREDIRECTFAIL mit folgenden Befehl behoben:
Set-TransportConfig -ShadowRedundancyEnabled $false
Kannst Du ausmachen, an welcher Stelle genau der Delay auftritt. Also wenn Du von extern eine EMail versendest wann kommt diese auf Deinem Exchange-Server an?
Prüfe mal die Grundeinstellungen Deiner Domain - MX-Record, SPF, DMARC (MXToolbox). Sind dort IPv6 Adressen eingetragen, ist Deine Firewall / Exchange für IPv6 konfiguriert. hast Du mehrere (evtl. "tote") MX Records?
Was passiert, wenn Du von einem externen Client eine Verbindung über telnet / Port 25 aufbaust (Anleitung telnet). Für Windows kannst Du telnet mit dem Programm putty testen.
einen neuen Exchange Server 2016 aufgesetzt
Hast Du damit zwei Exchange Server in Betrieb oder nur den neuen Ex 2016? Ich gehe davon aus dass der Ex 2016 eine "neue" IP bekommen hat. Ist diese in der Firewall / Portforwarding eingetragen?
Wurde das Portforwarding für den alten Exchange Server gelöscht?
Der aktuelle Stand ist, dass eingehende E-Mails aktuell gar nicht mehr zum Exchange-Server übermittelt werden.
- Der Telnetzugriff auf den Exchange-Server (Port 25) funktioniert allerdings - auch von extern.
- Wireshark-Analysen zeigen, dass eingehende Nachrichten auf Port 25 nur bis zum externen Netzwerkadapter des Firewall-Servers kommen und nicht zum internen Adapter weitergeleitet werden (und somit auch nicht zum Exchange-Server)
Die einzigen Änderungen meinerseits auf dem Firewall-Server (mit Windows Server 2016) in der letzten Zeit waren:
- Einspielen eines Security-Updates
- Installation von Wireshark
Eigentlich dürfte beides keine Effekte auf das Routingverhalten haben. Darüber hinaus war mir aufgefallen, dass bereits letzte Woche eine Testnachricht nicht zugestellt wurde, die darauffolgende hingegen schon. Insofern schien das Problem bereits vorher zu bestehen, wenn auch nur temporär.
Zu den anderen Fragen:
- Alle Portforwarding existieren noch. Deswegen funktioniert auch der Telnetzugriff noch.
- Es gibt aktuell tatsächlich zwei Exchange Server (Testserver und Produktivsystem). Beide Systeme sind aber nicht miteinander verbunden und befinden sich in unterschiedlichen Domänen.
- Der Telnetzugriff auf den Exchange-Server (Port 25) funktioniert allerdings - auch von extern.
- Wireshark-Analysen zeigen, dass eingehende Nachrichten auf Port 25 nur bis zum externen Netzwerkadapter des Firewall-Servers kommen und nicht zum internen Adapter weitergeleitet werden (und somit auch nicht zum Exchange-Server)
Diese Aussage widerspricht sich, da ein funktionierender Telnet-Test von extern dem Ergebnis der Wireshark Analyse widerspricht.
Mal von vorne: Beschreibe mal Deine Konfiguration - bitte ausführlich. Also welche Produkte setzt Du für die Firewall, NAT, MTA, Spam-/Virenfilter auf welchem Server (Firewall, Exchange) ein. Wenn Du z.B. auf dem Firewall Server ein MTA installiert hast, dann funktioniert Telnet. Damit wird die EMail vom MTA angenommen, aber offensichtlich nicht an Exchange weitergeleitet. Deshalb überprüfe mal die Konfiguration auf dem Firewall-Server: MTA, Spamfilter, Portforwarding. Wenn Du einen MTA einsetzt, dann schaue Dir die Messege Queue an - dort sollten die EMails "hängenbleiben".
Danke für die schnelle Antwort!
Ich habe die Wireshark- und Telnettests wiederholt:
- Wenn ich von außen per Telnet auf Port 25 auf den Server zugreife, erhalte ich die Nachricht, dass der Zugriff funktioniert hat („Connected to ….“). Ferner kann ich den entsprechenden Request auf dem Exchange-Server mit Wireshark sehen. Der Test hat auch ohne VPN-Zugriff funktioniert.
- Wenn ich hingegen eine Testmail von extern schicke, kann ich mit Wireshark nur Requests auf dem externen Netzwerkadapter des Firewall-Servers sehen, auf dem internen nicht.
Zu den weiteren Fragen:
- Eine Firewall ist nur auf dem Firewall-Server installiert – auf diesem ist aktuell nur eine Windows Server 2016 Standard-Firewall installiert.
- Ferner ist auf dem Firewall-Server NAT konfiguriert.
- Zusätzliche Spam- und Virenfilter sind derzeit nicht installiert (lediglich die nativen von Exchange).
- Weiterhin ist auf dem Firewall-Server ein Portforwarding konfiguriert. Die Einstellungen sind aber korrekt.
- MTA habe ich zumindest nicht wissentlich installiert. Wie kann ich das verifizieren? Kann das auch ein Bestandteil von Exchange sein, der automatisch mitinstalliert wird (in dem Fall wäre es aber nicht auf dem Firewall-Server)?
Ausgehende Testmails funktionieren übrigens problemslos (auch wenn die Zustellung mit ca. 5 Minuten auch noch etwas zu lange dauert).
Das Verbindungsproblem zwischen externem und internen Adapter würde meines Erachtens eigentlich auf ein Routingproblem mit dem RRAS-Dienst (Routing and Remote Access Service) hindeuten. Wenn ich es richtig sehe, dürfte dann allerdings der Zugriff per Telnet nicht funktionieren.
Mit telnet nicht nur die Connection prüfen, sondern auch eine EMail (also "Mail from: ...) versenden. In der Anleitung ist der Ablauf genau beschrieben.
Kannst Du mal die NAT / Portforwarding Einstellungen hier posten (öffentliche IP Adressen / FQDN natürlich schwärzen). Zum Testen kannst Du das Portfarwarding mal deaktivieren und schauen, ob telnet dann einen Fehler bringt. Je nach Einstellung Deines Exchange Servers wird bei telnet der Name des Mailservers und die (interne) IP Adresse angezeigt - sind dies die Infos vom Exchange-Server.
Bitte überprüfe auch mal die MX Einstellungen Deiner Domain - mit diesem Tool. Sind diese korrekt bzw. verwendest Du die Domain aus dem MX Record für den telnet Test?
Ich gebe Dir Recht, es sieht nach einem Problem des NAT / Portforwarding aus. Bitte überprüfe mal alle Einstellungen, evtl. sind mehrere Einträge für Port 25 vorhanden.
Nachtrag: Mal ganz tivial den Firewall Server neu starten - hilft in 50% der Fälle ?
Der Telnettest mit „mail from:“ geht, wie erwartet, nicht durch. Ich interpretiere ich es insofern richtig, dass eine 1) Verbindung zum Exchange-Server von außen hergestellt werden kann, 2) auf dem Exchange-Server auch ein Dienst auf Port 25 lauscht, aber 3) keine Mail empfangen werden kann?
Ich habe auch mit https://mxtoolbox.com getestet, ob das Problem mit der Konfiguration der DNS-Einträge zusammenhängt. Das Ergebnis: Der Domainname verweist korrekt auf die IP des Firewall-Servers, die Domain steht nicht auf einer Blacklist, aber das Tool "failed to connect to SMTP host". Das Ergebnis war ja auch erwartet.
Die folgenden Portweiterleitungen sind auf dem Firewall-Server konfiguriert. "A" steht für die externe IP-Adresse des Firewall-Servers, während "B" für die interne IP-Adresse (es gibt keine externe) des Exchange-Servers steht:
A:25 --> B:25
A:80 --> B:80
A:443 --> B:443
A:143 --> B:143
A:993 --> B:993
A:587 --> B:587
Zwischen dem externen und internen NIC ist SNAT konfiguriert. Daran habe ich keine Änderungen vorgenommen, in der Form hat es also bereits in der Vergangenheit funktioniert.
Ein Restart ist tatsächlich häufig hilfreich – in diesem Fall aber leider nicht ;)
Zwischen dem externen und internen NIC ist SNAT konfiguriert.
Wie Du bereits erwähnt hast würde auch ich auf ein NAT Problem tippen. Du kannst zur Sicherheit den "telnet mit Mail-Versand Test" direkt vom Firewall Server durchführen - natürlich mit der internen IP des Exchange Servers. Wenn dieser funktioniert liegt es (höchstwahrscheinlich) am Portforwarding bzw. Firewall Rechner.
Hier bin ich allerdings raus, ich habe zu wenig Erfahrungen mit RRAS / NAT als das ich Dir weiterhelfen könnten. Stelle Dein Fehlerbild und die bisherigen Testergebnisse im MCSE Forum (ich hoffe der Link ist erlaubt) ein. Dort "sitzen" die Spezialisten ?
Das Problem ist nun gelöst: Es wurde durch falsch konfigurierte Netzwerkrouten verursacht.