WS 2012 R2 als NAT-Router: Timeout zu fremden FTP-Servern

[LigH 12]

Ich habe einen Windows Server 2012 R2 als NAT-Router eingerichtet, so wie vorher schon einmal mit einem Windows Server 2003 R2.

 

Damals mit dem WS2003 habe ich mit allen Programmen problemlos Verbindung aus dem LAN ins Internet bekommen, egal mit welcher Art von Programm (Webbrowser, FTP-Client, Telnet/SSH, sonstige TCP- und UDP-Anwendungen...).

 

Mit dem WS2012 klappt auch fast alles. Bis auf FTP. Mit keinem der mir vorhandenen Programme (FileZilla, Far manager 3, Poderosa - Telnet an Port 21) wird eine Verbindung zu irgendeinem FTP-Server im Internet aufgebaut, es wird immer mit Zeitüberschreitung abgebrochen. In der Liste der Zuordnungen (Routing und RAS - NAT) kann ich keine Verbindung zu Remote-Port 21 von der privaten IP-Adresse sehen, auf dem der FTP-Client läuft. Wenn ich eine SSH-Verbindung zum selben Server habe, ist die Verbindung zum Remote-Port 22 aber eingetragen.

 

Ignoriert der Server Verbindungsversuche zu Remote-Port 21 absichtlich? Wo kann ich prüfen, ob entsprechende Regeln existieren? Ich fände es ja sehr überraschend, wenn NAT für FTP standardmäßig so deaktiviert wird. In der Windows-Firewall auf dem Server habe ich noch nichts in der Hinsicht entdeckt, ausgehende TCP-Verbindungen sind erst mal grundsätzlich alle erlaubt.

[LigH 12]

Nachtrag: Direkt auf dem Server kann ich mit einem FTP-Client arbeiten. Nur aus dem Intranet über den Server ist es nicht möglich.

[Sunny61 773]

Du darfst und mußt sogar (lt. Boardregeln) auf den anderen Thread hinweisen, Danke: http://social.Technet.microsoft.com/Forums/de-DE/windowsserver8de/thread/338599cf-26b4-4425-a44f-c624b79048a0#338599cf-26b4-4425-a44f-c624b79048a0 Im Technet kannst Du auch auf diesen hier verweisen.

[LigH 12]

Danke für den Hinweis, mach ich dann... — Verlinken darf ich da noch nicht.

 

Gibt es für die Boardregeln zum späteren Nachlesen auch einen Link? Bisher hab ich den von der Startseite aus noch nicht entdeckt.

bearbeitet 2. Juli 2014 von LigH

[Dr.Melzer 191]

Gibt es für die Boardregeln zum späteren Nachlesen auch einen Link?

Bitte sehr: http://www.mcseboard.de/topic/191452-mcseboardde-regeln-nutzungsbedingungen/

[Sunny61 773]

Die No. 19 suchst Du. ;)

[LigH 12]

Es hat sich was getan ... ein Teil der Ursache scheint mir nun bekannt zu sein.

 

Trotz der Einrichtung eines NAT-Routers durch Aktivieren von Routing & RAS, bei dem man ja festlegen mus, was Internet- und was Intranet-NIC ist, sind dennoch beide NICs in der Netzwerkumgebung vom Zugriffstyp "Internet"; außerdem ist die Internet-NIC mit einem "privaten Netzwerk" verbunden, die Intranet-NIC dagegen mit einem "öffentlichen Netzwerk" (vom Typ "nicht identifiziertes Netzwerk"). Entsprechend werden also auch für Verbindungen aus dem Intranet von der Firewall die restriktiven Internet-Regeln angewendet. Mit der Folge, dass ein Großteil der SMB-bezogenen Kommunikation behindert wird. Und eben auch FTP-Zugriffe durch den NAT-Router hindurch geblockt wurden.

 

Leider habe ich bisher nicht gefunden, wie ich die NICs den logischen Netzwerken zuordnen kann, um diese genau umzukehren, in der Hoffnung, dass dann auch in der Firewall Regeln für private Netzwerke für das Intranet gelten und dadurch auch Netzwerkfreigaben sichtbar werden und die Kommunikation unter den Arbeitsplätzen nicht behindert wird.

[Sunny61 773]

Den Netzwerktyp kann man in der Registry umstellen. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\NetworkList\Profiles

 

http://answers.microsoft.com/de-de/windows/forum/windows_7-networking/internetzugang-geht-nicht-weil-heimnetzwerk-als/c15b3a71-877d-42a1-a965-4e5a04bbe29f

http://social.technet.microsoft.com/Forums/windowsserver/en-US/89714024-b5a9-4ac6-bd83-d485a8d5f5ce/how-to-assign-a-network-category?forum=winservercore

[LigH 12]

Danke, interessant ... im Zweig "Profiles" habe ich nur einen Eintrag. Hätte wegen zwei NICs eigentlich auch zwei Profile erwartet.

[LigH 12]

Mal noch ein wenig zum NAT-Routing belesen: Dass das "Intranet"-Netzwerk als "nicht identifiziert" gemeldet wird, lag an einer falschen Konfiguration des IPv4-Protokolls im Adapter. Die Intranet-Gateway-Karte darf selbst weder Gateway-Adresse noch DNS-Server-Adresse haben, beides muss leer bleiben. So ist der Netzwerk-Umgebung nun auch halbwegs verständlich, dass hier "Internetverbindung" und dort "keine Internetverbindung" existiert.

 

Aber noch gibt es Schwierigkeiten mit der gegenseitigen Sichtbarkeit. Das kann allerdings auch wieder weitere Gründe haben, daran muss nicht die Firewall alleine Schuld sein, auch der Dienst "Computer-Browser" ist berüchtigt...

bearbeitet 17. Juli 2014 von LigH

[LigH 12]

Je länger ich erfolglos experimentiere, umso weniger verstehe ich die Logik. Werde ich von WS2012R2 dazu gezwungen, eine Domain zu verwenden, wenn ich ihn als NAT-Router verwenden will? Bei einer Arbeitsgruppe gibt es offenbar einen wesentlichen Haken im Zusammenspiel zwischen NAT-Routing, Netzwerk-Kennungen und Firewall-Regeln:

 

Wenn ich RRAS als NAT-Router installieren will, muss für die Intranet-NIC bei IPv4 unter anderem das Feld für das Gateway leer bleiben.

 

Wenn bei einem Netzwerkadapter das Feld für das Gateway leer ist, wird das zugehörige Netzwerk nicht identifiziert.

 

Nicht identifizierte Netzwerke werden als "öffentlich" behandelt, wenn sie nicht zu einer Domain gehören.

 

In öffentlichen Netzwerken ist die Netzwerkerkennung deaktiviert, und die Firewall blockiert überwiegend eingehende Verbindungen.

 

Ergebnis: Der NAT-Router-PC mit Server-Windows wird in der Arbeitsgruppe nicht nur nicht erkannt, sondern behindert auch noch den Austausch zwischen den Arbeitsstationen.

 

Und dazu jetzt die blöde Frage: Was mache ich falsch?!

bearbeitet 17. Juli 2014 von LigH