skippa

Hi,

eine Software in der Richtung ist mir nicht bekannt - würde daher ein wenig mit Skripten in die Trickkiste greifen:

Minütlich ein Skript ausführen

- Prüfen beider Leitungen

- bei Fehler auf einer der Leitungen eingriff in die Routingtabelle und austauschen des Default-Gateways

Sollte somit auch ohne Reboot funktionieren.

Beste Grüße

Hi,

was für einen Switch setzt du denn ein?

Was sagt das Log vom Switch? Endgerät sauber authentifiziert?

Beste Grüße

Hi,

- IP-Konfiguration des zweiten Interfaces komplett entfernen

- IP-Adresse auf das erste Interface mit drauf legen (Secondary-IP)

- Routing prüfen

- TMG Listner prüfen, ggf. neu anlegen

- TMG durchstarten

.. müsste das Problem lösen..!?

Problem bei deiner beschriebenen Konstellation sind zwei Default-Gateways. Wenn du die IP als Secondary auf die erste Verbindung bindest, hast du nur ein definiertes Gateway und somit einen konsistenten Weg.

Beste Grüße

Hi,

kannst du in der Webveröffentlichungsregel nicht einfach "Jeder" als Benutzer hinzufügen?

Müsste auf "Authentifizierte Benutzer" stehen - und das erklärt dann auch die Anmeldung..

Beste Grüße

Hi,

hast du in der Webveröffentlichung für https auch einen Hostnamen eingegeben - oder sind dort jegliche Hostnamen erlaubt?

Beste Grüße

Hi Johannes,

ja, da gibt es Software-Lösungen. Habe gute Erfahrungen mit der Software von Protected-Networks, 8MAN, gemacht.

Beste Grüße

Hi,

wenn das Thema noch aktuell ist:

Der Client kann sich durch bestimmte Optionen selber schützen (Registry und Programmverzeichnis). Wenn hier der Schutz aktiviert ist, kann das Update mit autopcc.exe auch fehlschlagen.

Im Zweifel mal in das Log von TM schauen - da müsste der Grund aufgelistet sein.

Beste Grüße

Hallo.

 

Habe ich etwas überlesen? Wo steht den in der Frage des TO etwas von ISA?

 

LG Günther

hi!

sorry - verdammt. man sollte nicht so viel parallel machen :rolleyes:

EDIT:

wird dir denn wenn du den externen zugriff versuchst, auch das zertifikat vom owa angezeigt?

also stimmen aussteller, cn, etc. mit dem vom exchange überein - oder kann es auch ein zertifikat von deiner firewall sein?

mfg

hi,

was sagt denn das log vom isa?

für welche netzwerke ist der listner konfiguriert?

mfg

hi,

tippe auf dreiecksrouting ;-)

packet kommt vom inet über die fritzbox rein, geht auf den isa, vom isa auf den webserver und vom webserver wieder direkt auf die fritzbox - und hier ist das problem: das packet müsste über den isa zurück gehen...

mfg

Hi Thomas,

was genau ist deine Frage dazu? ;-)

Grüße,

Simon

Hi,

versuch folgendes:

Auf dem entfernten Client gehst du in die Eingabeaufforderung und gibst dort den Befehl "nslookup" ohne Parameter ein. Du bist jetzt im nslookup, dort gibst du den Befehl "server [server-ip]" ein.. Also in deinem Fall "server 192.168.0.1", abschließend mit Return. Jetzt gibst du die Domäne ein, welcher du beitreten möchtest z.B. "tasknet.intern" oder so - kriegst du nun die IP-Adressen deiner DCs zurück?

Greetz,

Simon

Auf DC2 funktioniert ping Richtung IP-Adresse von DC1 NICHT.

Da Standardgateway 192.168.210.68 ist vom DC2 aus anpingbar

Hi,

wenn du die 192.168.210.68 pingen kannst, was funktioniert dann nicht?

Gruß,

Simon

Hi,

wüsste nicht was dagegen spricht. Subnetz im AD eintragen und tschakka!

