Re: 425 Can't Open Data Connection
Posted: 2014-09-08 19:42
NAT is a technology that hides any network behind one IP. For that reason, connections from the Internet end on your router, they can't see anything beyond. Hence, the IP service can only show the router IP.
Running services behind NAT routers requires port forwarding. That's true for every router on the server side (if there's more than one in line). Port forwards must be done for ALL ports that are involved. FTP requires many ports (hundreds to thousands). There are two modes of operation:
1. Active (PORT) mode, as shown by your logs. Mostly used by lazy server admins or in case of providers blocking ports. As you see, the PORT command is sent by the client, not the server. The server will connect back to the client for data connections. Thus, in Active mode, the client has to forward the data ports in the client router, and the client must tell the FTP client software the client network's public IP plus the ports to use. Your logs show incorrect configuration (non-public IP in PORT command).
2. Passive mode, the recommended one. The client sends PASV and the server will propose an IP and data port (=socket) on the server side. Passive mode will work for clients out-of-the-box as every configuration is done by the server. The actual actions are the same: Forward plenty of ports for Passive data connections and tell the FTP server to use them. Let the server software know the server networks public IP.
Note that the 'matching ports' issue is true for both modes. Alteration of the PORT command's or PASV reply's payload just asks for trouble.
Guide for getting both Active and Passive mode to run: Network Configuration. It is for FileZilla's software but many parts can be applied to other FTP software as well.
Note 1: Some routers are so badly programmed that all proper Active mode configuration is in vain.
Note 2: Everything said here does NOT apply to IPv6.
PS: You might ask why the client did even reach the server with that wrong configuration? Well, that's the most prominent case where routers manipulate FTP traffic. As you see, it fails regularly.
Running services behind NAT routers requires port forwarding. That's true for every router on the server side (if there's more than one in line). Port forwards must be done for ALL ports that are involved. FTP requires many ports (hundreds to thousands). There are two modes of operation:
1. Active (PORT) mode, as shown by your logs. Mostly used by lazy server admins or in case of providers blocking ports. As you see, the PORT command is sent by the client, not the server. The server will connect back to the client for data connections. Thus, in Active mode, the client has to forward the data ports in the client router, and the client must tell the FTP client software the client network's public IP plus the ports to use. Your logs show incorrect configuration (non-public IP in PORT command).
2. Passive mode, the recommended one. The client sends PASV and the server will propose an IP and data port (=socket) on the server side. Passive mode will work for clients out-of-the-box as every configuration is done by the server. The actual actions are the same: Forward plenty of ports for Passive data connections and tell the FTP server to use them. Let the server software know the server networks public IP.
Note that the 'matching ports' issue is true for both modes. Alteration of the PORT command's or PASV reply's payload just asks for trouble.
Guide for getting both Active and Passive mode to run: Network Configuration. It is for FileZilla's software but many parts can be applied to other FTP software as well.
Note 1: Some routers are so badly programmed that all proper Active mode configuration is in vain.
Note 2: Everything said here does NOT apply to IPv6.
PS: You might ask why the client did even reach the server with that wrong configuration? Well, that's the most prominent case where routers manipulate FTP traffic. As you see, it fails regularly.