IThome

Wenn die Telefonanlage dieses Gateway hat, schickt sie Pakete dort hin. Der Rechnerrouter muss dann wissen, wohin damit. Er schickt es auch zu seinem Gateway, welches der VPN-Router ist. Dieser kennt dann das Netz in Standort B. Interessanter ist es von Standort B aus gesehen. Der VPN-Router dort muss Pakete in die Netze 192.168.1.0 und 192.168.2.0 durch den Tunnel lassen. Der VPN-Router in Standort A muss eine (statische) Route in das Netz 192.168.1.0 haben, da er nicht direkt angeschlossen ist und er auch schon ein Default Gateway hat (das des Internetproviders). Was ist das für ein VPN ? IPSEC ?

/updatenow ?

Auf dem DC ausführen, nachdem die Zonen erstellt wurden. Die Zonen sollten idealerweise AD-integriert sein und dynamische Updates zulassen ... NET STOP NETLOGON && NET START NETLOGON IPCONFIG /REGISTERDNS Der DC registriert alle relevanten Einträge neu (eventuell ein wenig warten). Dann erstellst Du noch einen Alias companyweb, der auf den Hostnamen des DCs verweist. Die Clients werden sich auch selbstständig neu registrieren ...

Die Tunneleinstellungen müssen so gemacht werden, dass alle entfernten Netze auch über die Tunnel zu erreichen sind. Anderenfalls würden die VPN-Router es über das Gateway des Internetproviders versuchen ...

PC in Standort B hat seinen Router als Default Gateway, dieser kennt die Route zu den beiden Netzen in Standort A über den Router in Standort A (erreichbar via VPN), der Router in Standort A hat eine Route zu dem Telefonanlagen-Netz erreichbar über den Rechner, der routet. Die Telefonanlage hat als Default Gateway den Routerrechner. Dieser wiederum hat als Default Gateway den VPN-Router, der den Weg zu Standort B kennt ...

Kannst Du die Zonen neu anlegen (AD-integriert) ?

Bei Nortel weiss ich das jetzt nicht, aber üblicherweise wird auf dem Gateway/Client IKE-Keepalive bzw. Dead Peer Detection benutzt ...

Event ID 2022 is logged, and your Windows 2000-based computer may stop responding

Hm, kommt mir auch komisch vor, wenn der Händler diese Version schon hundert mal verkauft hat :D Aber Spass beiseite, das hört sich wenigstens grenzwertig sein (vermeintlich selbst zusammengeklebt) , aber mal sehen, was unser Lizenzexperte dazu sagt ...

Benutze die erste, dann erzeugen die Benutzer die Berechtigungen so, dass auch Administratoren zugreifen können ...

Wenn die Benutzer die Profilordner selbst neu erstellen und dann mit dem lokal gespeicherten Profil füllen, muss VOR dem Erzeugen dieser Ordner eine Computerrichtlinie für die Rechner gültig sein, an denen sie sich anmelden ... Computerkonfiguration - Administrative Vorlagen - System - Benutzerprofile - "Sicherheitsgruppe "Administratoren" zu servergespeicherten Profilen hinzufügen" Erzeugen die Benutzer ihren Profilordner nicht neu, ist dieser also schon vorhanden und mit den entsprechenden NTFS-Berechtigungen angepasst worden, muss eine Computerrichtlinie gültig sein, die die Besitzprüfung abschaltet ... Computerkonfiguration - Administrative Vorlagen - System - Benutzerprofile - "Eigentümer von servergespeicherten Profilen nicht prüfen" Da Du aber die Benutzer neu erstellt hast, sich dessen SID also verändert hat, passen die Berechtigungen in der NTUSER.DAT (ich meine damit nicht die NTFS-Berechtigungen für die NTUSER.DAT) nicht mehr. Die Berechtigungen auf NTFS-Ebene alleine zu setzen, reicht also nicht aus. Die Benutzer können ja wahrscheinlich die alten, lokalen Profile auch nicht mehr nutzen, richtig ? Ich gehe mal davon aus, dass die Benutzer keine lokalen Administratoren sind ...

Was hat er alles gelöscht ? Alle Einträge in den Zonen oder die Zonen selbst ?

Schau mal hier ... http://support.microsoft.com/kb/321721/en-us

Mach doch mal RSOP.MSC auf dem Client. Aus welcher Richtlinie kommt denn diese Einstellung ? Wo hast Du die von Dir erstellte Richtlinie gelinkt ? Steht sie in der Priorität höher als eine schon vorhandene Richtlinie, die auch diese Einstellung vornimmt ?

Ich fühle mit Dir und wünsche den Tätern einen Getriebeschaden im Schneesturm mitten in der Pampa ...

Man hat den Titel ...

Auf dem Client ...

Passiert das auch mit installiertem UPHC ? http://www.microsoft.com/downloads/details.aspx?FamilyID=1B286E6D-8912-4E18-B570-42470E2F3582&displaylang=en

Sehe ich auch so ...

Naja, wenn ich bedenke, dass ich trotz langer Erfahrung 7 Monate (Selbststudium) dafür gebraucht habe ...

Jep ... :)

Bis wohin kommst Du ? Kannst Du die Dir zugewandte Schnittstelle der Firewall anpingen ? Kannst Du die abgewandte Schnittstelle der Firewall anpingen (falls beides nicht geht, erstelle eine Regel, die ICMP zulässt) ? Was ist das überhaupt für ne Firewall, ein 2003 Server mit ISA ? Was loggt die Firewall ? Der RRAS jedenfalls routet, so viel steht fest. Du kannst ja Geräte jenseits des RRAS erreichen. Der RRAS selbst kann ja auch auf einen Rechner hinter der Firewall zugreifen, dann sollte der Client es auch können (sofern der Firewall es durch eine Regel nicht verhindert) ....

Kannst Du ein Gerät im internen Bereich des RRAS erreichen ?

Also ... Der RRAS kommt dort hin, wo der VPN-Client hin soll (er kann ihn anpingen oder was auch immer). Der VPN-Client hat eine Adresse aus dem internen Bereich des RRAS. Der Client kommt aber nicht zu dem entfernten Rechner, zum RRAS aber schon ?!

In den Eigenschaften der VPN-Verbindung - Netzwerk - Eigenschaften Internetprotokoll - Erweitert - Allgemein. Verbinde Dich danach neu und poste IPCONFIG /ALL des Clients ...