sancho79
Goto Top

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

Content-Key: 140568

Url: https://administrator.de/contentid/140568

Ausgedruckt am: 29.03.2024 um 13:03 Uhr

Mitglied: user217
user217 14.04.2010 um 10:56:04 Uhr
Goto Top
ich gehe davon aus das die Dienste nach den änderungen neu gestartet wurden...
klappts wenn du den webproxy am netzwerk deaktivierst?
benutzt du den Isa Client wegen auth?
Mitglied: Edi.Pfisterer
Edi.Pfisterer 14.04.2010 um 11:05:23 Uhr
Goto Top
Hallo!

Beachte mal folgendes:
User: anonymous
sollte hier nicht die Benutzergruppe stehen, die vom Schmuddel ausgeschlossen ist? --> Authentifizierungsproblem?

wichtiger aber:
Destination: External ( 62.214.9.144:80)
Request: GET http://www.audi.de/

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
Mitglied: sancho79
sancho79 14.04.2010 um 12:41:03 Uhr
Goto Top
Zitat von @user217:
ich gehe davon aus das die Dienste nach den änderungen neu gestartet wurden...
klappts wenn du den webproxy am netzwerk deaktivierst?
benutzt du den Isa Client wegen auth?


- ISA änderungen werden, nach meiner Erfahrung, ohne reboot eines Dienstes zb: <Microsoft Firewall> übernommen.
- nein, habe ich schon versucht -->
- fürs interne Network den Web Proxy deaktiviert - ohne Erfolg
- Auth haben wir nicht, der ISA läuft bis auf diese 2-3 URLS astrein; never change ....
Mitglied: user217
user217 14.04.2010 um 13:06:18 Uhr
Goto Top
Isa änderungen werden nur manchmal ohne reboot des dienstes übernommen!! ACHTUNG
Mitglied: sancho79
sancho79 14.04.2010 um 13:25:02 Uhr
Goto Top
Zitat von @Edi.Pfisterer:
Hallo!

Beachte mal folgendes:
> User: anonymous
sollte hier nicht die Benutzergruppe stehen, die vom Schmuddel ausgeschlossen ist? --> Authentifizierungsproblem?

wir haben kein Auth, die Schmuddel-Gruppe wird durch interne IP´s (von Admin PCs) ausgeschlossen, daher wird die korrekte rule (in dem Fall Web für Admins) gezogen mit anonymous user.

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?)

Bei mir auch nicht .... 74.125.47.105 (google) geht


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.

Allow All Outbound Traffic from <interne IP eines Clients> to External (am Client: mit externem DNS Server eintrag und Ohne Proxy):
sowohl 74.125.47.105 als auch google.de geht;
sowohl 62.214.9.144 als auch audi.de - geht nicht !!!
Laut Log zieht er sich die korrekte temporäre Regel <Any from Client IP to External>

Es kann jetzt natürlich sein, dass der Client dann trotzem über den Proxy geht; Proxy werde ich abends mal deaktivieren und dann nur für diesen Client HTTP und DNS direkt raus aktivieren.


2.) rechte Maustaste auf die Regel --> http konfigurieren --> Hackerl ENTFERNEN bei Normalisierung verifizieren und
High-Bit-Zeichen sperren

Sind beide schon drausen gewesen. (hatte ich auch schon gefunden - daran liegts net)


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.

welche Option ist beim ISA dafür verantwortlich ?


Vielen Dank erstmal... aber -->
Noch jmd ne Idee ? face-wink
Mitglied: Edi.Pfisterer
Edi.Pfisterer 14.04.2010 um 13:34:02 Uhr
Goto Top
Hola!
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... face-wink
Mitglied: Edi.Pfisterer
Edi.Pfisterer 14.04.2010 um 14:00:11 Uhr
Goto Top
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)
Mitglied: sancho79
sancho79 14.04.2010 um 14:03:11 Uhr
Goto Top
Zitat von @Edi.Pfisterer:
Hola!
> 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... face-wink

Ja, IE Proxy am Client ist raus, google geht, audi nicht face-wink
Die IP des Clients ist in der Admin rule (keine DNS filter wie in der schmuddel gruppe) drin, aber laut Logg verbindet sich der Client über korrekte test rule (any intern extern)

also wird der Client zwar seine HTTP/DNS anfragen nciht an den Proxy stellen, jedoch sollten die Web filter regeln des Proxys selbst noch gelten, oder gelten die nur für anfragen über den Proxy ?

Dann wäre es sehr verwunderlich, das der client obwohl er seine anfragen nicht an den Proxy stellt trotzdem nicht auf Audi.de kommt.

Und mir ist noch aufgefallen, wenn ich über google auf einen "tieferen Link" (http://www.audi.de/de/brand/de.html) gehe, geht es ?!?!?!
ISA Log: GET http://92.122.207.177/de/brand/

aber bei www.audi.de loggt der ISA:
GET http://92.122.207.177/
?!?!?!?

Gruß
Mitglied: sancho79
sancho79 14.04.2010 um 14:07:12 Uhr
Goto Top
Zitat von @Edi.Pfisterer:
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...).


nslookup www.audi.de
Non-authoritative answer:
Name: a1845.ga.akamai.net
Addresses: 62.214.9.144, 62.214.9.135
Aliases: www.audi.de, www.audi.de.edgesuite.net

