IThome

Was haste denn gemacht, den Regkey gesetzt UND das Configuration Protocol deaktiviert ? naja, Hauptsache, dass das jetzt funktioniert ... :)

Wann hast Du diese Richtlinie denn gesetzt und für wen gilt sie ? Sie muss aktiv sein, BEVOR das serverseitige Profil das erste Mal zurück geschrieben wird. Nachträglich bringt sie nichts mehr. Weiterhin muss sie auf den Clients angewendet werden, nicht auf dem Server ...

Da bin ich ja mal gespannt :) Kann dann ja nur der Server sein, da die Tests ja durch die Bank mit sämtlichen Systemen (Clientseite) Fehler produziert haben ... Hm, 5 Minuten, ich habe auf den ARP-Cache gezielt, da sind 5 Minuten eigentlich zu viel ...

Hm, einen Jana würde ich eher nicht auf einem SBS installieren, nur auf einem separaten Rechner ...

Öhm ... ??? :confused: , mach das noch mal, also von 10.1.1.104 auf die 10.1.2.22 pingen. Warte dann mehr als 2 Minuten (lieber 4 oder 5) und pinge dann von 10.1.2.22 auf die 10.1.1.104. Klappt das auch ?

Ich krieg da schon noch eine Meldung vom Default Gateway (von XP ausgeführt). Ist die Ausgabe von TRACERT auf beiden Seiten prinzipiell gleich ? edit: schnickschnack, ist richtig, die erste Antwort ist die vom Default Gateway. Du kannst also auch die 10.1.1.7 auch nicht anpingen (welche Meldung kommt ?) ?

Man benötigt keine 3 Karten, ein Default Gateway setzt man auf der Karte des Servers, die mit dem Internetrouter verbunden ist. Der Internetrouter benötigt nur noch eine Rückroute in das ihm abgewandte Netz. Die Clients in dem Netz des Internetrouters sprechen den Server an, er soll in das unbekannte Netz (Internet) routen, was er über seine Defaultroute macht. Diese Clients bekommen ein ICMP-Redirect und wenden sich in Zukunft direkt an den Internetrouter. Die Clients in dem Netz ohne Internetrouter wenden sich ebenfalls an den Server und der routet weiter. Die Antwortpakete werden vom Internetrouter über den Server zurück in das Netz geleitet (deswegen die Route auf dem Internetrouter). Naja, der Internetverkehr ist die Kür, das LAN-Routing dagegen erstmal Pflicht ... ;)

Achso, von einem 2000 Client aus gepingt kommt also auch keine Antwort (2000 hat ja zumindest keine integrierte Firewall) ? Du pingst die IP-Adresse an oder den Namen ? Hm, noch mal überlegen ... Pingst Du von einem Client des einen Netzes einen aus dem anderen an, klappt das (was bedeutet, dass richtig geroutet wird und dass beide das richtige Gateway haben müssen). Machst Du das jetzt umgekehrt und zwar von dem Client aus, der vorher von dem anderen angepingt wurde und zu dem Client, der vorher gepingt hat, dann kommt keine Antwort (welche Meldung kommt ?). Es gibt ja nicht viele Möglichkeiten: der pingende Client kennt keine Route zum Ziel (kann nicht sein, er hat ja vorher geantwortet). Der angepingte Client kennt keine Rückroute (kann auch nicht sein, denn er hat vorher eine Antwort bekommen). Der Router macht NAT (würde das Verhalten erklären, hast Du aber ausgeschlossen). Es läuft eine Sicherheitssoftware auf dem angepingten Client, welche den Zugriff aus dem entfernten Netz verhindert (funktioniert die Pingerei innerhalb der Netze ?). Aber auch das hast Du verneint. Naja, ich würde mir mal ne XP-Maschine mit 2 Netzwerkkarten schnappen, "IpEnableRouter" konfigurieren und es mit diesem "Router" versuchen. Ebenfalls würde ich probieren, jeweils einen Rechner aus den betroffenen Netzen DIREKT an den Server anzuschliessen.

Er hat eine fest eingestellte Adresse (und die passt ja auch), das ist also nicht relevant ... Das mit IPv6 kann man natürlich mal probieren, allerdings würde mich das doch sehr wundern, wenn das die Ursache ist ...

Also sehr wahrscheinlich Clients in dem Netz, welches nicht antwortet. Poste mal von einem die VOLLSTÄNDIGE Ausgabe von IPCONFIG /ALL, ebenso die von einem aus dem anderen Netz, der antwortet ...

Das kann man in der RRAS-Konsole sehen, wo es dann einen Punk "NAT" gibt, was ich allerdings nicht glaube ...

Poste bitte mal die Ausgabe von ROUTE PRINT, nachdem Du nach einem Neustart die Route erneut eingetragen hast.

