IThome

Da diese Box schon seit Jahren "End of Life" hat, der Thread 5 Jahre alt ist und wir keine Softwaretauschbörse betreiben, schliesse ich diesen Thread ... Vielen Dank für Dein Verständnis ...

Ein Zertifikat, ein Name, unterschiedliche Namensauflösung (je nachdem, von wo man kommt) ...

Du hast also ein Zertifikat mit Namen remote.xxx.net. Wenn Du von aussen kommst, gibst Du den Namen remote.xxx.net ein (ohne VPN, ist ja SSL), der Name wird von einem öffentlichen DNS-Server in Deine öffentliche IP aufgelöst und Dein Router leitet die Pakete an den internen Server. Legst Du jetzt intern eine Zone remote.xxx.net an und erzeugst dort einen Host ohne Namen (also 192.168.124.251) und greifst jetzt von intern auf remote.xxx.net zu, dann richtest Du diese Anfrage an Deinen internen DNS-Server. Dieser ist für diese Zone zuständig und liefert die 192.168.124.251 zurück. Dein Client verbindet sich also mit dem internen Server direkt. Wenn Du via VPN zugreifst, sollte der VPN-Client den DNS-Server intern benutzen (ansonsten funktioniert es nicht). Beim Verbindungsaufbau werden neben der IP-Adresse also auch DNS-Server Adresse/n zugewiesen. Der interne DNS-Server liefert für remote.xxx.net die interne IP und der Client verbindet sich. Du greifst also mit dem gleichen Namen intern wie extern auf Deinen Server zu (was glaube ich das ist, was Du möchtest).

Warum stellst Du das Zertifikat nicht auf das öffentliche Zertifikat "remote.xxx.net" aus und erzeugst Dir intern eine DNS-Zone mit dem Namen "remote.xxx.net", in der Du einen Host ohne Namen mit der internen IP-Adresse erzeugst ?

Warum ist der Exchange nicht aktuell ?

Für XP-Clients ... Assign the DNS Domain for a Network Adapter

Welche Exchangeversion und welcher Patchlevel ? Welche Outlookversion und welcher Patchlevel ?

Name des Servers, also z.B. \\faxserver

Wenn das auch am WE nicht klappt, dann poste die Ausgabe von IPCONFIG /ALL des Servers und eines Clients aus jedem Subnetz ...

Ja ja, was da alles krumm sein könnte ... Aber nach 3 Wochen Schweigen des TOs wird das Problem entweder erledigt oder nicht so wichtig sein :wink2:

Du wirst um ein Rejoining (erst Arbeitsgruppe, dann wieder Domäne) nicht herumkommen ...

... und wenn überhaupt Default Gateway, dann nur eins! auf einer! Karte und nicht die Adresse der jeweils anderen Karte. Wie der Kollege schon geschrieben hat, wird keine Route benötigt, da der Server den Weg in beide Netze kennt (er ist direkt mit beiden verbunden) ...

Da muss was in der Ereignisanzeige stehen. Ist das ein DC oder ein Member ? Zieht der noch Gruppenrichtlinien ?

Sind die Zeiten synchron ?

Was hast Du alles geändert ?

Gib noch mal bitte NSLOOKUP SERVER08DC.DOMAIN.COM. ein und poste das Ergebnis (nicht den abschliessenden Punkt hinter COM vergessen). DOMAIN.COM muss aufgelöst werden, da der Server authoritativ für diese Domäne ist. Und das unabhängig davon, ob die Domäne extern vorhanden ist oder nicht.

Heisst das, er bekommt/hat eine Adresse und kann trotzdem nicht zugreifen ?

Serverbasierte Profile ? Ordnerumleitungen mit Offline-Verfügbarkeit ?

Keine Ahnung, wie Dein Filezilla eingestellt und die Firewall darauf angepasst war. Im Logging der Firewall z.B. kannst Du sehen, wie die Verbindung aufgebaut wird bzw. was geblockt wird. Was genau wird denn von der Firewall nach innen geleitet ?

Falls vom Client aus mit aktivem FTP zugegriffen wird, verbindet der Client sich von einem TCP-Port >1024 (N) aus mit dem TCP-Port 21 des FTP-Servers. Der Client übermittelt dem Server PORT N+1. Der Server verbindet sich dann aktiv (daher der Begriff aktives FTP) von seinem Port TCP 20 mit N+1 des Clients. Verbindet sich der Client passive mit dem FTP-Server, verbindet er sich von N mit TCP 21 des Servers. Der Client öffnet einen weiteren Port N+1. Nach Verbindungsaufbau sendet der Client ein PASV Kommando zum FTP-Server. Der Server öffnet seinerseits einen Datenport >1024, übermittelt diesen Poirt dem Client, welcher sich dann mit seinem Datenport N+1 mit dem soeben übermittelten Serverdatenport verbindet. Beim passiven FTP werden also beide Verbindungen vom Client aus initiiert. Was Du in der Firewall frteigeben musst, hängt also davon ab, was für einen Modus der Client auswählt und welche dynamischen Ports der Server dann erzeugt. Wenn Du in Deiner Firewall einen Layer 7 Filter für FTP hast, wird er anhand der FTP-Kommanbdos "merken", was geöffnet werden muss ...

Anfang der Woche erst durchgeführt, keine Probleme ...

Naja, er müsste seinen Rechner erstmal in eine Arbeitsgruppe bringen, um ihn dann erneut der Domäne zufügen zu können. Alleine dafür benötigt er lokale Administratoren-Rechte. Du müsstest das Computerkonto seines Laptops aus dem AD löschen, damit der User mit dem Benutzerrecht "Hinzufügen von Arbeitsstationen zur Domäne" das Computerobjekt wieder anlegen kann (zurücksetzen reicht nicht aus). Aber um der Domäne beizutreten, benötigt der User auch lokale Admistrator-Rechte. Lange Rede, kurzer Sinn ... Deine Anforderung kann nicht erfüllt werden ...

Genau da musst Du es einstellen ... Computerkonfiguration -> Administrative Vorlagen -> Windows Komponenten -> Remotedesktopdienste -> Remotedesktopsitzungs-Host -> Verbindungen - "Remoteverbindungen für Benutzer mit Hilfe der Remotedesktopdienste zulassen" Diese Einstellung gilt für XP und grösser ...

Das Routergerät muss den ordnungsgemässen Umgang mit den VPN-Protokollen beherrschen. Im Falle von PPTP also nicht nur mit TCP 1723, sondern auch mit GRE (IP-Protokoll 47) oder im Falle von IPSec hinter NAT-Geräten, dass die Initialverbindung über UDP 500 hergestellt wird und dann auf UDP 4500 umschwenkt (ein NAT wurde erkannt). Grundsätzlich scheint Dein Gerät das zu beherrschen, wenigstens für einen Client, möglicherweise auch mit 2 Clients zu verschiedenen Endpunkten. Aber eben nicht mit 2 Clients zum selben Endpunkt ... Ein Site-to-Site kann man relativ einfach und kostengünstig mit Draytek-Routern z.B. realisieren ...

Möglicherweise meinst Du .PRF Dateien für Outlook ?!