5
ISA 2006 OWA Listener reagiert plötzlich nicht mehr 0x80074e21 Abortive Connection
Keiner der Berichte konnte bisher weiterhelfen !
Hier noch eine Ergänzung von der ISA Protokollierung auf dem HTTPS Protokoll
Hallo zusammen, vielleicht kann mir jemand beim Debugging meines SBS OWA Problems weiter helfen:
Kurz zum Problem, seit ein paar tagen funktioniert aus mir unerklärlichen Gründen der externe zugriff aufs owa über https nicht mehr.
Hier ein paar Hinweise zum bisherigen Debugging:
- ISA / IIS Konfiguration wurden nicht verändert
- Zertifikate sind alle in Ordnung und auch korrekt installiert
- OWA intern funktioniert tadellos
- DynDNS funktioniert tadellos
Hier eine kurze übersicht über die Konfig:
OWA Anfrage kommt von außen (SSL) mit DynDNSAdresse
Weblistener sollte diese entgegen nehmen (Formbased Auth.) und ohne SSL an den Exchange weiterleiten.
Erste tests ergaben folgendes:
Telnet [server dyndns] 443 --> nicht erfolgreich ! das macht mich extrem stutzig !
Im ISA Logging taucht nichts auf, und nach dem die Routerkonfiguration nicht verändert wurde kann man das auch ausschließen.
Ein Aufbau zur Formbased auth. Seite von intern sprich https://server-ip/exchange landet auf einer Formbased auth. Seite vom ISA2006
nach einer Anmeldung kann die Website nicht gefunden werden !
PS: Das Problem besteht inzwischen auf 2 SBS Servern einmal mit ISA 2004 und ISA 2006 mit dem absolut gleichen Verhalten !
Hier ist die Ausgabe vom ISA Reporting auf Protokoll HTTPS beim herstellen einer Verbindung:
0x80074e21 FWX_E_Abortive_Connection
Die Frage ist nun was bewegt auf einmal eine der beiden Seiten dazu einen "RST" zu senden ?
WSA_RWS_ABORTIVE_SHUTDOWN or
FWX_E_ABORTIVE_SHUTDOWN 0x80074E21
A connection was abortively closed after one of the peers sent a RST segment.
Damit wird jegliche DNS Anfrage abgewiesen und die Verbindung entweder vom ISA oder IIS getrennt!
Bin für jeden Debugging Tip dankbar,
Kurz zum Problem, seit ein paar tagen funktioniert aus mir unerklärlichen Gründen der externe zugriff aufs owa über https nicht mehr.
Hier ein paar Hinweise zum bisherigen Debugging:
- ISA / IIS Konfiguration wurden nicht verändert
- Zertifikate sind alle in Ordnung und auch korrekt installiert
- OWA intern funktioniert tadellos
- DynDNS funktioniert tadellos
Hier eine kurze übersicht über die Konfig:
OWA Anfrage kommt von außen (SSL) mit DynDNSAdresse
Weblistener sollte diese entgegen nehmen (Formbased Auth.) und ohne SSL an den Exchange weiterleiten.
Erste tests ergaben folgendes:
Telnet [server dyndns] 443 --> nicht erfolgreich ! das macht mich extrem stutzig !
Im ISA Logging taucht nichts auf, und nach dem die Routerkonfiguration nicht verändert wurde kann man das auch ausschließen.
Ein Aufbau zur Formbased auth. Seite von intern sprich https://server-ip/exchange landet auf einer Formbased auth. Seite vom ISA2006
nach einer Anmeldung kann die Website nicht gefunden werden !
PS: Das Problem besteht inzwischen auf 2 SBS Servern einmal mit ISA 2004 und ISA 2006 mit dem absolut gleichen Verhalten !
Hier ist die Ausgabe vom ISA Reporting auf Protokoll HTTPS beim herstellen einer Verbindung:
0x80074e21 FWX_E_Abortive_Connection
Die Frage ist nun was bewegt auf einmal eine der beiden Seiten dazu einen "RST" zu senden ?
WSA_RWS_ABORTIVE_SHUTDOWN or
FWX_E_ABORTIVE_SHUTDOWN 0x80074E21
A connection was abortively closed after one of the peers sent a RST segment.
Damit wird jegliche DNS Anfrage abgewiesen und die Verbindung entweder vom ISA oder IIS getrennt!
Bin für jeden Debugging Tip dankbar,
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 116553
Url: https://administrator.de/contentid/116553
Printed on: April 24, 2024 at 14:04 o'clock
5 Comments
Latest comment
Hast du ISA 2006 SP1 installiert?
Was sagt die Datenverkehrssimulation?
Ich entnehme deiner Beschreibung, dass du einen NAT-Router vor dem ISA-Server hast?
Dann musst du bei der Traffic-Simulation auch dessen LAN-IP als Quelle angeben.
Telnet schlägt von Außen fehl?
Hast du den Test auch von außerhalb gemacht? Manche Router haben die Eigenart, dass der Zugriff auf geNATtete Ports von Innen auf die externe IP nicht geht (z.B. Cisco und Bintec)
Grüße
Max
Was sagt die Datenverkehrssimulation?
Ich entnehme deiner Beschreibung, dass du einen NAT-Router vor dem ISA-Server hast?
Dann musst du bei der Traffic-Simulation auch dessen LAN-IP als Quelle angeben.
Telnet schlägt von Außen fehl?
Hast du den Test auch von außerhalb gemacht? Manche Router haben die Eigenart, dass der Zugriff auf geNATtete Ports von Innen auf die externe IP nicht geht (z.B. Cisco und Bintec)
Grüße
Max
Hallo Danke für deine Antwort,
ISA2006 SP1 ist installiert, auch der 2004er ISA ist up2date
Jepp beide Server hängen an einem Bintec Router
Getestet wurde per telnet "echt" von aussen da die server von mir remote bedient werden.
Statefull Inspection Firewall Regeln passen auf alle fälle da die beiden OWA's bis letzte Woch noch funktioniert haben.
Das ist ja gerade das phenomenale es wurde nichts geändert oder rebootet auf einmal streiken beide Listener und die Anfragen werden gekappt.
Was meinst du genau mit der Datenverkehrssimulation ?
ISA Konnektivitätsüberprüfung vom DynDNS schlägt fehl
die Protokollierung des https Protokolls liefert das oben beschriebene ergebnis !
Stehe echt langsam aufm schlauch wie ich das sonst noch debuggen könnte, vielleicht fällt dir dazu was ein
ISA2006 SP1 ist installiert, auch der 2004er ISA ist up2date
Jepp beide Server hängen an einem Bintec Router
Getestet wurde per telnet "echt" von aussen da die server von mir remote bedient werden.
Statefull Inspection Firewall Regeln passen auf alle fälle da die beiden OWA's bis letzte Woch noch funktioniert haben.
Das ist ja gerade das phenomenale es wurde nichts geändert oder rebootet auf einmal streiken beide Listener und die Anfragen werden gekappt.
Was meinst du genau mit der Datenverkehrssimulation ?
ISA Konnektivitätsüberprüfung vom DynDNS schlägt fehl
die Protokollierung des https Protokolls liefert das oben beschriebene ergebnis !
Stehe echt langsam aufm schlauch wie ich das sonst noch debuggen könnte, vielleicht fällt dir dazu was ein
Was meinst du genau mit der Datenverkehrssimulation ?
Geh in der ISA Konsole auf "Problembehandlung" > Reiter "Datenverkehrssimulator" (wenn es den nicht gibt hast du SP1 nicht installiert). Dort wählst du "Webzugriff", gibst die IP-Adresse des Routers ein uns als Ziel die IP des Servers mit HTTPS (du kannst auch den DynDns-Domainnamen eingeben, ABER dann muss der für den ISA-Server auf die interne IP des Servers und nicht auf die des Routers zeigen).
Wenn du dann auf "Starten" klickst, solltest du sehen welche Regeln der ISA-Server für diesen Traffic anwendet.
Alternativ kannst du mal den Bintec direkt auf die IP des OWA-Server stellen, um zu testen ob der sich überhaupt ansprechen lässt.
Grüße
Max
Jepp SP1 passt, der Datenverkehrssimulator ist mir noch garnicht aufgefallen !
sb
Eingaben:
Quellparameter: IP des Servers + Port 443
Zielparameter: Dyndns/Exchange
Ergebnis:
Verweigerter Datenverkehr
Netzwerkregelname: Keine - Durch NAT impliziert (Webproxy-Datenverkehr)
Das Protokoll besagt folgendes: (fff0df64)
-Listener akzeptiert die Anferdung auf der IP Adresse des Servers
-Sucht nach einer Zugriffsverweigerungsregel, die mit dem Verkehr von der Quelle zum Ziel übereinstimmt
-Sucht nach einer Regel, die mit dem Protokoll HTTPS verbunden ist
-Prüft die Regel die dem Protokoll Https zugeordnet sind
-evaluiert die Regel "Standardregel"
-Standardregel stimmt mit dem Paket überein und verweigert es möglicherweise. Eine Regel, die dieser Regel in der Liste der RIchtlinienregeln voransteht und mit dem Paket übereinstimmt, hat jedoch Vorrang und lasst das Paket möglicherweise zu
Was kann man daraus ableiten ?
OWA Listener akzeptiert die Anfrage dennoch greift die Standardregel, die alles blockiert.
Kann es sein das der Webproxyfilter damit etwas zu tun hat ?
sb
Eingaben:
Quellparameter: IP des Servers + Port 443
Zielparameter: Dyndns/Exchange
Ergebnis:
Verweigerter Datenverkehr
Netzwerkregelname: Keine - Durch NAT impliziert (Webproxy-Datenverkehr)
Das Protokoll besagt folgendes: (fff0df64)
-Listener akzeptiert die Anferdung auf der IP Adresse des Servers
-Sucht nach einer Zugriffsverweigerungsregel, die mit dem Verkehr von der Quelle zum Ziel übereinstimmt
-Sucht nach einer Regel, die mit dem Protokoll HTTPS verbunden ist
-Prüft die Regel die dem Protokoll Https zugeordnet sind
-evaluiert die Regel "Standardregel"
-Standardregel stimmt mit dem Paket überein und verweigert es möglicherweise. Eine Regel, die dieser Regel in der Liste der RIchtlinienregeln voransteht und mit dem Paket übereinstimmt, hat jedoch Vorrang und lasst das Paket möglicherweise zu
Was kann man daraus ableiten ?
OWA Listener akzeptiert die Anfrage dennoch greift die Standardregel, die alles blockiert.
Kann es sein das der Webproxyfilter damit etwas zu tun hat ?
Du hast Quelle und Ziel falsch eingegeben.
Quelle ist: LAN-IP des Routers (weil NAT-Modus), Port: *
Ziel ist: https://<lan-ip-des-owa-server>:443/exchange
Oder, anstatt die LAN-IP kannst du auch den DynDns-Namen verwenden, dann muss der aber für den ISA-Server auf die interne IP des OWA-Servers und nicht auf die externe IP des Bintec-Routers zeigen.
Grüße
Max
Quelle ist: LAN-IP des Routers (weil NAT-Modus), Port: *
Ziel ist: https://<lan-ip-des-owa-server>:443/exchange
Oder, anstatt die LAN-IP kannst du auch den DynDns-Namen verwenden, dann muss der aber für den ISA-Server auf die interne IP des OWA-Servers und nicht auf die externe IP des Bintec-Routers zeigen.
Grüße
Max
