Re: Web Chaining - Ausgehender Port für SSL

ich denke, es funktioniert so, wie es sollte.
:-)
deine clients stellen ihre cern-kompatiblen webproxyclientanfragen an den
isa, weil du ihre browserkonfigurationen angepasst hast (isa:8080).
der isa würde diese requests jetzt stellvertretend (proxy) für deine clients
ins inet schicken. die responses der webserver (ob nun verschlüsselt oder
nicht) gehen an die clients zurück.
in deinem fall gibt es "nur" eine weitere zwischenstation.
somit schickt dein isa die requests an den squid und bittet jenen wiederum
als stellvertreter (proxy representative) zu agieren.
der squid geht also ins inet holt den krams ab (verschlüsselt oder
unverschlüsselt je nach request) und gibt die inhalte dem isa zurück.
der wiederum versorgt deine clients.
wenn deine clients jetzt einen https-request abschicken und dieser auch
korrekt beantwortet wird und sie auf die passenden sites zugreifen können,
dann ist eigentlich alles wunderbar. das der "interne"
webproxyclientanfragen-verkehr bis hin zu den jeweiligen proxys
verschlüsselt wird ist zumindest bei meinen kunden selten der fall, da diese
strecken meistens eh geschützter sind.
möchtest du aber, das selbst die requests zum und zwischen den proxys
verschlüsselt werden, dann müsstest du dies z.b. beim isa über den port 8443
(default) initialisieren (achtung serverzertifikat nötig!). aber ob dein
squid die anfragen via webverkettungsregel dann auch verschlüsselt
entgegennehmen kann, kann ich dir nicht sagen.
(btw.: ein single-nic-isa ist wie mitm porsche mit maximal 30km/h über die
autobahn. hihi)
gruss, jens mander...




"Jens Weibler" <Jtb@xxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:uVosGnxgGHA.3956@xxxxxxxxxxxxxxxxxxxxxxx
ich dachte eigentlich, dass der ISA-Server den Webrequest auseinandernimmt
und je nach Aufbau an den entsprechenden Port schickt..

Ich sehe, dass der ISA auf Port 80 ein HTTP-Connect an den Squid stellt..

Also bekommt der upstream-Proxy das nur auf die entsprechenden Ports
angeliefert wie es der ISA wiederrum bekam? ok, dann ich klar, warum es
nicht so funktioniert wie gewünscht :)

Danke!

--
mfg
Jens

"Jens Mander" <jemand[at]kickikacki.de> wrote in message
news:eGcn1SxgGHA.4404@xxxxxxxxxxxxxxxxxxxxxxx
ah, jetzt ja.
du schickst die internen requests via 8080 für alle protokolle (http,
https, ftp) an den isa.
der wiederum schickt die requests dann an den upstream-proxy wie in der
webverkettung eingestellt ist (in deinem fall 80).
es laufen also 3 protokolle (http, https, ftp) auf einem listener auf
(8080) und von dort aus (isa) gehts gesammelt weiter an deinen upstream
(80).
wenn du auf dem squid nachschaust, werden die nach extern gerichteten
https-requests gestellt oder in http "umgewandelt"?!
was wird auf deinen downstream-clients angezeigt, kommt der connect
zustande via ssl oder nicht?!
gruss, jens mander...


"Jens Weibler" <Jtb@xxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:uYZSnAxgGHA.5096@xxxxxxxxxxxxxxxxxxxxxxx
Hi,

Der Squid lauscht auf Port 21, 80 und 443..
Eingestellt bei der Webverkettung sind 80 und 443 :(

Wobei ich beim ISA garnicht weiß, wie ich FTP-Proxy-Anfragen an einen
Upstream-Proxy weiterleite..

--
mfg
Jens

"Jens Mander" <jemand[at]kickikacki.de> wrote in message
news:uWxG5nvgGHA.5096@xxxxxxxxxxxxxxxxxxxxxxx
komisch, komisch.
soweit ich weiss müsste der isa standardmässig die requests via 8080 an
den upstream weiterreichen.
es sei denn du hättest den port in der webverkettung geändert. auf
welchem port nimmt der squid denn entgegen??
gruss, jens mander...


"Jens Weibler" <Jtb@xxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:%23EBlbmpgGHA.2208@xxxxxxxxxxxxxxxxxxxxxxx
Hi Jens,

die Einstellungen für die Proxy-Rule sind:
Redirect
- HTTP request as HTTP request
- SSL request as SSL request

Also scheint hier alles richtig zu sein :(

--
mfg
Jens

"Jens Mander" <jemand[at]kickikacki.de> wrote in message
news:%23f1n5EngGHA.3588@xxxxxxxxxxxxxxxxxxxxxxx
schau dir mal deine webverkettungsregel an.
dort gibt es eine registerkarte "bridging".
standardmässig werden https-requests in http-requests "umgeleitet".
vielleicht ist dir damit geholfen?!
wenn du den ssl-port auf dem webproxy einstellst (eigenschaften des
netzes "intern", registerkarte "webproxy"), dann können interne
clients ihre webproxyrequests verschlüsselt zum isa schicken. aber
das chaining sollte meiner meinung nach nicht davon betroffen sein.
gruss, jens mander...


"Jens Weibler" <Jtb@xxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:OKl7$pmgGHA.764@xxxxxxxxxxxxxxxxxxxxxxx
Hi Jens,

gerade das habe ich eingerichtet. Aber eingehende Proxyanfragen
(CONNECT) landen auf Port 80 beim upstream-proxy..

Kann es sein, dass ich den Proxy auf einen SSL-Port ansprechen muss,
damit er es auch an den upstream Proxy als SSL weitergibt?

--
mfg
Jens

"Jens Mander" <jens.mander[at]kickikacki.de> wrote in message
news:OAUAoBYgGHA.1276@xxxxxxxxxxxxxxxxxxxxxxx
hast du eine webverkettung konfiguriert?? (isa-konsole \
konfiguration \ netzwerke \ webverkettung) um die requests zu
deinem upstream-proxy weiterzuleiten? falls ja, dann kanns du in
dieser jenen welchen den port angeben, über den die requests
weitergereicht werden sollen (standard: 8080 und 8443).
gruss, jens mander...



"Jens Weibler" <Jtb@xxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:%230Qu4s$eGHA.3468@xxxxxxxxxxxxxxxxxxxxxxx
Hallo,

ich habe meinen ISA2004-Server in der Single Network Adapter
Konfiguration und benutze einen Upstream Proxy (Squid). Da alle
Requests über Port 80 nochmal durch die Hardwarefirewall gefiltert
werden (was auch gut so ist), müssen SSL-Requests vom ISA über
Port 443 rausgehen. So dachte ich auch, dass ich es eingestellt
habe (Upstream Server SSL Port)

Wenn aber nun ein interner Client eine SSL-Seite öffnet, sendet
der ISA-Server den Request an den Upstream-Server auf Port 80 :(
Wieso macht er das? Und wie kann ich das ändern?

--
mfg
Jens



















.

Relevant Pages

  • Re: Web Chaining - Ausgehender Port für SSL
    ... dass der ISA auf Port 80 ein HTTP-Connect an den Squid stellt.. ... Also bekommt der upstream-Proxy das nur auf die entsprechenden Ports ... der wiederum schickt die requests dann an den upstream-proxy wie in der ...
    (microsoft.public.de.german.isaserver)
  • Re: Web Chaining - Ausgehender Port für SSL
    ... den isa, weil du ihre browserkonfigurationen angepasst hast. ... somit schickt dein isa die requests an den squid und bittet jenen ... auseinandernimmt und je nach Aufbau an den entsprechenden Port ... Also bekommt der upstream-Proxy das nur auf die entsprechenden Ports ...
    (microsoft.public.de.german.isaserver)
  • Re: Web Chaining - Ausgehender Port für SSL
    ... isa, weil du ihre browserkonfigurationen angepasst hast. ... somit schickt dein isa die requests an den squid und bittet jenen ... auseinandernimmt und je nach Aufbau an den entsprechenden Port schickt.. ... Also bekommt der upstream-Proxy das nur auf die entsprechenden Ports ...
    (microsoft.public.de.german.isaserver)
  • Re: Web Chaining - Ausgehender Port für SSL
    ... isa, weil du ihre browserkonfigurationen angepasst hast. ... somit schickt dein isa die requests an den squid und bittet jenen wiederum ... auseinandernimmt und je nach Aufbau an den entsprechenden Port schickt.. ... Also bekommt der upstream-Proxy das nur auf die entsprechenden Ports ...
    (microsoft.public.de.german.isaserver)
  • Re: Direct browser access to internal servers
    ... Jim Harrison (ISA SE) ... Web Proxy Client send the request to the ISA on port 8080,..not 80. ...
    (microsoft.public.isa.publishing)