ISA 2004

hallo liste,

kann jemand was mit dieser fehlermeldung beim ISA 2004 anfangen?

# Fehlercode 64: Host ist nicht verfügbar
# Hintergrund: Der Gateway- oder Proxyserver hat die Verbindung mit dem Webserver verloren.

die anfrage kommt bis zur firewall sauber durch aber wird aus unerfindlichen gründen geblockt.

hmm - meine konfiguration ist etwas kompliziert.

ich habe ein 192.x.x.x netz und will einen webserver mit der ip 10.x.x.x erreichen. die verbindung kommt über eine verschlüsselte dsl-leitung zustande. besser gesagt kommt nicht zustande
der isa läuft auf einem w2k3 server mit aktuellem servicepack und soweiter.

meine regel sieht wie folgt aus:

von intern (192.x.x.x) alle benutzer
nach extern IP adresse (10.x.x.x)
jeder datenverkehr erlaubt mit allen ports frei (in meiner verzeiflung hab ich da alles freigegeben)

es wird im netz geroutet wobei zu erwähnen ist das wir am montag von nat auf routing umgestellt haben.

prinzipell funktioniert die verbindung da wir sonst kein internet und mail hätten. wenn ich mir ein protokoll geben lasse dann wird angezeigt das die verbindung getrennt wurde. (warum auch immer)

das ganze hatte unter nat funktioniert. und intressanter weise kann ich sowohl die ip anpingen als auch ein tracert drauf fahren. hat jemand vielleicht eine idee woran das liegen könnte?

shalom
reik

Ist der Webserver auf IP 10.x.x.x. im ISA veröffentlicht ?

hi stefan,

der webserver steht in einem entferntem netz. ich gehe davon aus das er auf der checkpoint dort veröffentlich ist.
auf der isa braucht man diesen ja nicht zu veröffentlichen wenn ich das mit dem routing und firewallregeln richtig verstanden habe.

ich hoffe das beantwortet deine frage erstmal.

shalom
reik

Hast du denn für diese Verbindung auch NAT aktiv ?
So, wie ich das sehe, versuchst du ja, den Webserver über eine private IP-Adresse anzusprechen, da kann NAT u.U. tödlich sein.

Cheers,
Joshua

hallo joshua,

also wir haben die verbindung von nat komplett auf routing umgestellt sonst hätten verschiedende dienste nicht funktioniert (zb. VPN mit einem hp/cisco client) - meine vorgesetzten wollen nix mehr von nat hören, mit anderen worten ich darf dieses protokoll nicht mehr einsetzen.

ja das ist korrekt - auf beiden seiten ist jeweils eine private ip obwohl das ganze bereits übers internet läuft. der router der raus zeigt hat auch nach aussen eine private ip. was dort die telekom macht kann ich nicht sagen. offensichtlich wird das ganze innerhalb einer osi-schicht durchgeroutet, so das auf beiden seiten private ip´s aussen stehen können.

shalom
reik

morgen liste,

hmm also ich habe den fehler schon mal soweit eingekreist das ich nun weiss das eine antwort von der angeforderte IP auf port 80 erwartet wird. antworten kommen aber standartmäßig nur auf port 8070 (ja ich weiss ein bescheuerte port aber ich hab ihn mir nicht ausgedacht - nur zur ehrenrettung meinereiner )

meine überlegungen sind nun folgende:

1) ich nehme die ausnahme aus den browser-einstellungen
2) ich ziehe die antwort nicht mehr direkt aus dem internet sondern nutze so wie beim surfen im internet den entfernten proxy mit der ip 10.49.254.35

diesem versuch liegt die überlegung zu grunde das wir von NAT auf Route mit dem wechsel der Firewall von ISA 2000 auf ISA 2004 gemacht haben. das heisst ja sämtliche ip´s gehen direkt raus und versuchen eine verbindung mit wem auch immer im intranet bzw. internet (bis zu checkpoint zumindestens dann wird ja auf eine öffentliche ip gegangen) aufzubauen.

hmm ... zerreisst mich bitte mal bevor ich am montag einen falschen weg versuche - weil es nicht funktionieren kann warum auch immer aus eurer sicht herraus - und damit weiter zeit verschwende. mit anderen worten ist meine überlegung erstmal grundsätlich falsch, oder ist das soweit ok? feunde netzwerker? mittlerweile sehe ich nämlich den wald vor lauter bäume nicht mehr ...

shalom
reik

hallo liste,

also die lösung des problems ist sowas von trivial gewesen das man mich schon wieder prügeln müsste. naja hier also die auflösung des knotens.

die ISA firewall 2004 hat die möglichkeit für jedes einzelne protokoll (zb. http, ftp ect.) eine webproxy einzutragen. dies geschieht nicht bei den regeln (wo man einzelne ports eingrenzen kann) sondern bei dem protokoll selbst und dort nimmt man den hacken beim webproxy herraus. und das war dann die lösung des problems.

dank an alle die sich mit den kopf zerbrochen haben.

shalom
reik