Da FTP IP-Adressen und -Ports innerhalb solcher Nachrichten sendet (nicht nur in den Paketköpfen), handelt es sich nicht um ein NAT-freundliches Protokoll.
Aus diesem Grund verfügen NAT-Gateways häufig über einen speziellen Code für die Verarbeitung von FTP. Dieser Code wird als FTP "Application Layer Gateway" oder ALG bezeichnet. FTP-ALGs suchen nach Nachrichten wie dem PASV-Befehl und schreiben die IP-Adresse erneut, um die öffentliche IP-Adresse des NAT-Gateways darzustellen, damit die Kommunikation funktioniert.
Befindet sich Ihr FTP-Client hinter einem NAT-Gateway und Ihr FTP-Server nicht, können Sie den passiven Modus verwenden, um ein fehlerhaftes NAT-Gateway ohne FTP-ALG zu umgehen.
Befindet sich Ihr FTP-Client NICHT hinter einem NAT-Gateway, sondern Ihr FTP-Server IST, können Sie normales aktives FTP problemlos verwenden. In diesem Fall würde der Passivmodus jedoch tatsächlich abbrechen, wenn das NAT-Gateway vor dem FTP-Server nicht vorhanden ist ein gutes FTP-ALG. Viele NAT-Gateways verfügen über halb gebrochene FTP-ALGs, die aktive FTP-Funktion für FTP-Clients hinter dem NAT ermöglichen, jedoch nicht den Fall "FTP- Server hinter dem NAT" behandeln. Offensichtlich denken viele Anbieter von NAT-Gateways nicht an den Server-behind-the-NAT-Fall.
Wenn sich sowohl Ihr FTP-Client als auch Ihr FTP-Server jeweils hinter separaten NAT-Gateways befinden, die keine FTP-ALGs haben, wird aktives FTP vom NAT des Clients blockiert und passives FTP wird vom NAT des Servers blockiert Wenn Sie in diesem Fall überhaupt kein FTP verwenden, müssen Sie eine Art Tunnel oder eine andere Problemumgehung einrichten. Die Umstellung auf verschlüsseltes FTP wird funktionieren, da verschlüsselte FTP-Protokolle entwickelt wurden, nachdem NAT-Gateways üblich waren und die Autoren wussten, dass ein NAT-Gateway die Interna des Protokolls nicht sehen oder sich damit vermischen kann. Daher mussten sie es so entwickeln, dass es funktioniert in allen verschiedenen NAT-Szenarien.