Der Paket-Filter auf dem Router wird (kenne ihn nicht, aber gehe davon mal aus) nur in Richtung Internet gehen; vermute die Filterung von Protokollen, etc. wird nicht im VPN greifen.

Gruß,

Simon

Hi,

wenn ich das richtig interpretiere ist kein NAT konfiguriert?!

Wie hast du den Routing & RAS konfiguriert? Mit dem Wizard oder von Hand?

Gruß,

Simon

Hi,

siehst du irgendwas im Log vom IIS wenn du per https auf den Webserver zugreifen möchtest? Wenn dir die Webseite das Zertifikat entsprechend anzeigt, sollte das soweit OK sein.

Gruß,

Simon

Hi,

oder um es uns mal ein wenig einfacher zu machen, geh mal in eine Eingabeaufforderung und poste und den Output von den folgenden Befehlen

"netsh routing dump",

"netsh firewall dump".

Gruß,

Simon

Hi,

du brauchst dann natürlich auch noch zusätzliche Client-Zertifikate - die würd ich dann aber aus Kostengründen von deiner eigenen CA ausstellen lassen ;-)

Gruß,

Simon

Hi,

klar ist das möglich:

Eigenschaften von Webseite -> Verzeichnisssicherheit -> Sichere Kommunikation Bearbeiten -> Sicheren Kanal voraussetzen (SSL) und Clientzertifikate voraussetzen

müsste als Basiseigenschaft reichen ;-)

Gruß,

Simon

Hi,

du sprichst immer wieder von einem CA Zertifikat. Das ist das Zertifizierungsstellen Zertifikat und nicht das für deinen Webserver. Mithilfe des CA Zertifikats und einer Zertifizierungsstelle kannst du aber ein Zertifikat für deinen Webserver ausstellen.

Nachdem du den Request bei einer Zertifizierungsstelle eingereicht hast, bekommst du einen Public-Teil zurück, der mit dem Private-Teil der Anforderung eingespielt werden muss.

Sollte im Zertifikat ein anderer Name vergeben sein, siehst du eine Fehlermeldung - Zugriff ist aber weiter möglich.

Wenn du den Haken "Sicherne Kanal voraussetzen (SSL) Aktivieren" herausnimmst und einfach manuell die https://<IP vom Webserver>/ aufrufst, was passiert da genau?

Gruß,

Simon

Hi,

versuch dann mal auf dem Router ne Route für dein internes Netz hinzuzufügen - schon sollten die Verbindungen klappen (- sofern es wirklich das NAT-Problem ist, welches ich vermute). Andernfalls wissen wir, dass es nicht am NAT liegt ;-)

Gruß,

Simon

Ja ping geht durch. Komme ja vom Server aus auch ins Inet.

geht auch ein ping vom client?

gruß,

simon

Hi,

okay, verstehe. Habe mir den Topic noch einmal durchgelesen und weiß was du erreichen möchtest. Leider verstehe ich denn Sinn nicht ganz - wenn die Clients in der Domäne (auch wenn nur DNS-Domäne) intra.test.de liegen sollen, würde ich dafür eine Subdomäne schaffen und nicht nur im DNS den Namen entsprechend anpassen.

Wenn die Option im DHCP nichts bringt, befürchte ich des du die Clients anfassen musst.

Gruß,

Simon

Hi,

die IPSec-Kommunikation wird dann ja sicher über eine Gruppenrichtlinie gesteuert. Wenn du nun deinen Domänencontroller zwingst immer IPSec zu sprechen, können neue Domänenmitglieder keine Policy ziehen - da sie ja noch nciht wissen, dass IPSec mit dem und dem Zertifikat gemacht werden soll.

Vermute es geht mal in die Richtung.

Gruß,

Simon

Hi,

DNS-Server auf dem 2008er installiert? Mal n Trace auf ne IP im Netz gemacht?

Ich würde das Default-Gateway auf der LAN-Seite entfernen - es kann es nur eins geben.

EDIT:

Kannst du die IP-Adresse vom Router anpingen? Wenn nicht, würde ich auf Probleme mit dem NAT tippen.

Gruß,

Simon