ISA Loggt auf Audi.de: GET http://92.122.207.177/
Mitglied: Edi.Pfisterer
Edi.Pfisterer 14.04.2010 um 23:33:18 Uhr
Goto Top
Hallo!
lass uns mal zusammenfassen:
post 1:
Destination: External ( 62.214.9.144:80)
Request: GET http://www.audi.de/

weiter unten dann:
nslookup www.audi.de
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/

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

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
Mitglied: Edi.Pfisterer
Edi.Pfisterer 20.04.2010 um 08:53:43 Uhr
Goto Top
Freut mich, dass es nun bei Dir funktioniert!
Gern geschehen, danke für das positive Feedback!

lg
Ironimus Edi
Mitglied: sancho79
sancho79 20.04.2010 um 09:16:17 Uhr
Goto Top
tut mir leid, ich kam die letzten Tage nicht dazu, massive Probleme hier.

Aber ich danke dir schon mal für deine Hilfe face-wink

also:

212.152.163.10 bzw. 62.214.9.144 sind pingbar.
Ich schätze nicht, dass es ein ISP Problem ist, da wir vor ca 2 Monaten den Provider gewechselt haben und das Problem vorher und nacher bestand.

so jetzt wirds witzig ....

ping www.audi.de
Pinging a1845.ga.akamai.net [62.214.9.144] with 32 bytes of data:
Reply from 62.214.9.144: bytes=32 time=33ms TTL=53
...

per browser:

Error Code: 500 Internal Server Error. The request is not supported. (50)

Ich versuche gleich noch etwas anderes - ich meld mich
Mitglied: Edi.Pfisterer
Edi.Pfisterer 20.04.2010 um 10:16:16 Uhr
Goto Top
hm...
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...
Mitglied: sancho79
sancho79 20.04.2010 um 15:13:52 Uhr
Goto Top
so jetzt aber .... hier is die hölle los ^^

ich habe nen Client vor die Firewall gehängt (ins Netz zwischen Router und Firewall)....

Es MUSS ein ISA Problem sein:

google.de geht
audi.de geht !!!

ping www.audi.de
62.214.9.144

das selbe auf der Firewall (Auch ISA2004 - welche VOR dem Proxy hängt !)
ping www.audi.de
62.214.9.135
geht

per Browser:
Error Code: 500 Internal Server Error. The request is not supported. (50)


Bei den IP´s ist zwar ein unterschied, aber wenn ich den Ping nach ein paar minuten wiederhole, bekomme ich eine andere IP angezeigt (einmal 144 einmal 135)

beide haben den selben DNS Server eingetragen - FW und Client. Und auch die ISP und die damit verbundene DNS Server Änderung lässt auf ein ISA Problem schliessen.


Gruß
SanCho
Mitglied: sancho79
sancho79 20.04.2010 um 15:25:34 Uhr
Goto Top
Mitglied: sancho79
sancho79 20.04.2010 um 15:30:57 Uhr
Goto Top
du meinst im AD als Host audi.de mit der IP 212.152.163.10 eintragen ?
Mitglied: Edi.Pfisterer
Edi.Pfisterer 20.04.2010 um 16:19:28 Uhr
Goto Top
du meinst im AD als Host audi.de mit der IP 212.152.163.10 eintragen ?
ja, meinte ich...
ich denk mal weiter nach face-wink
(und geh jetzt heim, hier ist (nicht mehr) die hölle los face-wink
lg
Edi
Mitglied: sancho79
sancho79 21.04.2010 um 07:46:35 Uhr
Goto Top
URL wird dann zwar korrekt aufgelöst (als 212.152.163.10) aber zum Erfolg führt das nicht.
Mitglied: Edi.Pfisterer
Edi.Pfisterer 21.04.2010 um 08:30:28 Uhr
Goto Top
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...
Mitglied: sancho79
sancho79 22.04.2010 um 09:54:45 Uhr
Goto Top
Viel Lärm um nichts ..... hätte ich doch mal lieber auf dich gehört <user217> *aber ich hab was draus gelernt*

Lösung des Problems war:

in der ISA2004 config -> Add-ins -> Web Filters:
den "Compression Filter" zu AKTIVIEREN

UND danach den Firewall Dienst NEU ZU STARTEN.

Vielen Dank für eure Hilfe.

Gruß
SanCho

@MOD´s: Ihr könnt alles ab hier löschen, da diese Versuche in die falsche Richtung geführt haben.... "urobe73" Danke dir trotzem für dein bemühen.
Mitglied: Edi.Pfisterer
Edi.Pfisterer 22.04.2010 um 11:54:09 Uhr
Goto Top
Hallo!
Du hast den Beitrag als gelöst markiert..
woran lag es nun? würde mich persönlich interessieren...

lg
Edi
Mitglied: sancho79
sancho79 23.04.2010 um 09:35:49 Uhr
Goto Top
mein resolve war weiter oben.....

Lösung des Problems war:

in der ISA2004 config -> Add-ins -> Web Filters:
den "Compression Filter" zu AKTIVIEREN

UND danach den Firewall Dienst NEU ZU STARTEN.

Vielen Dank für eure Hilfe.

Gruß
SanCho