Its easy to forget about the –debug parameter, but a lot of times it can be very helpful, especially with NetCmdlets where in many cases –debug will output the protocol interface (the “PITrail” as we call it at /n software) of the connection. The PITrail includes a trail of communication between the cmdlet and the remote host it is talking to.
Rob emailed me to ask for help diagnosing a 425 error he was getting when using the NetCmdlets get-ftp cmdlet. As I described to Rob, in a nutshell the 425 problem happens because the FTP client (the cmdlet in this case) is unable to open a TCP data connection (for transferring data like file directory listings or file contents) on the ip and port that the server told it to use.
Adding the -debug parameter to the get-ftp call, I can see what ip and port the server is telling me to connect to:
In Rob's case, his 415 error happened right after the LIST command. By using –debug, we were able to see without a doubt that the server was actually sending a valid ip and port in its response, but that port simply wasn’t open on the firewall guarding the server machine.
The firewall *should* have been able to see the port that the server chose and open it up, but I guess this particular firewall just isn’t that smart. Anyway, Rob was able to correctly configure a smaller passive port range in IIS FTP and sync that range with his firewall.
Related: FTP Error 425,
FTPS Through NAT