Why can't I connect to some ftp servers from behind my win2008 NAT?

Solution 1:

The little-bit-of-text that does get through suggests it might be some sort of MTU problem. The best way to move forward is to install Wireshark on the gateway and capture all the traffic involved in the FTP connection. If you see a large packet being sent multiple times, it's MTU. Otherwise, paste the trace somewhere and someone can interpret it for you, if it isn't clear to you.

Solution 2:

As a side note, the CRC problem is usually caused by the checksumming done direcly on the NIC in hardware. The OS stack doens't see the checksum correctly anymore then.

Try to open the network card properties, and disable any kind of offload, it should remove these messages.

Update:

Upon further analysis of your logs, the packet that doesn't seems to be recieved is only 166 bytes long (it's the "Bienvenue" one that gets retransmitted over and over on the LAN interface), so I don't think it's an MTU issue here. It doesn't seems to be auth/ident because the server sends all packets. It is although the first one that has a CRC error in it.

Try to disable all the hardware accelerations (offload) on the internal nic, and eventually on the external one also if it doesn't help. Having a fixed speed and duplex is also quite nice when troubleshooting to enable one potential cause at a time (10/half-duplex is good start). If it works, just reenable thing one-by-one, to be able to pinpoint where the problem is.

If nothing works, it may be the FTP-NATing software that is at fault : FTP is a protocol that has to be mangled to work through NAT (not here usually). Try to use a FTP-proxy (Layer 7) software. If that works, you'll have a workaround since it seems only for FTP.

Solution 3:

The FTP application proxy in your NAT gateway appears to be borking on the '220-' multi-line response code.

FTP response codes are normally all single line, but the '-' after the number indicates that more lines of output are coming.

I've seen this happen before - from memory in my case it was a PIX firewall.

I seem to recall that some FTP servers can be told not to send multi-line responses by prefixing the login password with a '-', EDIT, however in this case that's not the fix because the 220- response is being sent before the user attempts to login.

If you are friendly with the administrator of the FTP server, ask them to temporarily disable their server's login banner and see whether your login proceeds any further.

Solution 4:

I think, I've got the same annoying problem at my office with IPtables, except we know it happens and don't want to fix it.

It might help to check which ports you're blocking for incoming traffic. I'm pretty sure FTP only uses 21 for incoming connections (i.e. you can connect to something, but you can't dir on it).

I'm pretty sure that the port you get in return is negotiable, so it might be a good idea to scrap FTP and use SFTP in this case if you can.