Hallo und herzlich willkommen, benutze die formularbasierte Authentifizierung ... How to manage Outlook Web Access features in Exchange Server 2003 Gruss Sven

Wie schon mal geschrieben ist der Router wahrscheinlich nicht das Problem (zumindest nicht, wenn NAT ausgeschaltet ist), die Routingtabelle und IPCONFIG jedenfalls sehen sauber aus. Hast Du den RRAS eigentlich schon mal deaktiviert und via Assistent (Benutzerdefinierte Konfiguration - LAN-Routing) erneut konfiguriert ?

Schön, dass es funktioniert und danke für die Rückmeldung ... :)

Man könnte eine statische Route für den GLS-Server einstellen, dafür das Default Gateway entfernen. Aber ganz ehrlich, wirklich sauber ist das nicht. Weiterhin könnte man auf dem SBS statische Paketfilter einrichten, was allerdings beim Betrieb eines NAT-Routers (das ist der SBS wahrscheinlich) nicht empfohlen wird ...

Stichwort SMB-Signierung (hast Du ja schon vermutet), benutze mal die Suche. Ich denke, da wirst Du schnell fündig ...

Mir fällt da nichts auf, was routingtechnisch den Zugriff verhindern könnte. Der Server kennt beide Netze, die Clients den Weg zum Router, der dann weiter verbindet. Wenn es in eine Richtung geht, MUSS der Router funktionieren, die Pakete werden ja auch über den Router zurück geschickt. Wenn die andere Richtung nicht funktioniert, kann da nur NAT im Spiel sein oder es sind Filter konfiguriert (Vista Desktop-Firewall, auf dem Router (unwahrscheinlich, wenn im Assistenten LAN-Routing gewählt wurde)) ...

Also keine Windows-Firewall oder ähnliches ? Welche Einträge sieht man in den Eigenschaften der Netzwerkkarten (neben den üblichen wie Internetprotokoll oder Client für Microsoft Netzwerke) der Clients in Netz 1 ? Sind da irgendwelche VPN-Clients installiert ? Kommt da überhaupt etwas an (sniffen) ? Ich würde als erstes auf allen Geräten die früher eventuell konfigurierten Routen entfernen. Danach "IpEnableRouter" wieder auf 0 setzen und den RRAS erneut konfigurieren (wenn nötig den RRAS vorher deaktivieren). Auf allen Clients die zugewandten Schnittstellen des Routers als Default Gateway in den Eigenschaften der Netzwerkkarten konfigurieren und dann noch mal mit einem PING <IP-Adresse> probieren ... Ich würde gerne mal die VOLLSTÄNDIGEN Ausgaben von IPCONFIG /ALL der verschiedenen Clients und des Servers und ebenso noch die Ausgabe von ROUTE PRINT des Servers sehen (nachdem die Änderungen vorgenommen wurden).

Hm, der Link funktioniert nicht ... Ich vermute den Fehler nicht auf dem Router, sondern auf den anzusprechenden Clients in Netz 1 ...

Hast Du was mit den Beschreibungen in dem von Dir geposteten Newsgroupbeitrag erreichen können ? Läuft auf dem zu erreichenden Rechner ein NVIDIA Driver Helper Service (oder so ähnlich) ? Wenn ja, beende ihn mal und versuche es erneut ?

Mit RUNAS sollte das auch klappen ...

Bitte auch mal ROUTE PRINT vom Server ... Mach das lieber mit dem RRAS, das ist besser konfigurierbar. Benutze im Assistenten einfach LAN-Routing und nichts weiter, dann routet das Ding schon. Bis wohin kommst Du aus Netz 2, bis zur gegenüberliegenden Schnittstelle des Routers ? Da läuft keine Firewall auf den Clients in Netz 1 ? Eventuell ein Cisco VPN-Client ? Oder diese NVidia Firewall, die es mal gab (Active Armor oder wie das Ding sich nennt) ?

Um simples Routing zwischen den beiden Netzen zu testen muss der Server erstmal gar kein Gateway haben (er ist ja direkt an beide Netze angeschlossen) und schon gar nicht seine eigene Schnittstellen. In Netz 1 haben die Clients die 10.1.1.7 als Default Gateway, in Netz 2 haben die Clients die 10.1.2.1 als Default Gateway. Es müssen erstmal nirgendwo irgendwelche Routen statisch gesetzt werden. Das muss erst passieren, wenn unbekannte Netze wie das Internet erreicht werden sollen. Ist der Router korrekt konfiguriert (also kein NAT in Deinem Fall), dann war´s das schon. Wie hast Du den Router eigentlich aktiviert ? RRAS oder durch Registry (IpEnableRouter) oder wie hast Du das gemacht ? Du kannst auch mal die Ausgabe von ROUTE PRINT eines Clients aus beiden Netzen und dem Server posten ...

Er hat ja keinen Proxyserver und will möglichst auch keinen ... ;)