asot00

Den Port habe ich manuell geändert, aber ich glaube wir sind auf dem Holzweg. das problem liegt woanders. Gerade eben habe im Dashbaord ->Protokolierung folgendes bemerkt. Die Verbidnung wir initiert, aber der interne Server kann Port 53 wegen (unbekanntenr Absender) an ISA nicht öffnen, da verweigerte Verbindung " Standardregel". Dass heißt ich müsste demnach noch eine Zugriffsregel auf ISA erstellen. Was meinst du?

Frage: hast du den RemotelyAnyWhere Port eigentlich umkonfiguriert? Nö, das Problem was ich habe ist ja allgemein und bezieht sich auch auf andere S.V.Regeln.

Ich bin mir ziemlich sicher, dass die Konfiguration seit Beginn stimmt. HIn und wieder hab ich zwar ind en TCP/IP settings rumgespielt um vielleicht das Problem zu finden, aber es hat nichts geholfen. Gibt es vielleicht etwas was ich übersehen habe? Wie gesagt, der SG(ISA) ist beim internen Server angegeben

Wie müsste denn die Konfig deiner Meinung nach aussehen?

Ich brauch doch den DNS auf der WAN Schnittstelle um aufs Internet zuzugreifen. Das der Client zwie DNS Einträge hat, ist nicht Standard, natürlcih reicht eine. Aber auch das löst mein Problem nicht. Wenn nichts geht, probiert man halt aus.

Deine Beschreibung müsste stimmen. Bei POPcon frag am besten den Hersteller. Popcon holt die Mails doch nur ab und dann kommt doch der Categorizer zum Einsatz. Also müssten die Filtereinstellungen doch funzen.

Die Namensauflösung wollte ich so lösen: FQDNs im internen DNS eingetragen z.b. CNAME Eintrag: exchange.local -> Server-IP webserver.local- >Server IP DNS Zugriffsregel von extern nach intern oder DNS Serververöffentlichung. Beides wollte irgendwie nicht funktionieren

Der veröffentliche Server hat als SG den ISA Server: Meine Konfig: SERVER01 (IP:192.168.50.1, SG:192.168.50.3, DNS:192.168.50.1) ISA LAN (IP:192.168.50.3, DNS:192.168.50.1) ISA WAN( IP:192.168.11.30, SG:192.168.11.1, DNS:192.168.11.1) Router (IP:192.168.11.1) CLIENT extern(IP:192.168.11.20, SG:192.168.11.30, DNS:192.168.11.1 und DNS:192.168.11.30)

TCP/IP versteh ich schon, nur die Konfig in der Firewall ist etwas verwirrend So hab das heute noch einmal alles getestet. Das Problem ist immer noch da. "Ursprung ist der Client" ist keine Kommunikation möglich. Außerdem kann ich alle Serververöffentlichungen nur über die IP ansprechen, über FQDN ist auch keine Kommunikation möglich.

Wie sieht es denn bei anonymen Benutzern aus, die auf meinen internen Webserver zugreifen. Die kennen die SG des ISA servers doch gar nicht.

Ich glaube jetzt habe ich es voll verstanden. Morgen geht es wieder richtig an die Arbeit mit dem ISA. Noch mal vielen Dank für die geschätzte Hilfe.

Bingo, jetzt klingelts bei mir. Also müsste ich z.B. Dyndns für den öffentlichen Namen verwenden. Muss ich bei der Konfig des Routers etwas beachten?

Ich muss doch zwangsläufig bei dem externen Client als SG die Router IP angeben, damit die Internetverbindung läuft.

Das mit dem OWA stimmt, nur habe ich das Problem das ich den zu veröffentlich Namen ja nicht auflösen kann, da sich der A-record Eintrag hinter dem ISA befindet.

Wenn ein Router dazwischen ist gilt das wohl nicht mehr, oder? Client (Internet) -> Router -> ISA01 P.S. Danke grizzly999 für deine schnelle, kompetente und hilfreiche Unterstützung. So komm ich meiner MS 70-350 näher.

Ach so verstehe, also muss ich nur das virtuelle Verzeichnis veröffentlichen. Was muss ich bei der Regel beachten? Das mit dem virtuellen Werzeichnis gilt analog auch für OWA?

Muss der ISA immer als Standardgateway konfiguriert sien, obwohl ein gleiches Subnetz ohne Router verwendet wird?

Wie müsste die Regel ungefähr aussehen? Reicht eine Port-Änderung im IIS-Admin?

Ich habe den Fehler gefunden!!! Eine Einstellung in der Regel hat die Verbindung zugelassen. Und zwar stand vorher: "Ursprung der Anforderungen scheint der ursprüngliche Client zu sein" eine Änderung auf "Ursprung der Anforderungen scheint der ISA-Computer zu sein" hat das problem gelöst. Was skurril ist, dass ich das bei jeder beliebigen Serveröffentlichung ändern muss, sonst bekommen ich keinen Zugriff warum????

Kann ich meine interne PKI, die ich auf dem Domänencontroller installiert habe über den ISA Server im Internet veröffentlichen? Für einige Konfigurationsszenarios brauche ich nämlich Zertifkate z. B bei VPN über L2TP mit Zertifikaten. Dann könnte ich mir nämlich über http:\\servername\certsrv Zertifiakte für externe Clients ausstellen. Eine Richtlinie die Port 80 auf dem ISA freigibt, müsste dann reichen oder?

Also den Unterschied zwischen den Regeln habe ich nun verstanden. Aber ich ahbe immer noch Probleme von Extern auf Intern zuzugreifen: Meine Konfig sieht so aus: Serververöffentlichung: VON (Beliebig) - NACH Intern(Serververöffentlichungs-IP 192.168.50.1) - Protokoll (RDP Terminaldienste Server) - Benutzer (Alle Benutzer) - Listener (Extern) So wenn ich vom meinen Client (192.168.11.20) auf die Externe Schnittstelle des ISA zugreife (192.168.11.30:3389) bekomme ich keine Verbindung. Im ISA Überwachungsprotokoll wird unter der Rubrik AKTION "Initiierte Verbindung" angezeigt, dann aber gar nichts mehr. Ich komme mit meinem Wissen einfach nicht mehr weiter

Also wenn ich es richtig verstanden habe, brauche ich keine 2 Internetverbindung um die Serververöffentlichungsregeln am ISA Server zu testen. Das die Konfig am CLIENT jeweils unterschiedlich ausfällt, war mir klar.

Also nochmal: Konfig 1: Ein Client versucht über das Internet auf den Router zuzugreifen und der Router übermittelt die Anforderung vom Client an den ISA Server (Extern) Konfig 2: Es besteht eine Cross-over Verbindung zum ISA Server, somit hat der Client ohne eine Internetverbidnung eine direkte Verbindung auf den ISA Server (Extern) Gibt es zwischen den beiden Konfigurationen einen Unterschied. Ich möchte nämlich Die Serververöffentlichungregeln auf dem ISA am besten ohne eine 2 Internetverbindung simulieren.

Tur mir Leid, es war keine Absicht.

Ja klingt logisch, ich werde das Ganze noch einmal geanu unter die Lupe nehmen