none
WS2012R2 als NAT-Router blockiert Zugriffe auf äußere FTP-Server RRS feed

  • Allgemeine Diskussion

  • Guten Tag.

    Ich habe einen Windows Server 2012 R2 Standard hauptsächlich als NAT-Router für ein kleines Firmennetzwerk eingerichtet, so wie es vorher auch schon einmal mit einem Windows Server 2003 R2 funktioniert hatte: Installieren von DHCP, DNS, Routing & RAS; Intranet-NIC auf feste IP setzen; Routing & RAS aktivieren. So hat jeder PC im Firmennetz problemlos Zugriff auf praktisch alle Dienste im Internet (HTTP[S], NTP, SSH/Telnet, BitTorrent; sogar ein Online-Spiel mit UDP läuft, um mal was ungewöhnliches probiert zu haben).

    Außer FTP.

    Egal mit welchem FTP-Client (Webbrowser, FileZilla, Far manager 3, Telnet auf Port 21), bereits der Versuch, eine TCP-Verbindung aufzubauen, schlägt mit einer Zeitüberschreitung fehl. (Nur falls jemand - wie im IRC mehrfach passiert - vorschlagen möchte, den passiven Modus zu probieren: Das PASV-Kommando kann ich nicht senden, bevor überhaupt eine TCP-Verbindung besteht...)

    Es geht auch nicht um einen selbstverwalteten FTP-Server, sondern um beliebige FTP-Server im Internet, z.B. der zu unserer Firmenwebsite gehörende bei 1&1, oder der von der FU Berlin oder TU Chemnitz...

    In der Liste der Zuordnungen (Routing & RAS - NAT) sehe ich auch keine Verbindungen zu einem Remote-Port 21. Die Anzahl zurückgewiesener NAT-Übersetzungen bleibt jedoch 0. In der Masse der Firewall-Regeln ist mir bisher noch keine aufgefallen, die einen Verbindungsversuch mit einem Remote-Port 21 verweigern würde.

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

    Wie kann ich nun systematisch nach der Ursache forschen?

    --

    P.S.: Auch gefragt im MCSEBoard; darf ich mit ungeprüftem Nutzerkonto aber noch nicht verlinken


    Mittwoch, 2. Juli 2014 07:43

Alle Antworten

  • Ich vermute, dass irgend eine Firewall-Regel dafür verantwortlich ist. Um in der Konsole   etwas zu finden, bietet es sich an, nach den Ports zu sortieren. Das erfolgt zwar alphabetisch statt numerisch, ist aber besser, als jede einzelne Zeile lesen zu müssen.

    Es kann sich bei dir um eine eingehende Regel handeln, die Port 21 nicht zulässt. Es kann auch sein, dass gar keine Regel für den Port vorhanden ist. Dann erstelle testweise eine und schau, ob du beim Verbindungsaufbau weiter kommst.

    Gemeinerweise kann man auch in Routing- und RAS solche Regeln festlegen. Dort sucht man sie meist nicht. Du findest sie, wenn du dir unter IPv4, Allgemein die Eigenschaften der Schnittstellen anschaust. Dort gibt es die Schaltflächen Eingehende Filter... und Ausgehende Filter....

    Mittwoch, 2. Juli 2014 12:28
  • Bei Routing & RAS sind die Listen für eingehende und ausgehende Filter für die Schnittstellen leer.

    Dass eine Firewall-Regel für eingehende Kommunikation verantwortlich sein soll, würde mich überraschen, denn ich will ja nicht auf Port 21 meines Servers zugreifen, sondern per NAT mit einem Server außerhalb im Internet kommunizieren, es müsste also nur die TCP-Verbindung weitergeleitet werden, so wie das auch mit allen anderen Diensten funktioniert. Aber wenn dem so wäre, dann wäre die Suche in der riesigen und unübersichtlichen Liste an Firewall-Regeln wohl aufwändig, da man keine eigenen Filter definieren kann. Unter den vorgegebenen Filtern ist gerade mal die nach aktiven Regeln nützlich.

    Mittwoch, 2. Juli 2014 13:18
  • Ja, teilweise. Das Aktivieren von Routing & RAS hat offenbar nicht wie erwartet eine weniger restriktive Regel für die Intranet-Netzwerkkarte eingestellt. Tatsächlich wurde die gleiche Firewall-Regel auf beide Netzwerkkarten angewendet.

    Ich weiß noch nicht, welche Lösung optimal wäre. Zur Zeit habe ich die Verwendung der Firewall für die Intranet-Netzwerkkarte deaktiviert; das könnte vielleicht latent unsicher sein... Aber seitdem ist nicht nur eine FTP-Verbindung wieder möglich, auch alle anderen merkwürdigen Netzwerk-Probleme (z.B. dass jeder Arbeitsplatzrechner im Netzwerk immer nur bestimmte wenige PCs in der Arbeitsgruppe gesehen hat, und auch dann kein zuverlässiger Zugriff auf Freigaben möglich war) scheinen nun gelöst.


    • Bearbeitet LigH-de Montag, 14. Juli 2014 08:04 Typo
    Montag, 14. Juli 2014 08:02
  • P.S. - noch dazu:

    Nach dem Aktivieren von Routing & RAS für ein NAT-Routing, bei dem man ja festlegen muss, welche NIC für das Internet und welche NIC für das Intranet zuständig ist, stimmt dennoch die Zuordnung zu logischen Netzwerk-Typen nicht, auch wenn das Routing funktioniert:

    Die NIC fürs Intranet ist verbunden mit einem "öffentlichen Netzwerk" (vom Typ "nicht identifiziertes Netzwerk") und hat den Zugriffstyp "Internet".

    Die NIC fürs Internet ist verbunden mit einem "privaten Netzwerk" und hat den Zugriffstyp "Internet".

    So haben dann wohl beide Netzwerkschnittstellen die restriktiven Firewall-Regeln, also wird auch im Intranet die SMB-Kommunikation für Freigaben und gegenseitige Erkennung behindert.

    Kann man diese Zuordnung irgendwo manuell korrigieren? Oder muss das NAT-Routing in Version 2012 anders initialisiert werden, als ich das mal früher für Windows Server 2000 gelernt hatte? Davon wäre ich zumindest nicht völlig überrascht...

    Dienstag, 15. Juli 2014 11:06