%20hinter%20der%20TMG-Firewall%20sind%20nur%20mit%20einigen%20Browsern%20nicht%20zug%C3%A4nglich.png)
Ich habe eine Site mit Forefront TMG als HTTPS-Website veröffentlicht. Sie verfügt über ein gültiges SSL-Zertifikat (EV). Die Site wird in allen Browsern außer Safari, Midori und Dolphin korrekt angezeigt.
Das Problem ist, dass bei Safari überhaupt keine Verbindung zur Website besteht. Als ob die Website überhaupt nicht auf die Anfrage antwortet. Es wird keine Datei übertragen. Die Verbindung ist komplett tot. Zumindest für eine lange Zeit (30 Sekunden bis ein paar Minuten).
Ich habe mehrere verschiedene Websites über HTTPS konfiguriert. Verschiedene Domänen, verschiedene IPs und verschiedene Zertifikate. Die Zertifikate stammen von verschiedenen Ausstellern.
Das Problem besteht bei allen meinen HTTPS-Websites, NUR mit den Browsern Safari, Midori und Dolphin. Alle 3 Websites funktionieren in allen anderen Browsern einwandfrei. Keine Verzögerungen, keine gemeldeten Probleme.
Ich habe versucht, die Umleitung von HTTP auf HTTPS beim TMG-Listener zu deaktivieren, um das Zertifikatsproblem auszuschließen. Ich kann auch nicht über http auf meine Websites zugreifen. Sie sind jedoch von den Browsern Firefox, Opera, Chrome, IE, Vivaldi, Slimjet und Edge aus problemlos zugänglich.
Manchmal kann ich eine einzelne Seite in Safari anzeigen, aber es dauert über 30 Sekunden, bis sie angezeigt wird, wobei einige Bilder (und/oder CSS) fehlen. Dann schlägt die Website fehl, weil AJAX auf der Seite fehlschlägt, obwohl die CORS-Header richtig konfiguriert sind und referenzierte URLs sogar antworten können (mit enormen Verzögerungen).
Es sieht so aus: Sie geben die URL ein und erhalten eine Meldung, dass die Site nicht erreichbar ist. Wenn Sie die Seite dann mehrmals aktualisieren, wird sie schließlich angezeigt, allerdings stark beschädigt (z. B. waren viele Dateien nicht erreichbar).
Auf anderen Browsern gibt es keine Verzögerungen. Alle Dateien sind sofort zugänglich.
Auf meiner Registerkarte „Webzugriffsrichtlinie“ habe ich alle Überprüfungs- und Proxyoptionen deaktiviert.
Das Seltsamste daran ist, dass ich eine andere Site (HTTP) auf demselben Server habe, die aber unter einer anderen IP-Adresse veröffentlicht ist. Die Site funktioniert in ALLEN Browsern problemlos. Alle IP-Adressen und das Routing scheinen richtig konfiguriert zu sein. Wenn das nicht der Fall wäre, wie würden die anderen Browser die Sites dann anzeigen?
Übrigens liegt es zu 100 % nicht an den Websites selbst. Selbst wenn ich versuche, eine einzelne HTML-Datei oder ein Bild von der Site zu öffnen, kann es mit Safari nicht abgerufen werden.
WICHTIG: Die SSL-Zertifikatsinformationen der Site werden korrekt angezeigt. Dies ist das Einzige, was von diesen Sites heruntergeladen wird. Ich sehe also das Vorhängeschlosssymbol und Site-Informationen, aber keinen Inhalt. Nachdem ich HTTP-Verbindungen zugelassen habe, funktioniert es auch nicht über HTTP. Funktioniert in einigen Browsern über HTTP.
WICHTIG: Die genannten Sites sind alle in allen Browsern zugänglich, wenn TMG weggelassen wird (über VPN, bei direkter Bezugnahme auf meine NLB-IP).
Das Problem begann, als wir unsere virtuellen Server auf neue Hosts im neuen Netzwerk verschoben haben. Im alten Netzwerk funktionierte alles. Aber andererseits – was hat die interne Netzwerkkonfiguration damit zu tun, dass Websites nur in bestimmten Browsern nicht zugänglich sind?
Aktualisieren
Ich habe viele Dinge ausprobiert, z. B. die MTU der CISCO ASA-Firewall geändert, aber es hat nicht geholfen. Ich habe versucht, meine SSL-Konfiguration auf TMG mithilfe dieses Tutorials zu aktualisieren:
Verbessern der SSL-Sicherheit auf Forefront TMG
Ich endete damit, dass der Test nicht einmal abgeschlossen wurde. Außerdem bekomme ich eine Warnung über „inkonsistente Serverkonfiguration“. Und es stoppt mit der Meldung „Langer Handshake-Workaround: Hanshake nicht länger als 0x200 Bytes: 132“. Nun, ich habe die Domänen www.example.com und example.com auf unterschiedliche Adressen eingestellt. Das ist Absicht. Und es gibt ein paar Umleitungen zwischen den beiden. Übrigens hat die WWW-Site ihr eigenes Zertifikat für den Fall, dass jemand ihre URL mit https eingegeben hat. Aber es wird meistens nicht verwendet. Und ja, ich habe das Zertifikat des Nicht-WWW-Servers ersetzt, aber das WWW bleibt ohne Update. Es ist ein Fehler, aber er sollte nur die WWW-Site betreffen. Aber die, die sich schlecht verhält, isthttps://example.com, nichthttps://www.example.com.
Was ist falsch? Da es beim letzten Mal gut funktionierte, hatte ich dieselbe TMG-VM auf einem anderen Host. Ich hatte meine Sites auf verschiedenen (älteren) IIS-Servern. Ich hatte verschiedene externe IPs und keine DMZ. Und das Zertifikat war anders, älter, mit einem 128-Bit-Schlüssel statt einem 256-Bit-Schlüssel. Es gab keine CISCO ASA-Firewall. Nachdem wir alle Websites auf neue Maschinen verschoben hatten, passierte es. Sie funktionieren mit jedem Browser außer Safari, Midori und Dolphin.
Aktualisieren
Ich bin über VPN und ASA mit dem internen Netzwerk verbunden. Wenn ich die IP-Adresse meiner Site-Domain direkt auf die interne NLB-Adresse einstelle, funktioniert es. Wenn ich die DMZ-IP einstelle, funktioniert es nicht. Und natürlich funktioniert es auch nicht auf einer externen IP. Natürlich funktionieren alle 3 Pfade in den meisten Browsern einwandfrei, nur Safari, Midori und Dolphin sind betroffen.
Übrigens leitet derselbe CISCO ASA meine Webanforderungen an das öffentliche Netzwerk weiter.
BTW2: Reine HTTP-Site (ohne Zertifikat) von demselben IIS->NLB->TMG->DMZ->ASA – funktioniert mit Safari ohne Verzögerungen oder andere Probleme. Das einzige, was ich nicht getestet habe, war das Entfernen des Zertifikats und das Einstellen von ausschließlich HTTP-Zugriff. Es handelt sich um eine Produktionswebsite. Wenn ich es versuchen würde, müsste ich es nachts und in großer Eile tun.
Antwort1
Das klingt nach einem grundlegenden Problem mit der Netzwerkverbindung. Die Symptome sind typisch für eine falsch konfigurierte MTU. Alternativ kann es sein, dass TGM etwas aus dem Takt bringt, aber ich weiß nicht genug darüber, um das sagen zu können.
Ich würde empfehlen, zunächst mit einer reduzierten MTU zu testen. Ein guter Anfang wäre, entweder den Server oder den Client oder beide auf eine MTU von 1200 einzustellen. Alternativ könnten Sie die Verbindung per Wireshark prüfen, um zu sehen, welche Art von TCP-Parametern ausgehandelt werden, und von dort aus weitermachen.
[Bearbeiten] Das Ändern der MTU unter Windows hängt etwas von der von Ihnen ausgeführten Windows-Version ab. Da dies nicht angegeben ist, habe ich nur das allgemeine Google-Ergebnis bereitgestellt: