Here lies the error. As I could see in my gFTP log, gFTP sends: PORT "192,168,xxx,xxx,xxx,xxx" And this finally ends up in the $hostaddrstring. But as you can see from the address, this is the local-network-address of my workstation on our LAN here and not my actual public IP. That's why the test in Net::FTPServer fails.
NAT doesn't work well with clients that are actually servers. FTP in active mode is such a client. When requesting a file (including a directory listing), the server creates a connection to the client over which the data is sent.
FTP, being a very common protocol, is usually intercepted by NAT and "fixed". Instances of PORT are rewritten from the client's internal address to the router's external address.
Your problem is that this is not occurring. I can think of three reasons
- Your NAT software isn't capable of fixing FTP PORT commands. (Not likely)
- Your NAT software isn't configured to fix FTP PORT commands.
- Your NAT software doesn't realize your connection is an FTP communication. (Most likely)
How does NAT know whether a socket is a used as an FTP command connection? Commonly,
- Any outgoing connection to TCP port 21 is presumed to be an FTP command connection.
- All other connections are presumed to not be FTP command connections.
Is your server running on port 21?
Does anyone know where in my client/workstation/linux-machine setup the flaw is?
Simply put, you aren't using passive mode. Most FTP clients default to passive mode. That way, all the connections are made from client to server.