Webproxy/Packet-Filter Problem

[xtragood 10]

Hi Leutz!

 

Ich sitz jetzt schon seit einer Woche an einem Problem, bei dem ich einfach nicht weiterkomme.

 

Das Problem betrifft die Einstellungen am ISA Server 2000 auf W2K Server. Auf msisafaq.de hab ich mich schon gründlich durchgelesen, auch vieles gefunden, aber das Problem daß ich jetzt habe lässt sich nicht lokalisieren...

 

Ich hab versucht, die Einstellungen des ISA-Servers im laufenden Betrieb auf einen in ner Testumgebung (AD, DNS, DHCP dort nicht verfügbar) zu übertragen.

 

Funktioniert eigentlich auch alles prima. Nur muß ich einen IP-Filter für Zugriff auf HTTP zusätzlich anlegen, den es in der Netzumgebung nicht gibt.

 

Ich denke, das liegt irgendwie am Webproxy, weiß es aber nicht genau...ich hab alle Einstellungen schon zig mal überprüft und es sind genau die gleichen...woran mag das liegen?

 

Weiß jemand ne Lösung?

[jvogler 10]

Kannst Du vielleicht noch etwas genauer beschrieben was der Packet-Filter bewirken soll, Quelle/Ziel, Art des Clients usw.

 

Jochen

[xtragood 10]

Ok, also...

 

Es geht jetzt nur um HTTP und Port 80...

 

 

Es ist konfiguriert:

 

- Site an Content Rule / Allow Rule (standart)

- Protocol Rule / Allow / HTTP

- IP Packet Filter / TCP, direction both, all local ports, remote port 80

 

Wobei ich den IP Filter nur auf dem Testsystem aktivieren musste... im coporate network gibt es diesen Filter nicht und der Zugriff auf HTTP funktioniert trotzdem...warum?

 

/edit

 

Unsere Clients funktionieren wohl über Webproxy-Client Methode und bekommen ihre Einstellungen über das Netzwerk geschickt. Die Einstellungen im ISA-Server hab ich aber ebenfalls 1:1 vom produktiven System übernommen...

[jvogler 10]

Greifst Du im Testsystem direkt am ISA auf´s Web zu ohne über den Webproxy zu gehen? Dann brauchst Du einen Packetfilter.

 

Packetfilter öffnen den gewünschten Port permanent. Man verwendet diese i.d.R. um Dienste auf dem ISA direkt zu veröffentlichen, bzw. in DMZ Szenarien.

 

Die Protokollregeln finden bei den Clients (Secure NAT/FW- u. Webproxy-Client) anwendung. Hier werden die jeweiligen Ports dynamisch geöffnet.

 

Ich hoffe das hilft Dir erst mal weiter.

 

Jochen

[xtragood 10]

Ok, das wusste ich schon.

 

Hab nochmal ein wenig rumgetestet und herausgefunden, daß wenn ich das packet filtering generell ausschalte und die protocol rule für DNS und HTTP aktiviert ist, der Zugriff über Webproxy ins Internet klappt...

 

Sobald ich packet filtering aber wieder einschalte (und das ist zwingend notwendig) es wieder nicht klappt.

 

Im produktiven System sind aber auch Paket Filter definiert und der Zugriff klappt trotzdem... also bin ich immer noch nicht weiter als bisher...

[jvogler 10]

Geht ein ping durch bzw. funzt die Namensauflösung?!

[xtragood 10]

Solange die Paket Filter ausgeschaltet sind, ja...

 

/edit

 

etwas genauer:

 

- Produktives System (Paket Filter an / ICMP outbound konfiguriert) funktioniert Ping nach draussen

- Testsystem (Paket Filter an / ICMP aoutbound konfigriert) funktioniert Ping ebenfalls nach draussen

[jvogler 10]

Noch mal zum Verständnis, die Verbindungstests führst Du am ISA direkt aus, oder?

 

Was hast Du für Packetfilter bisher erstellt?

 

Tu mir im Moment noch schwer weil ich Deine Konfig noch nicht so recht durchschaut habe.

 

Jochen

[xtragood 10]

Noch mehr Input:

 

- Server mit 3 Schnittstellen NIC's. 1 extern, 1 intern, 1 DMZ (noch nicht konfiguriert)

- ISA Server integratet mode

- Site and content rule: allow rule (standart)

- Protocol Rules: DNS Query, DNS Query Server, FTP, FTP download only, Gopher, HTTP, HTTPS, NNTP, NTP(UDP), SSH, POP3, SMTP, MSN Messenger, MMS, PNM, RTSP (wobei ja nur DNS und HTTP interassant wären)

- IP Packet Filter: DNS lookup allow, FTP inbound/outbound allow, H.323 block, ICMP (outbound, ping response, source quench, timeout, unreachable) allow, Netbios block

 

und das Testsystem hab ich versucht ebenso einzurichten...

 

PS: Kann sein, daß im Produktivsystem das eine oder andere nicht richtig konfiguiert ist, aber im Prinzip funktioniert alles. Ein Client kann ohne Verbindungseinstellungen sofort in Internet...

[jvogler 10]

Sobald du im produktivsystem beim client den proxyeintrag vornimmst und in der site/content rule allgemein erlaubst und auch im webabhörer keine authentifizierung verlangst, dann darf jeder Client gleich surfen.

Am Server selbst sollte das auch funktionieren, nicht aber wenn Du den Proxyeintrag raus nimmst.

 

Nochmal meine Frage, verwendest Du im Testsystem einen Client (=NT4/W2k/XP Pro Rechner) oder testest Du am ISA Server direkt?? Ohne Proxyeintrag wird das nämlich nicht funktionieren, dazu müsstest Du erst noch einen Packetfilter für Port 80 erstellen.

 

Jochen

[xtragood 10]

Original geschrieben von jvogler

Sobald du im produktivsystem beim client den proxyeintrag vornimmst und in der site/content rule allgemein erlaubst und auch im webabhörer keine authentifizierung verlangst, dann darf jeder Client gleich surfen.

 

Falsch...das ist im Testsystem so...im Produktivsystem funktioniert das ohne Proxyeintrag.

 

Am Server selbst sollte das auch funktionieren, nicht aber wenn Du den Proxyeintrag raus nimmst.

 

Richtig, damit wäre ich dann schonmal einen Schritt weiter.

 

Nochmal meine Frage, verwendest Du im Testsystem einen Client (=NT4/W2k/XP Pro Rechner) oder testest Du am ISA Server direkt?? Ohne Proxyeintrag wird das nämlich nicht funktionieren, dazu müsstest Du erst noch einen Packetfilter für Port 80 erstellen.

 

1 W2K Client mit Gatewayeintrag vom ISA-Server, der sich die Einstellungen genau wie im produktiven System vom ISA automatisch bei Zugriff ziehen soll (funktioniert nicht)

Trage ich dort den Proxy manuell ein funktioniert auch der Zugriff dort (ohne IP Filter Port 80)

 

Ich hoffe, langsam nähern wir uns dem Ziel... :D

[xtragood 10]

Ok...jetzt hab ich's doch noch selber geschafft!

 

Das Problem lag darin, daß die externen DNS-Server nicht beim Client eingetragen waren.

 

In der produktiven Umgebung ist es ja generell so, daß der interne DNS-Server an die externen weiterleitet, falls es den DNS-Eintrag dort nicht findet.

 

Da bei uns im Netz ja DHCP für die Ausbringung der DNS-Einstellungen verwendet wird, fehlten diese Einträge in meiner Testumgebung...

 

Schwierig, aber gelöst... :)

[jvogler 10]

Na also! :)