Werden Daten zum Server übertragen und die Übertragung einer Datei dauert länger als ca. 2 Minuten, so bricht die Kommunikation nach der (erfolgreichen) Übertragung ab. Unabhängig ob aktives oder passives FTP benutzt wird. Der Download vom Server verläuft problemlos.
KB931130 richtet sich genau auf dieses Problem (bin ich erst später darauf gestoßen).
Aus dem Firewallprotokoll leite ich anhand mehrerer Versuche mit Aktiv- und Passiv-FTP folgendes ab:
Es gibt je nach Bedarf mehrere Möglichkeiten der Abhilfe.
Wird nur aktives FTP benötigt:
Wird aktives und passives FTP benötigt:
Es muss also vermieden werden, dass gleichzeitig der "Gatewaydienst auf Anwendungsebene" und die "FTP-Dienst"-Ausnahme der Firewall aktiv sind, da deren fehlerhaftes Zusammenspiel unterdrückt werden muss.
KB931130 beschreibt eine Lösung, die ich nicht getestet habe, aber die gleiche Wirkung verspricht (ALG verwaltet keine Portmappings für den FTP-Dienst):
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ALG\ISV\{6E590D61-F6BC-4dad-AC21-7DC40D304059}]
"PreferExternalManifest"="Disable"
Im Firewallprotokoll fällt auf, dass noch vor Abschluss der Übertragung der Port 21 in der Firewall des Servers geschlossen wird (war für ca. 120s offen). Nach der Übertragung sendet der FTP-Server über Port 21 die Quittung "226 Transfer complete". Dazu wird Port 21 wieder geöffnet, jedoch wird an einen völlig falschen Client-Port gesendet - das Paket wird von Client-Seite abgelehnt und eine entsprechende ICMP-Nachricht an den FTP-Server geschickt.
Auszug auf dem Server-Firewall-Protokoll bei Passiv-FTP mit aktivierter Firewall (FTP-Dienst erlaubt):
| time | action | protocol | src-ip | dst-ip | src-port | dst-port | Anmerkung |
|---|---|---|---|---|---|---|---|
| 08:58:28 | OPEN-INBOUND | TCP | client | server | 2478 | 21 | Verbindungsaufbau |
| 08:58:29 | OPEN-INBOUND | TCP | client | server | 61016 | 5001 | PASV-Anfrage |
| 08:58:49 | OPEN-INBOUND | TCP | client | server | 61017 | 5002 | PASV-Anfrage |
| 08:59:28 | CLOSE | TCP | client | server | 61016 | 5001 | abgebaut 08:58:29 |
| 09:00:28 | CLOSE | TCP | client | server | 2478 | 21 | vorzeitiges Schließen |
| 09:00:39 | OPEN | TCP | server | client | 21 | 48641 | Senden "Transfer complete" |
| 09:01:00 | CLOSE | TCP | server | client | 21 | 48641 | abgebaut 09:00:50 |
| 09:01:28 | CLOSE | TCP | client | server | 61017 | 5002 | abgebaut 09:00:39 |
Die eigentliche Übertragung der Datei (STOR bis Transfer complete) über Port 5002 fand von 08:58:49 - 09:00:39 statt.
Auszug auf dem Server-Firewall-Protokoll bei Aktiv-FTP mit aktivierter Firewall (FTP-Dienst erlaubt):
| time | action | protocol | src-ip | dst-ip | src-port | dst-port | Anmerkung |
|---|---|---|---|---|---|---|---|
| 10:45:03 | OPEN-INBOUND | TCP | client | server | 4913 | 21 | Verbindungsaufbau |
| 10:45:04 | OPEN | TCP | server | client | 20 | 5001 | PORT |
| 10:45:20 | OPEN | TCP | server | client | 20 | 5002 | PORT |
| 10:46:49 | CLOSE | TCP | client | server | 4913 | 21 | vorzeitiges Schließen |
| 10:47:08 | OPEN | TCP | server | client | 21 | 46206 | Senden "Transfer complete" |
| 10:47:08 | CLOSE | TCP | server | client | 20 | 5002 | abgebaut 10:47:08 |
| 10:47:15 | CLOSE | TCP | server | client | 20 | 5001 | abgebaut 10:45:04 |
| 10:47:29 | CLOSE | TCP | server | client | 21 | 46206 | |
| 10:48:30 | OPEN-INBOUND | TCP | client | server | 4913 | 21 | |
| 10:48:49 | CLOSE | TCP | client | server | 4913 | 21 |
Die eigentliche Übertragung der Datei (STOR bis Transfer complete) über Port 5002 fand von 10:45:20 - 10:47:08 statt.
Der FTP-Sitzungstimeout (der sofort gültig ist) hat auf das Verhalten der Firewall keine Auswirkung. Wird die Sitzung nicht geschlossen, schließt der Server nach der Wartezeit des Timeouts automatisch die Sitzung ("421 Timeout"). Da jedoch die Firewall stets vorher den Port 21 bereits geschlossen hat, schlägt dieser Kommunikationsversuch ebenfalls fehl.
Dazu aus dem MS-TechNet-Artikel How Windows Firewall Works:
With the exception of some File Transfer Protocol (FTP) traffic, Windows Firewall does not use Application layer information to statefully filter traffic. FTP is a special case [...] Windows Firewall uses the Application Layer Gateway Service to provide dynamic port mapping for the FTP data channel, thereby facilitating the stateful filtering of FTP traffic.
Note: Passive (PASV) FTP is not treated as a special case and is not handled by the Application Layer Gateway Service. PASV FTP traffic is statefully filtered by Windows Firewall in the same way other TCP/IP traffic is statefully filtered.
The Application Layer Gateway Service (sometimes known as the ALG service) is required if you enable Windows Firewall on a computer that is an FTP client or FTP server that does not use PASV FTP. The Application Layer Gateway Service listens for outgoing FTP traffic from an FTP client. It then extracts the port from which the FTP client is expecting to receive data and creates an appropriate dynamic port mapping for the FTP data channel.
The Application Layer Gateway Service and Windows Firewall interact as follows:
- If the Application Layer Gateway Service is disabled and you try to enable Windows Firewall, Windows Firewall will start, but FTP traffic that does not use PASV FTP might fail.
- If you stop the Application Layer Gateway Service while Windows Firewall is running, Windows Firewall will continue to run, but FTP traffic that does not use PASV FTP might fail.
- If the Application Layer Gateway Service is stopped and its startup type is set to Manual, then the Application Layer Gateway Service will attempt to start when you enable Windows Firewall.
Soll für den Server heißen: