Re: Web Chaining - Ausgehender Port für SSL

ja, das die Firewall immer aktiv ist, habe ich auch schon bemerkt.
Imho ein Manko vom ISAServer wenn man nur einen Proxy haben will.

Wie gesagt, ich habe eine Firewall zur Verfügung, die mir mehr als ein
ISAServer bietet.
Aber wir werden OT ;)

--
mfg
Jens

"Jens Mander" <jemand[at]kickikacki.de> wrote in message
news:eAkfYH8gGHA.3496@xxxxxxxxxxxxxxxxxxxxxxx
nur zur info: wenn der isa dual-homed wäre, dann hättes du auch ein
umfangreicheres proxy-regelwerk!
die "echte" firewall auf dem isa ist eh immer aktiv (auch im
unihomed-zustand).
gerngeschehen,
jens mander...



"Jens Weibler" <Jtb@xxxxxxxxxxxxxxxxx> schrieb im Newsbeitrag
news:eWLwCU2gGHA.3496@xxxxxxxxxxxxxxxxxxxxxxx
jaja, aber wir wollen den ISA nur als Proxy verwenden..
Für echtes Firewalling habe ich was anderes :)

Ich schau mal ob ich den Proxy auf SSL umstelle - nochmal danke für deine
Hilfe!

--
mfg
Jens

"Jens Mander" <jemand[at]kickikacki.de> wrote in message
news:ebGD37ygGHA.5064@xxxxxxxxxxxxxxxxxxxxxxx
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
    ... 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: 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 ... dass der ISA auf Port 80 ein HTTP-Connect an den Squid stellt.. ... 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)