Replikation 2 DCs 2 Subnetze gestört

[Velius 10]

 

am dynamischen Zuordnen knusper ich noch ein wenig rum, die feste zuordnung einzelner ports funktioniert schon einmal, die empfehlung ueber VPN zu tunneln find ich sehr ernuechternd.

ehrlich gesagt so wahnsinnig ungewöhnlich finde ich das ganze Konstrukt (Firewall zwischen Internem Netz und Perimeternetz) nun auch nicht, ich quäl mich mal weiter durch die recht umfangreiche Doku für die ich mich nochmals bedanken möchte.

 

Ist es auch nicht, auch ohne fixe Port Zuweisung - aber ehrlich gesgat ist es schwierig dir so in einem Board zu helfen wenn da noch Polemik hinzukommt.:wink2:

 

 

 

hätte nur noch die Frage ob ich korrekt verstanden habe das sich nur fest vergebne Ports ueber die Firewall erreichen lassen und ob es notwendig ist die Server im ISA zu publishen?

 

Publishen in diesem Szenario schon gar nicht und auch dynamische Ports, ob mit ISA oder ohne, sind machbar.

[Jim di Griz 13]

Polemik gegen eine Maschine, nicht gegen Personen, wer sich den schuh anziehen will nur zu

 

die einfache Antwort: muss ueber IP-Sec "getunnelt" werden haette mir viel Zeit gespart.

 

Und Polemik ist durchaus angebracht wenn sich die Dinge verhalten wie bei RPC und wenn sich ISA verhaelt wie es sich verhaelt.

NUr 2 Anmerkungen: mit SP1 WIndows server 2003 wurde der RPC-Stack geändert, danach war kein "firewallen" von RPC-Verbindungen mehr möglich.

Laut meinem BPA zum isa soll ich wegen:

"To allow non-strict RPC traffic, expand the Firewall Policy node, right-click the rule Allow Private Subnet Traffic to DCs, click Configure RPC protocol, and clear the Enforce strict RPC compliance check box"

würde ich auch gerne tun, leider ist da kein Auswahlfeld (auch nicht nach reboot des ISA und Neuerstellen der Regel.... (weil der Haken schon in den Systemregeln entfernt wurde?)

 

das alles kostet sinnlos zeit und ist keineswegs angenehm, ein wenig fluchen durchaus angebracht.

 

und zum Problem: unter allen Dokumenten war eines dem ich gefolgt bin, Einrichten einer IP-Sec Verbindung um RPC-Regeln auf der Firewall zu umgehen.

 

Notwendig ist hier dann entweder eine CA oder eine Verschlüsselung per Scheinzertifikat die jeder lesen kann.

 

Also aktuell repliziert alles. Das naechste Abenteuer ist aber schon in Sicht, alle Rechner der Domäne bekommen inzwischen zertifikate die ich beglaubigen muss, nur der ISA-Server fragt nicht............

[Velius 10]

Die Checkbox kenne ich sogar, und die existiert auch wirklich. Welches SP fährst du denn beim ISA2004:suspect::wink2:

 

Das sich was RPC Call änderte seit SP1 war mir auch klar. Einige andere Firewall Produkte hatten auch ihre Mühe, vor allem damit, dass Windows Server seit SP1 zwei GUIDs, bzw. zwei Calls auf einmal anfragen/durchführen kann.

 

 

 

By the way: IPsec zwischen den DC ist wie erwähnt nur eine Lösung. Da du ja das Problem mit dem ISA isoliert hast, versuch's doch zu lösen (z.B. aktuellstes SP einspielen welches den veränderten RPC-Call versteht??).

[Jim di Griz 13]

Der ISA Server ist ISA 2006.

 

Microsoft ISA Server 2006

© 2006 Microsoft Corporation.

Version: 5.0.5721.240

 

Ich bin jetzt mehrere lange Tage dabei ein paar Protokolle zu erstellen/zu testen.

 

Dazu folgendes:

 

das mitgelieferte RPC-Protokoll (all interfaces) hat keine secondary connections definiert.

erstelle ich ein RPC-Protokoll mit secondary connections wird mal das eine mal das andere erkannt wenn ich beide verwende.

Wenn ich nur zum Testen einen RPC-Server (also einen DC) publishe erkennt ISA ohne Probleme die RPC-UIDs der Server, warum kann er denn dann nicht sauber routen?

Aber beide verhalten sich wie das Ventrilo-Protokoll das ich auch noch fertigmachen muss:

egal welche Settings ich für secondary connections verwende: ISA 2006 erkennt die secondaries zu 99% als unidentified traffic, auch nach reboot um die bestehenden connections zu resetten.

 

Alle Rechner sind MS-updated bis nichts mehr geht und haben soweit weisse eventlogs. Auf dem ISA ist nur der ISA, keine Fremdsoftware. auf dem "virtuellen PDC" ist auch nichts drauf.

DIe CDs zur Installation sind Action Pack-CDs mit gültigen Serials

 

So wie es momentan aussieht bekommt der ISA-Server kein Zertifikat weil er feststellt, das beim Abarbeiten des AD-Zertifikatsrequests keine RPC-Endpoints vorhanden sind, damit schlägt dann die GPO-Verarbeitung fehl. Der ISA-Server bekommt ja auch keine IP-Sec Verbindungsparameter bisher, soweit also erstmal alles zummindest irgendwie stimmig.

 

hm, nachdem die DCs sich prächtig miteinander verstehen werd ich wohl den ISA nochmal neu machen müssen, mal sehen obs hilft.....

 

snipp on

By the way: IPsec zwischen den DC ist wie erwähnt nur eine Lösung. Da du ja das Problem mit dem ISA isoliert hast, versuch's doch zu lösen (z.B. aktuellstes SP einspielen welches den veränderten RPC-Call versteht??).

snipp off

 

ALLE Maschinen hier sind updated to the max, also alles was ueber MS-Update kommt und ALLE sind installiert von Original-CDs.

ich suche schon eine weile zum thema, welcher patch oder hotfix fehlt denn hier? und warum ist sowas essentielles nicht ueber MS-Update erhaeltlich?

[Velius 10]

Kuck mal hier: http://www.microsoft.com/communities/newsgroups/en-us/default.aspx?dg=microsoft.public.isaserver&tid=abc373d3-9bef-4d5f-abb3-663155bcd669&p=1

 

Try to following registry changes. We were having the same problem and ran

ISA Best Practices Analyzer and it suggested making the following changes and

it worked.

 

 

HKLM\SYSTEM\CurrentControlSet\Services\TCPIP\Parameters

 

EnableRSS Change to 0

 

EnableTCPA Change to 0

[Jim di Griz 13]

Die Reg-Changes sind vorhanden (BPA hatte ich auch schon mehrfach verwendet, die Settings stimmten seit Installation ),

 

die Networkbindings "sollten" auch stimmen, werd ich aber mal aendern um es auszuprobieren.

 

Vielen dank für den Hint