HeRo wrote:At the same time it might be a good idea to make passive mode the default instead of active mode, since there seems to be more problems with the active mode.
I can offer quick comparison for that:
Code: Select all
Client Active Passive
-------------------------------------------------------------------
1) Public IP (incoming allowed) OK OK
2) Public IP (incoming blocked) FAIL OK
3) Behind NAT with forwarded data ports OK OK
4) Behind NAT without FTP helper FAIL OK
5) Behind NAT with FTP helper, no SSL OK OK
6) Behind NAT with FTP helper, with SSL FAIL OK
7) Client 1), 3) or 5) with misconfigured server OK FAIL*
1) Either without firewall or with exception for TC to allow any incoming connection. Quite standard, but with IPv4 exhaustion it will be less often available.
2) As 1), but without proper configuration.
3) Manually forwarded data ports. Rare.
4) Client sends private address to server and NAT router does not rewrite it.
5) Similar to 4), but router inspects packets and rewrites addresses. Most common.
6) Exactly the same as 5), but if the connection is encrypted, packets can't be inspected by router. On the rise, frequent source of confusion, "but it worked so well without SSL, what happened?"
7) Server behind NAT without configured data ports forwarding, data ports blocked by firewall or something like that. If the server returns private address in reply to PASV command, TC converts it to public address of server (unless turned off by SpecialFlags=1024) which can also cause problems in some specific cases, but sometimes it might actually help.
For me the winner is obvious. :)