Isa 2004 proxy Error Code 500 Internal Server Error. The request is not supported. 50
Hi,
wir haben einen ISA2004 SP3 (auf 2k3) welcher als Proxy fungiert.
Nun haben wir seit längerem das Problem, dass bei bestimmten Homepages folgende Fehlermeldung am Client im Browser kommt:
Error Code: 500 Internal Server Error. The request is not supported. (50)
IP Address: <aufgelöste IP der Seite>
Date: 4/14/2010 7:13:14 AM
Server: <Isa Hostname>
Source: proxy
Dieses Problem tritt bei allen Clients nur bei bestimmten URLs auf (zB: www.audi.de, http://www.rhapsody.com/ ...) und das unabhängig vom Browser, da der Proxy, vermute ich, wegen irgend einer Filtereinstellungen diese Seite blockt.
Auch auf dem ISA selbst kommt die selbe Fehlermeldung.
Es existieren 2 Web Access Policies für User mit div. gesperrten schmuddel Seiten und für Admins ohne Ausnahmen (allow FTP HTTP HTTPS von intern nach extern). Aber die Seiten sind nicht in der DNS Filter Liste enthalten, da mit der Admin Rule die selbe FM kommt.
Ich habe verschiedene Lösungsansätze testweise versucht:
- Loggin auf die IP des Clients:
Allowed Connection <ISA Hostname> <Datum>
Log type: Web Proxy (Forward)
Status: 500 Internal Server Error
Rule: <Admin Web Rule>
Source: Internal ( <Client IP>:0)
Destination: External ( 62.214.9.144:80)
Request: GET http://www.audi.de/
Filter information: Req ID: 0c1cbc3e
Protocol: http
User: anonymous
Additional information
Client agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 2.0.50727)
Object source: Internet Processing time: 141
Cache info: 0x48040000 MIME type:
- alle Add-ins -> Web Filter deaktiviert - ohne Erfolg
- Add-ins -> Application Filter: Web Proxy, DNS Filter deaktiviert - ohne Erfolg
- fürs interne Network den Web Proxy deaktiviert - ohne Erfolg
- hierfür die Authentication testweise ein und wieder aus geschalten - ohne Erfolg
- Connection timeout erhöht - ohne Erfolg
- Config -> General -> Define HTTP Compression Preferences -> alle content Types werden nicht compressed
- Content Inspection deaktiviert - ohne Erfolg
- Link Translation für HTML Documents deaktivert - ohne Erfolg
- für das Protokoll HTTP den Web Proxy Filter deaktiviert - ohne Erfolg
- HTTP Caching deaktiviert - ohne Erfolg
- Proxy Cache gelöscht - ohne Erfolg
- alle Clients haben die korrekte Proxy Einstellung - <Proxy IP>:8080 ohne Auth.
Kennt jedmand das selbe Problem, oder hat es mal gelöst ? Angeblich soll dies seit ISA SP2 bekannt sein aber mit SP3 gelöst, was bei uns aber nicht zutrift.
Oder hat jemand eine Idee, was ich noch versuchen könnte?
Die selbe FM gibt es auch im Zusammenhang mit OWA (wenn man sie googled), was wir auch im Einsatz haben, aber auch dessen deaktiverung brachte keinen Erfolg.
Gruß
Sancho
wir haben einen ISA2004 SP3 (auf 2k3) welcher als Proxy fungiert.
Nun haben wir seit längerem das Problem, dass bei bestimmten Homepages folgende Fehlermeldung am Client im Browser kommt:
Error Code: 500 Internal Server Error. The request is not supported. (50)
IP Address: <aufgelöste IP der Seite>
Date: 4/14/2010 7:13:14 AM
Server: <Isa Hostname>
Source: proxy
Dieses Problem tritt bei allen Clients nur bei bestimmten URLs auf (zB: www.audi.de, http://www.rhapsody.com/ ...) und das unabhängig vom Browser, da der Proxy, vermute ich, wegen irgend einer Filtereinstellungen diese Seite blockt.
Auch auf dem ISA selbst kommt die selbe Fehlermeldung.
Es existieren 2 Web Access Policies für User mit div. gesperrten schmuddel Seiten und für Admins ohne Ausnahmen (allow FTP HTTP HTTPS von intern nach extern). Aber die Seiten sind nicht in der DNS Filter Liste enthalten, da mit der Admin Rule die selbe FM kommt.
Ich habe verschiedene Lösungsansätze testweise versucht:
- Loggin auf die IP des Clients:
Allowed Connection <ISA Hostname> <Datum>
Log type: Web Proxy (Forward)
Status: 500 Internal Server Error
Rule: <Admin Web Rule>
Source: Internal ( <Client IP>:0)
Destination: External ( 62.214.9.144:80)
Request: GET http://www.audi.de/
Filter information: Req ID: 0c1cbc3e
Protocol: http
User: anonymous
Additional information
Client agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; .NET CLR 3.0.4506.2152; .NET CLR 2.0.50727)
Object source: Internet Processing time: 141
Cache info: 0x48040000 MIME type:
- alle Add-ins -> Web Filter deaktiviert - ohne Erfolg
- Add-ins -> Application Filter: Web Proxy, DNS Filter deaktiviert - ohne Erfolg
- fürs interne Network den Web Proxy deaktiviert - ohne Erfolg
- hierfür die Authentication testweise ein und wieder aus geschalten - ohne Erfolg
- Connection timeout erhöht - ohne Erfolg
- Config -> General -> Define HTTP Compression Preferences -> alle content Types werden nicht compressed
- Content Inspection deaktiviert - ohne Erfolg
- Link Translation für HTML Documents deaktivert - ohne Erfolg
- für das Protokoll HTTP den Web Proxy Filter deaktiviert - ohne Erfolg
- HTTP Caching deaktiviert - ohne Erfolg
- Proxy Cache gelöscht - ohne Erfolg
- alle Clients haben die korrekte Proxy Einstellung - <Proxy IP>:8080 ohne Auth.
Kennt jedmand das selbe Problem, oder hat es mal gelöst ? Angeblich soll dies seit ISA SP2 bekannt sein aber mit SP3 gelöst, was bei uns aber nicht zutrift.
Oder hat jemand eine Idee, was ich noch versuchen könnte?
Die selbe FM gibt es auch im Zusammenhang mit OWA (wenn man sie googled), was wir auch im Einsatz haben, aber auch dessen deaktiverung brachte keinen Erfolg.
Gruß
Sancho
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 140568
Url: https://administrator.de/contentid/140568
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
22 Kommentare
Neuester Kommentar
Hallo!
Beachte mal folgendes:
wichtiger aber:
ein nslookup ergbit bei mir folgendes:
Name: a62-214-9-144.deploy.akamaitechnologies.com
Address: 62.214.9.144
Name: a1845.ga.akamai.net
Addresses: 212.152.163.10, 212.152.163.17
Aliases: www.audi.de, www.audi.de.edgesuite.net
Interessant ist daran folgendes:
ein Zugriff auf die Seite per IP 62.214.9.144 oder 212.152.163.10 oder 212.152.163.17 funktioniert nicht....
(zumindest bei mir - vielleicht kann das jemand bestätigen?)
den selben Effekt hast Du bei rhapsody:
Name: a291.g.akamai.net
Addresses: 212.152.163.32, 212.152.163.10
Aliases: www.rhapsody.com, www.rhapsody.com.edgesuite.net
(Beachte, wie nah die IP-Adressen der beiden Sites beeinander liegen...)
ich vermute, dass die Webserver so konfiguriert sind, dass er auf die URL achtet (einiger meiner Webserver sind ebenfalls so konfiguriert..) und daher nehme ich an, das Problem liegt an der Weitergabe der URL an die externen Webserver via ISA.
Versuche mal folgendes:
1.) eine Regel gesamter Datenverkehr Intern -> extern für alle (an 1. Stelle!).
Wenn du nun auf audi kommst, kannst Du zumindest mal DNS Probleme ausschliessen und sicherstellen, dass es an deinen anderen Regeln liegt.
2.) rechte Maustaste auf die Regel --> http konfigurieren --> Hackerl ENTFERNEN bei Normalisierung verifizieren und High-Bit-Zeichen sperren
lg
Edi
Beachte mal folgendes:
User: anonymous
sollte hier nicht die Benutzergruppe stehen, die vom Schmuddel ausgeschlossen ist? --> Authentifizierungsproblem?wichtiger aber:
ein nslookup ergbit bei mir folgendes:
62.214.9.144
Name: a62-214-9-144.deploy.akamaitechnologies.com
Address: 62.214.9.144
www.audi.de
Nicht autorisierte Antwort:Name: a1845.ga.akamai.net
Addresses: 212.152.163.10, 212.152.163.17
Aliases: www.audi.de, www.audi.de.edgesuite.net
Interessant ist daran folgendes:
ein Zugriff auf die Seite per IP 62.214.9.144 oder 212.152.163.10 oder 212.152.163.17 funktioniert nicht....
(zumindest bei mir - vielleicht kann das jemand bestätigen?)
den selben Effekt hast Du bei rhapsody:
www.rhapsody.com
Nicht autorisierte Antwort:Name: a291.g.akamai.net
Addresses: 212.152.163.32, 212.152.163.10
Aliases: www.rhapsody.com, www.rhapsody.com.edgesuite.net
(Beachte, wie nah die IP-Adressen der beiden Sites beeinander liegen...)
ich vermute, dass die Webserver so konfiguriert sind, dass er auf die URL achtet (einiger meiner Webserver sind ebenfalls so konfiguriert..) und daher nehme ich an, das Problem liegt an der Weitergabe der URL an die externen Webserver via ISA.
Versuche mal folgendes:
1.) eine Regel gesamter Datenverkehr Intern -> extern für alle (an 1. Stelle!).
Wenn du nun auf audi kommst, kannst Du zumindest mal DNS Probleme ausschliessen und sicherstellen, dass es an deinen anderen Regeln liegt.
2.) rechte Maustaste auf die Regel --> http konfigurieren --> Hackerl ENTFERNEN bei Normalisierung verifizieren und High-Bit-Zeichen sperren
lg
Edi
Hola!
Test, ob der Client über den Proxy geht:
Einfach diese IP aus der Rule "ANTISCHMUDDEL" entfernen...
Google sollte danach noch erreichbar sein, er sollte den proxy allerdings umgehen...
ich denke im übrigen weiter nach...
Es kann jetzt natürlich sein, dass der Client dann trotzem über den Proxy geht;
Hast du im Browser das Hakerl "Proxy" deaktiviert, nachdem Du die Regel erstellt hast?Test, ob der Client über den Proxy geht:
Einfach diese IP aus der Rule "ANTISCHMUDDEL" entfernen...
Google sollte danach noch erreichbar sein, er sollte den proxy allerdings umgehen...
ich denke im übrigen weiter nach...
Anmerkungen:
Stimmt Dein DNS? überprüf mal, ob eine nslookup-Abfrage das selbe Ergebnis wie bei mir (siehe oben) bringt...
(ich komme über www.audi.de NICHT auf 62.214.9.144)
bei mir protokolliert ISA beim Aufruf von www.audi.de als ZIEL-IP 212.152.163.17 - wie auch mein nslookup mein (logischerweise...).
ansonsten schaut mein LOG so aus wie deins...
(als schwacher Trost)
Stimmt Dein DNS? überprüf mal, ob eine nslookup-Abfrage das selbe Ergebnis wie bei mir (siehe oben) bringt...
(ich komme über www.audi.de NICHT auf 62.214.9.144)
bei mir protokolliert ISA beim Aufruf von www.audi.de als ZIEL-IP 212.152.163.17 - wie auch mein nslookup mein (logischerweise...).
ansonsten schaut mein LOG so aus wie deins...
(als schwacher Trost)
Hallo!
lass uns mal zusammenfassen:
post 1:
weiter unten dann:
das würde ja mit dem 1. post zusammenpassen....
dann aber:
hm...
hingegen ergibt MEINE nslookup (die ja bekanntlich zu gewünschtem Erfolg führt):
fällt dir was auf?
Es ist nicht Dein ISA das Problem, sondern Dein DNS!!!
Jedes Pakt, dass von Intern nach Extern geht, wird über den Proxy versendet via ISA. Eine Regel Intern->Extern->Any-> lässt einfach nur alle Scheunentore von innen nach aussen offen....
DNS-Abfragen werden generell an den DNS-Server gesendet, der über DHCP verteilt wird (und in Deinem Fall sollte dies natürlich dein eigener DNS sein...).
Die einzige offene Frage ist nun:
liegt das Problem
a) an Deinem DNS
b) am DNS Deines Providers (von dem Dein DNS ja seine Infos bekommt)
oder
c) du hast zwar ein DNS-Problem, das allerdings nicht dir Ursache allen Übels ist, sondern möglicherweise blockt Dein Provider (irrtümlich) den IP-Range
212.152.163.X
Frage, um c) ausschliessen zu können:
kannst Du 212.152.163.10 bzw. 62.214.9.144 anpingen? bei mir geht dies...
lg
edi
lass uns mal zusammenfassen:
post 1:
weiter unten dann:
nslookup www.audi.de
Non-authoritative answer:
Name: a1845.ga.akamai.net
Addresses: 62.214.9.144, 62.214.9.135
Non-authoritative answer:
Name: a1845.ga.akamai.net
Addresses: 62.214.9.144, 62.214.9.135
das würde ja mit dem 1. post zusammenpassen....
dann aber:
ISA Log: GET http://92.122.207.177/de/brand/
aber bei www.audi.de loggt der ISA:
GET http://92.122.207.177/
aber bei www.audi.de loggt der ISA:
GET http://92.122.207.177/
hm...
hingegen ergibt MEINE nslookup (die ja bekanntlich zu gewünschtem Erfolg führt):
www.audi.de
Nicht autorisierte Antwort:
Name: a1845.ga.akamai.net
Addresses: 212.152.163.10, 212.152.163.17
Aliases: www.audi.de, www.audi.de.edgesuite.net
Nicht autorisierte Antwort:
Name: a1845.ga.akamai.net
Addresses: 212.152.163.10, 212.152.163.17
Aliases: www.audi.de, www.audi.de.edgesuite.net
fällt dir was auf?
Es ist nicht Dein ISA das Problem, sondern Dein DNS!!!
also wird der Client zwar seine HTTP/DNS anfragen nciht an den Proxy stellen
ist so NICHT richtig! leider...Jedes Pakt, dass von Intern nach Extern geht, wird über den Proxy versendet via ISA. Eine Regel Intern->Extern->Any-> lässt einfach nur alle Scheunentore von innen nach aussen offen....
DNS-Abfragen werden generell an den DNS-Server gesendet, der über DHCP verteilt wird (und in Deinem Fall sollte dies natürlich dein eigener DNS sein...).
Die einzige offene Frage ist nun:
liegt das Problem
a) an Deinem DNS
b) am DNS Deines Providers (von dem Dein DNS ja seine Infos bekommt)
oder
c) du hast zwar ein DNS-Problem, das allerdings nicht dir Ursache allen Übels ist, sondern möglicherweise blockt Dein Provider (irrtümlich) den IP-Range
212.152.163.X
Frage, um c) ausschliessen zu können:
kannst Du 212.152.163.10 bzw. 62.214.9.144 anpingen? bei mir geht dies...
lg
edi
hm...
bei mir:
DNS-troubles?
trag mal fix die 212.x.x.x bei Dir im DNS ein, und schau, was dann passiert...
bei mir:
H:\SCRIPTS\aufloesung ermitteln>ping www.audi.de
Ping a1845.ga.akamai.net [212.152.163.10] mit 32 Bytes Daten:
Antwort von 212.152.163.10: Bytes=32 Zeit=100ms TTL=54
Antwort von 212.152.163.10: Bytes=32 Zeit=87ms TTL=54
Antwort von 212.152.163.10: Bytes=32 Zeit=114ms TTL=54
DNS-troubles?
trag mal fix die 212.x.x.x bei Dir im DNS ein, und schau, was dann passiert...
Hallo!
Hast du wirklich folgnede Konfig:
n Clients --> ISA2004(proxy) --> ISA2004(=firewall) --> Router --> ISP
und weiter:
Client zwischen firewall + Router --> audi funkt
client zwischen isa2004(proxy) + isa2004(firewall) --> audi funkt
clienth hinter isa 2004(proxy) --> audi funkt nicht
btw: wozu betreibst Du 2 ISA-Server hintereinander? Falls es um die DMZ geht: die könntest Du auch auf einer 3. Netzwerkkarte auf 1 ISA dranhängen (ich frage nur interessenshalber)
Kann es sein (falls meine Annahmen von oben stimmen), dass der proxy den URL nicht vernünftig an den ISA(firewall) weitergibt und daher gehen diese Seiten nicht (die offensichtlich beim Aufruf den URL überprüfen!!! Sonst würde es ja mit der IP-Adresse im Browser funtkionieren - so wie bei allen anderen Seiten im WWW).
hm...
Hast du wirklich folgnede Konfig:
n Clients --> ISA2004(proxy) --> ISA2004(=firewall) --> Router --> ISP
und weiter:
Client zwischen firewall + Router --> audi funkt
client zwischen isa2004(proxy) + isa2004(firewall) --> audi funkt
clienth hinter isa 2004(proxy) --> audi funkt nicht
btw: wozu betreibst Du 2 ISA-Server hintereinander? Falls es um die DMZ geht: die könntest Du auch auf einer 3. Netzwerkkarte auf 1 ISA dranhängen (ich frage nur interessenshalber)
Kann es sein (falls meine Annahmen von oben stimmen), dass der proxy den URL nicht vernünftig an den ISA(firewall) weitergibt und daher gehen diese Seiten nicht (die offensichtlich beim Aufruf den URL überprüfen!!! Sonst würde es ja mit der IP-Adresse im Browser funtkionieren - so wie bei allen anderen Seiten im WWW).
hm...