pichocki

Das stimmt leider nicht, denn genau deshalb bin ich ja drauf gekommen: Einer unserer Server WAR "falsch" autorisiert, denn ich hatte das im Server selbst angeklickt, ihn sich also selbst autorisieren lassen, hatte dabei jedoch leider nicht beachtet,dass der Server zwei Netzwerkkarten (je eine auf dem Subnetz 1 und eine auf dem Subnetz 0 hatte) seltsamerweise wurde er nur mit einer Adresse, der 1er Adresse, autorisiert Später haben wir die 1er-Karte deaktiviert, aber der DHCP-Server blieb "autorisiert", und er verteilte munter seine Adressen auf dem 0er-Subnetz Wie konnte das sein? Jedenfalls war es so :-( Ich weiß nicht, ob es dadurch Probleme gab, Fehlermeldungen gab es jedenfalls keine :-o

Auf alle Fälle hielte ich es für sehr sinnvoll, wenn bei der Eintragung überprüft würde, ob der angegebene Server, zumindest aber seine IP, tatsächlich existiert. Andernfalls habe ich durch einen Tippfehler vielleicht eine "DHCP-Leiche", bzw. ist der von mir gemeinte Server gar nicht wirklich autorisiert...

Ich hatte soeben das in http://www.mcseboard.de/topic/173734-dhcp-server-konsole-autorisierte-dhcp-server-falsche-ip-adresse/ beschriebene Problem und konnte es nun "lösen". (Ich wollte dort antworten, aber das Forum schlug mir vor, einen neuen Thread zu erstellen.) Was war das Problem? In der DHCP-Verwaltung unserer Domäne standen als "Autorisierte Server" manche Rechnernamen doppelt, obwohl sie nur eine IP haben, und noch dazu waren diese IPs teilweise falsch. Woran lag es? Das "Autorisieren" eines Servers prüft offenbar NICHT, ob der Rechner tatsächlich existiert, noch ob seine IP korrekt ist :-( Ich habe es gerade ausprobiert und einen neuen Server "Gipsnich" mit einer IP auf einem ganz anderen Subnetz "autorisiert" - und das "klappt" ganz vorzüglich (siehe Bild)! Die "Lösung" bestand also darin, die "falschen" Server zu ent-autorisieren und sie dann mit korrekten Daten erneut zu autorisieren. ... aber welche Auswirkung hat die Autorisierung überhaupt, wenn die genannten Server nicht einmal existieren müssen? <kopfschüttel>

Na, wie denn? Zumindes MIR gelingt es für nicht indizierte DFS-Shares NICHT, weder per URL noch per Laufwerksbuchstabe. ... und dass wir hier über Netzwerklaufwerke/-ordner reden, steht doch oben... Aber sehr gern lasse ich mir sagen, was ich falsch mache.

Ja, nee, oder? Das ist doch jetzt aber nicht wahr? Seit 2009 findet man Beiträge, in denen dieses Problem beschrieben wird, und selbst auf dem 2012R2 gibt es dafür noch keine Lösung? Das ist ja vollkommen armselig :( Das Problem ist ja nicht nur der fehlende Index (denn die Suche geht ja), aber ein nicht indiziertes Laufwerk kann ich auch nicht in eine Bibliothek auf dem Client aufnehmen.

Hi, Daniel. Danke für den Tipp, und: Ja, das wäre eventuell eine Möglichkeit, zumindest was das RRAS angeht. Aber das Problem, das ich dabei sehe, ist die Tatsache, dass das RRAS nicht mehr "allein steht", sobald es mit dem TMG zusammen arbeiten muss. Der merkt sich ja alle Einstellungen in seiner "Konfiguration", und sobald ich "von außen", also direkt in der RRAS-Konsole, eine Änderung vornehme, macht der TMG diese rückgängig nach dem Motto: "Nur ICH habe hier noch das Sagen"... also ist alles, was nicht im TMG einzustellen ist, nun gar nicht mehr einzustellen. Oder siehst Du das anders?

Wir haben ein ähnliches Problem und finden bisher keine zufriedenstellende Lösung: Wir haben zwei Standorte mit drei VPN-Tunneln verbunden. Der eine ist "ständig" online, der andere erduldet täglich die Telekom-Zwangstrennung. Da wir L2TP verwenden, darf an keinem der Standorte der TMG über NAT erreichbar sein, d.h. er muss "direkt im Internet" hängen. Das haben wir sichergestellt, denn beide TMGs gehen über ein DSL-Modem direkt ins Netz. Von Zeit zu Zeit bricht mindestens einer dieser Tunnel zusammen (vermutlich alle drei bei Zwangstrennung), und dann kann mindestens einer davon nicht wieder aufgebaut werden. Es SCHEINT so, als versuche die Seite, die nicht getrennt wurde ("Standleitung"), sofort die Verbindung wieder herzustellen. Das klappt aber nicht, da sich die zwangsgetrennte Seite ja zunächst wieder "einwählen" muss. Hierbei scheint sie sich aufzuhängen: Sie steckt fest in der "Verbindungsherstellung"; wenn man "Trennen" und danach "Verbinden" wählt, klappt das in aller Regel. Ist es tatsächlich denkbar, dass das "Routing & RAS" das nicht von allein macht? Gibt es da einen "Deadlock". Das fände ich allerdings sehr peinlich für Microsoft... und ärgerlich für uns Anwender! Aber viel wichtiger: Was kann man dagegen tun? Es gibt ja nur die EInstellung "Wählen bei Bedarf"; ich kann nicht einmal "Persistente Verbindung" auswählen, weil der TMG dies sofort zurückstellt. Und eine Einstellung für eine regelmäßige Trennung (wie es die Fritzbox bot), um der Zwangstrennung zuvorzukommen, kennt der TMG auch nicht... Weiß jemand Rat? Dann schon jetzt ein dickes Danke!

Wir haben eine "automatische" Trennung einer VPN-Verbindung, wie ich gleich erläutere. Wir können "damit" leben", aber ich wüsste gern, warum sich Windows wie beschrieben verhält: Von Rechner A wird aus der Ferne eine VPN-Verbindung ins heimische Netzwerk hergestellt. Dessen IP im lokalen Netz ist bekannt. Wenn ich mich dann an Rechner A anmelde, egal ob lokal oder über seine VPN-IP, dann wird die VPN-Verbindung getrennt. Das Ereignisprotokoll zeigt keine Fehler, sondern nur die Trennung als (erfolgreiches) Ereignis. Dieses Verhalten ist unabhängig von den Credentials der VPN-Verbindung, sondern hängt nur am "Besitzer" der VPN-Verbindung. Es passiert ausschließlich, wenn sich ein anderer User anmeldet, als der, der die VPN-Verbindung hergestellt hat. Wenn ich mich mit den Daten des "VPN-Verbindungs-Besitzers" anmelde, klappt die Verbindung und bleibt bestehen. Wenn ein anderer User aber angemeldet ist, bevor die VPN-Verbindung hergestellt wird, dann ändert sich nichts! Ist dieses Verhalten "by design"? Oder habe ich einen Planungsfehler? Wenn die Trennung "aus Sicherheitsgründen" passiert, dann müsste doch konsequenterweise in Fall (6) ebenfalls der angemeldete Benutzer abgemeldet werden oder die VPN-Verbindung fehlschlagen. Passiert aber nicht. Ich bin über jede Erhellung dankbar. Danke.

Ich bin mir nicht sicher, was ich wie routen muss, um mein Ziel zu erreichen - und frage deshalb um Rat. Danke dafür! Die Lage: Ein entfernt stehender Rechner hat zwei Netzwerkkarten. Eine NIC 192.168.2.99 hängt im entfernten LAN und nutzt dort einen TMG auf 192.168.2.14 als Gateway. Seine zweite NIC hängt über eine Fritzbox 10.0.0.1 im Internet. Über diese zweite NIC wird ein VPN-Tunnel aufgebaut und erhält die 192.168.0.99. Am anderen Ende der 192.168.0.99. hängt ein anderes LAN mit TMG, der einen VPN-Client nicht "wieder raus" lässt - also habe ich das Häkchen "Standardgateway..." in den TCP/IP-Einstellungen des VPN-Adapters herausgenommen. Bis hier klappt alles prima. Die Karte an der Fritzbox soll aber möglichst ausschließlich für die VPN-Verbindung "nach Hause" verwendet werden - sonst für nichts. Ich möchte (und das klappt auch) über den VPN-Tunnel zurück eine RDP-Sitzung auf dem entfernten Rechner öffnen können. Jetzt meine konkreten Fragen: Wie sorge ich dafür, dass der entfernte Rechner die NIC am Fritz möglichst nur für den VPN-Tunnel nutzt? Zumindest sollte ein Webzugriff möglichst nur über den entfernten TMG gegen. Hierzu habe ich eine statische Route eingetragen: route -p add 0.0.0.0 mask 0.0.0.0 192.168.2.14 metric 1 if <NIC am LAN> route -p add 0.0.0.0 mask 0.0.0.0 10.0.0.1 metric 9 if <NIC am FRITZ> Hiermit sollte doch zumindest der Weg über den entfernten TMG bevorzugt sein, oder? Wenn ich die zweite Route weglasse, dann klappt auch mein RASDIAL NACHHAUSE nicht mehr, oder? Kann ich da etwas tun? Kann ich dafür sorgen, dass die NIC am FRITZ wirklich NUR für den VPN-Tunnel nutzbar ist? Alternativ bzw. zusätzlich: Wie stelle ich die Windows-Firewall ein, so dass über die NIC am FRITZ nur ZWEI Dinge möglich sind: VPN ausgehend und RDP eingehend? Danke für jeden Tipp!

GELÖST - aber warum? Danke, Sunny, für die Tipps, aber leider haben sie nicht geholfen. Ich konnte das Problem nun selbst lösen, allerdings ist mir schleierhaft, wieso der Fehler auftrat - vielleicht hat ja jemand eine Erklärung: An meiner Konstruktion sind DREI User beteiligt: Das Konto, in dessen Kontext die Aufgabe RASDIAL ausgeführt wird (der Autor der Aufgabe ist irrelevant). Das Konto, mit dem RASDIAL den VPN-Tunnel zu meinem LAN aufbaut. Das Konto, mit dem ich mich auf dem per VPN verbundenen Rechner remote anmelde. Es hat sich jetzt gezeigt, dass es völlig irrelevant ist, mit welchem Konto der VPN-Tunnel aufgebaut wird. Aber umgekehrt MUSS das Konto, mit dem ich mich per RDP anmelde IDENTISCH sein mit demjenigen, in dessen Kontext die RASDIAL-Aufgabe läuft. Wenn ich mich mit einem anderen Konto anmelde, dann wird mit Abschluss der Anmeldung die VPN-Verbindung getrennt. Es SCHEINT so, als würde mit Abschluss der Anmeldung der Prozess, der einem anderen User gehört, getötet - obwohl die Aufgabe "ohne Benutzeranmeldung" laufen soll und das auch tut. Hat jemand eine Erklärung dafür? Ist das "by design"? Gäbe es andernfalls Sicherheitsprobleme? Nachtrag: Das Problem hat NICHTS zu tun mit meiner VPN-Konstruktion. Es scheint GRUNDSÄTZLICH so, als würde eine Aufgabe, die im Kontext eines anderen Benutzers mit der Einstellung "Ohne Benutzeranmeldung starten" angelegt wurde, beendet, sobald sich ein (anderer) Benutzer anmeldet. Kann das jemand bestätigen? Danke für Erhellungen, Gruß, Pi.

Hi. Ich habe einen Rechner, der an einer Einwahlverbindung hängt, der also bei jedem Start eine neue IP bekommt. Trotzdem möchte ich auf diesen Rechner von fern zugreifen. Ich habe deshalb eine Aufgabe für RASDIAL erstellt, und der Rechner stellt eine VPN-Verbindung zu meinem Netz her - ist damit also "quasi in meinem lokalen Netz". Seine lokale IP kenne ich und will dann per MSTSC eine RD-Verbindung zu ihm öffnen. Das klappt auch - aber nur fast, denn während der Anmeldung trennt der Remoterechner, die VPN-Verbindung, und er tut dies mit einem Error 56 von TermDD. Ich bin recht sicher, dass die ersten Versuche mit dieser Konstruktion funktioniert haben (damals hing der Rechner sogar an einem Tchibo-Stick...), aber jetzt bekomme ich diese Abbrüche. Mache ich etwas falsch? Nochmal in Kurzform: - Entfernter Rechner an Einwahlverbindung öffnet einseitigen VPN-Tunnel zu mir. - Ich öffne RD-Sitzung zu diesem Rechner. - Verbindungsabbruch mit TermDD-Error 56. Danke für Tips hierzu! Gruß, Pi.

Die hat nix mit dem VPN zu tun - ist aber der Grund dafür, dass ich dort den RDS-Server (mit unserer Online-Software) betreiben möchte. Und ein "einfacher VPN-Router" wird wohl das ganze Konstrukt aus RDS-Gateway-mit-Drumherum kaum hinreichend unterstützen (zumindest unserer Erfahrung nach, oder kennst Du ein entsprechendes bezahlbares Produkt?).

Guten Morgen - und danke bis hier. Auf Plattmachenundneuaufsetzen läuft es wohl hinaus, aber DANACH kann odrr sollte ich den TMG doch in die Domäne aufnehmen, oder? Ein einfacher VPN-Router tuts leider nicht, denn wegen der in der Außenstelle deutlich besseren Netzanbindung (DSL 100/100 in Schweden) soll unser RDS-Server dort stehen...

Hi, Norbert. Ja, das Problem sehe ich auch so wie Du. Aber wie ist es zu lösen? Den TMG neu aufsetzen? Und in welcher Reihenfolge dann hochstufen? Zuerst den Standalone-TMG den Tunnel aufbauen lassen (sein Host darf ja wohl Domänenmitglied sein, oder?), dannden anderen Rechner zum DC hochstufen und am Ende den TMG in die Domäne nehmen (geht das überhaupt nachträglich?) Oder wie ist eine sinnvoll Vorgehensweise? (Die Vorstellung ist, dass ein Mitarbeiter am anderen Ende der Welt die Dependance einrichtet...)

Hi. Wir haben ein Problem, an dem wir nun schon "etwas länger" herumwerkeln, und ich wäre über einen Tipp recht erfreut: Wir möchten eine Zweigstelle per VPN-Tunnel anbinden und die entsprechende Infrastruktur zuerst hier bei uns testen. Im "Hauptsitz" haben wir eine Domäne (im w2k8-Modus) und gehen über einen TMG-2010 und eine Fritzbox ins Netz. Nun haben wir einen weiteren TMG aufgesetzt, allerdings hat der während seiner Installation Domänenzugriff gehabt. Nun betreiben wir ihn "separat". Zur Simulation haben wir ihn an den Switch der Fritzbox angeschlossen, so dass beide TMGs sich an der "Außen-NIC" sehen können (natürlich haben diese dafür eigene IPs auf dem Subnetz der Fritzbox. Der VPN-Tunnel wird aufgebaut und steht, und von der "Hauptstelle" kann ich auch in die Dependance zugreifen, z.B. mit PING und sogar mit MSTSC. In die umgekehrte Richtung klappt es NICHT - nicht einmal PING. Der TMG der Außenstelle blockt diesen Verkehr. Das seltsame ist, dass es eine entsprechende Regel gibt, allen Verkehr von seinem internen Netz ins Netz der Hauptstelle zuzulassen - allerdings wird diese Regel nicht angewendet, stattdessen blockiert die Defaultregel alles. Wenn ich mir den TMG der Außenstelle ansehe, dann hat dieser ein Problem beim "Konfigurationsspeicherzugriff". Was ist das, und wie kann ich das beheben? Ist es tatsächlich denkbar, dass der TMG andere Regeln abarbeitet, als er in seiner GUI anzeigt - einfach, weil er diese Regeln nicht "speichern" kann? In der Außenstelle gibt es keinen DC, sondern nur einen Server - den ich gern zum DC hochstufen will. Aber ich denke, es ist sinnvoll, das DCPROMO "durch den Tunnel" zu machen, oder? Es SCHEINT mir so, als suche der Außenstellen TMG einen DC, den er während seiner Installation hatte, und zu dem er nun, nachdem er in die Außenstelle gebracht wurde, zunächst nicht sehen kann. Was machen wir denn bloß falsch? Oder andersherum: Gibt es eine "Best Practice" für das Aufsetzen einer "Außenstelle mit TMG und DC"? Welche Server in welcher Reihenfolge? (Es kann ja wohl kaum notwendig sein, alles in der Hauptstelle mit direktem Zugriff aufs Lan zu konfigurieren und dann die Rechner zu verschiffen... das muss doch auch "remote" gehen, oder? Für jeden Tipp dankbare Grüße, Ralf Pichocki.