Hallo Leutz,

De Fehlermeldung Error 64 ist leider auch mehrdeutig:
http://blogs.technet.com/isablog/archive/2009/01/30/users-receive-an-error-64-when-browse-a-web-site-published-through-isa-sever-2006.aspx
http://blogs.technet.com/yuridiogenes/archive/2008/11/23/error-64-the-specified-network-name-is-no-longer-available-while-browsing-internet-through-isa-server-2006.aspx
http://blogs.technet.com/yuridiogenes/archive/2008/10/09/error-64-from-the-field-to-the-classroom.aspx

Heute Morgen hat sich der Kunde wieder gemeldet und eine Loesung fuer die Problematik gefunden, welche ich Euch nicht vorenthalten moechte:

Auszug aus der e-mail des Kunden
Thema: Error64
Aussage: Wir hatten/haben auf manchen Webseiten massiv den Error64 vom Isa bekommen und ich hab mich da mal reingehängt, was rauszufinden. 
Kunden-Konstellation:
Client->ISA2006->Firewall (NAT von LAN auf public IP)->bluecoat-Proxy(T-systems)->Internet

Da der ISA dem Client den Error64 schickte, hab ich mich mal VOR den ISA geklemmt. Und siehe da, der Blueacoat schickt dem ISA einen TCP FIN ACK, mit der Auswirkung, dass der Client einen Error64 vom ISA bekommt.
Hab mich dann mal mit den Bluecoat-Spezies hingesetzt und wir haben ein paar “Features” ausprobiert. Und siehe da, beim deaktivieren von “reflected-IP” funktionierte die Webseite fehlerfrei!
Reflected-IP funktioniert so, das der Proxy ja eigentlich mit der public IP vom ISP im Internet hängt. Laut Gesetz darf das aber nicht, wenn da mehrere Kunden darüber laufen. Also wird vorher (bei uns auf der Firewall) von LAN auf Public IP genattet und diese/unsere public IP vom Proxy als Source IP genutzt. Das bewirkt das die Anfragen von uns mit der Public IP von uns und nicht mit der von T-Systems ins Netz gehen. Und der Prozess auf dem Proxy nennt sich “Reflected IP”. Deaktiviert man diesen (für eine bestimmte Webseite, wo es massiv auftaucht), funktioniert es!!!
Wo genau es nun am Proxy liegt und ob er sich RFC konform verhällt bleibt abzuwarten. Könnte auch mit Content-Legth-Headern zu tun haben, beim Zwischenspeichern vom Proxy, wo der in dem Fall einen FIN ACK rausjagt, aber das bleibt noch abzuwarten.

NACHTRAG vom 07.07.2010: Mein Kunde hat das Problem geloest:
“Nachdem unser “ISP” auf dem Bluecoat als globales setting den Befehl http.client.persistence(preserve)
eingetragen hat, war der Spuk mit dem error64 endlich vorbei!!!  ”

Gruss Marc

Hallo Leutz,

Nach der Implementierung von Forefront TMG kam es in unregelmaessigen Abstaenden, leider nicht reproduzierbar zu der Fehlermeldung Fehlercode 500: Interner Serverfehler beim Aufruf von Webseiten im Browser. Durch mehrfaches betaetigen der F5 Taste konnte die Webseite wieder dargestellt werden.
Wie der Fehler gefunden und behoben werden konnte steht in diesem Bilderbuch:

http://www.it-training-grote.de/download/0xc0040011%20FWX_E_IS_BUSY.pdf

Stichworte: (0xc0040011 FWX_E_IS_BUSY, EDNS, UDP 512 Byte, Cache vor Beschaedigung sichern)

Gruss Marc

Hallo Leutz,

dieser Beitrag ergaenzt die Aussage des Microsoft TMG Support aus meinem Artikel:
http://www.it-training-grote.de/blog/?p=2591
In dem Artikel steht, dass man mit Forefront TMG keine Ausnahmen von der HTTPS Inspection fuer IP-Adressen machen kann.
Die Original Aussage des MS Support war:

“No, but if you know the certificate subject and SAN names used by those services, you can enter those in the exceptions.
TMG uses the subject and SAN attributes to determine if the upstream server is “exceptional” as well as how to build the spoof cert if it needs to. The primary reason IPs aren’t usable is that in the hosted cloud Internet of today, IP addresses do not represent anything even remotely like “identity” and identity is exactly the context in which certificate validation operates.”

Dem scheint nicht so zu sein. In einem Posting in der deutschen ISA Server Newsgroup vom 30.04.2010 schreibt Alex111:
“Nachtrag: zum Glück erlaubt es TMG die IP wie folgt einzugeben. So hat es bei mir funktioniert: *.236.97.247”

Gruss Marc