Windows Server, NAT und der FTP-Transparentproxy

Auf der Arbeit haben wir einen Server, den wir als Hyper-V-Host benutzen. Auf dem Server läuft NAT (als Teil von Routing/RRAS), damit die virtuellen Maschinen alle eine private IP-Adresse haben und über den Host (als Gateway) ins Internet kommen bzw. ihre Dienste kontrolliert anbieten können. So weit, so gut.

Jetzt hatten wir das Problem, dass wir von den Gästen keine Verbindung zu FTP-Servern herstellen konnten. Es gab auch keinen Workaround; es gab exakt diesen einen FTP-Server, der nur FTP anbot. Kein HTTP, kein alternativer Server.
Der übrige Traffic lief normal durch – eingehender Traffic, ausgehender Traffic, alles wurde durch den Host und die NAT geroutet und durch die Firewall gefiltert. Perfekt. Bis auf das Problem mit FTP.

Die Firewall konnte es nicht sein, immerhin gab es keine explizite Regel für Port 21, und ohnehin – die VM stellt die Anfrage (ausgehender Traffic), und normalerweise sollte die Firewall solche passiven FTP-Verbindungen auch dynamisch erlauben.
Ports über und unter 1024 liefen gleichermaßen normal; auch bekannte Ports wie 25 oder 110, die von manchen ranzigen ISPs weggeblockt werden, um Spam-Server zu verhindern, waren nicht betroffen.
Auch im NAT-Router war kein Filter irgendeiner Art eingestellt (abgesehen von den Portweiterleitungen, aber die spielen ja nur für eingehenden Traffic eine Rolle). Trotzdem kam die Verbindung nie über ein SYN hinaus, das am Hostrechner verendete.

Ping, Traceroute und sonstige Tools waren erfolgreich; andere Dienste auf den getesteten FTP-Servern waren auch nicht beeinträchtigt. Nur FTP weigerte sich zu arbeiten.

Ein paar Stunden (ja, Stunden. Und wir waren zu dritt damit beschäftigt) später haben wir das Problem finden können: der FTP Transparent Proxy.

Die Dokumentation in TechNet ist ziemlich spärlich und hilft für dieses konkrete Problem nicht weiter. Die meisten Suchergebnisse bei Google sind entweder russisch, behandeln Linux-Server oder beschäftigen sich damit, wie man durch eine NAT seinen eigenen FTP-Server ansprechen kann.

Die Lösung ist ein Einzeiler auf der Kommandozeile:

netsh routing ip nat delete ftp

Und plötzlich waren die Verbindungen von Hyper-V-Gästen zu FTP-Servern erfolgreich.