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

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

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