I just went through many hours of trying to figure out wierd FTP problems. It looks like Peer1 has a weird firewall which gets confused on EPSV FTP connections. The way that the problem presented was that after login, when the FTP client attempted a directory listing (or any other command), after giving the EPSV command it would just hang.
For those who don't know, EPSV is "extended passive mode", and is a newer extension to FTP's historical passive mode (PASV), which is used to make FTP work in firewalled environments. I really don't know much about EPSV beyond that, although I think it was developed for enhanced future compatibility with IPv6.
Anyway, the problem is that most recent FTP clients attempt EPSV first, and then only use the traditional PASV if it fails. Also, most recent FTP servers support EPSV. Therefore, even if the firewall is blocking EPSV, the client will think that the command is successful, because the server is trying to do it, not knowing that it is being blocked.
I use vsftpd. The only way I found to prevent EPSV mode is to use their command whitelisting feature, and whitelist everything except EPSV and EPRT (the extended version of the FTP PORT command). So, here's what I added to my vsftpd.conf file, and it seems to work so far:
So now when a client attempts an EPSV command, it will respond with "550 Permission denied." and the client will usually fall back to regular PASV mode. I wish I could have blacklisted the command rather than whitelisting all other commands, but oh well.
If you have access to the client side of the connection, and don't/can't mess with the server side, you can usually turn off extended passive mode there as well. With curl, you need to add --disable-epsv. With regular ftp, you need to issue the command "epsv4" after connecting.