4

I want to connect to an FTP server from my local network, which is behind a NAT.

The gateway is a Win 2008 server, configured with routing and remote services / Nat enabled. The problem exists from XP, Vista sp1, and Vista sp2 computers.

Here's what I get (using the default DOS ftp client, but I get the same thing using FileZilla)

ftp> open ftp.foo.com
Connected to ftp.foo.com.
220-

[here I wait for 30s before getting the following line]

Connection closed by remote host.
ftp>

As you can see I'm disconnected before the login process, so I don't have the opportunity to use PASSV.

Here's what works :

  • everything else (ie, every non-ftp related connection)
  • connection to this specific server from my NAT gateway
  • connection on other servers from my behind-nat computer
  • direct internet connection to this specific ftp server from my computer (ie, without using the NAT server)

The company providing the ftp says the problem is not on their end, since I can connect from my NAT server. The same reasoning leads to the problem not being on my side neither (I can connect on other ftp servers)

What should I check ?


EDIT : here's what I get when I sniff the connection on the gateway while attempting to connect from my behind-the-nat computer :

On the Internet facing interface :

No.     Time        Source                Destination           Protocol Info
   1312 320.576218  213.186.xx.xxx        192.168.1.1           FTP      Response: 220-
   1313 320.576602  213.186.xx.xxx        192.168.1.1           FTP      Response: 220-Bienvenue, 
   1315 320.610911  213.186.xx.xxx        192.168.1.1           FTP      Response: 220-

And on my internal LAN interface :

    No.     Time        Source                Destination           Protocol Info
       9288 118.698920  213.186.xx.xx        192.168.0.100         FTP      Response: 220-

       9293 118.890406  213.186.xx.xx        192.168.0.100         FTP      Response: 220-Bienvenue, 
    Frame 9293 (166 bytes on wire, 166 bytes captured)
    Ethernet II, Src: Tp-LinkT_c6:e2:3f (00:21:27:c6:e2:3f), Dst: Giga-Byt_22:b0:99 (00:1f:d0:22:b0:99)
    Internet Protocol, Src: 213.186.xx.xx(213.186.xx.xx), Dst: 192.168.0.100 (192.168.0.100)
    Transmission Control Protocol, Src Port: ftp (21), Dst Port: jini-discovery (4160), Seq: 7, Ack: 1, Len: 112
        Source port: ftp (21)
        Destination port: jini-discovery (4160)
        Sequence number: 7    (relative sequence number)
        [Next sequence number: 119    (relative sequence number)]
        Acknowledgement number: 1    (relative ack number)
        Header length: 20 bytes
        Flags: 0x18 (PSH, ACK)
        Window size: 65536 (scaled)
        Checksum: 0xa5bc [incorrect, should be 0x96cb (maybe caused by "TCP checksum offload"?)]
        [SEQ/ACK analysis]
    File Transfer Protocol (FTP)

   9306 119.187327  213.186.xx.xx        192.168.0.100         FTP      [TCP Retransmission] Response: 220-Bienvenue, 
   9326 119.787350  213.186.xx.xx        192.168.0.100         FTP      [TCP Retransmission] Response: 220-Bienvenue, 
No.     Time        Source                Destination           Protocol Info
   9373 120.987450  213.186.xx.xx        192.168.0.100         FTP      [TCP Retransmission] Response: 220-Bienvenue, 

Any idea of why this CRC problem might be happening ?

btw, here are my mtu settings (on the gateway)and they are identical on my computer.

C:\Windows\system32>netsh interface ipv4 show interfaces
Idx  Met   MTU   State        Name
---  ---  -----  -----------  -------------------
  1   50 4294967295  connected    Loopback Pseudo-Interface 1
 10   30   1500  connected    Local Area Connection
 13   20   1500  connected    Local Area Connection 2

And here's some MTU analysis on my computer :

Pinging 192.168.0.1 with 1472 bytes of data:
Reply from 192.168.0.1: bytes=1472 time<1ms TTL=128

Pinging 192.168.0.1 with 1473 bytes of data:
Packet needs to be fragmented but DF set.

Here's what I get if I try to connect using telnet :

220-

Connection to host lost.

Press any key to continue...
4
  • What happens if you telnet to port 21 and type in the commands by hand. slacksite.com/other/ftp.html see passive example. Interesting part would be if you could type USER xxxxx and get a response.
    – Rex Logan
    May 8, 2009 at 3:55
  • @Rex : I edited my post.
    – Brann
    May 8, 2009 at 8:18
  • Did you try disable any kind of NIC hardware acceleration ? May 9, 2009 at 7:48
  • It looks like your server is correctly passing the traffic back to the internal address. How about a sniff from the client side to see if it's receiving the packets (it's either not ACKing, or you stripped them). May 11, 2009 at 17:01

7 Answers 7

3
+50

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.

1
  • @womble: Done (in the original question)
    – Brann
    May 4, 2009 at 12:40
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.

2

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.

3
  • You could be right. Maybe there is something like ip_contrack_ftp on Windows as well? Is there a way to disable special FTP NAT tracking on Windows Server?
    – Martin C.
    May 11, 2009 at 7:00
  • The NAT function in Windows Server 2008 will indeed need an ALG to cope with re-writing any PORT commands in the FTP stream. This still looks like a broken ALG to me. I've just realised that the "prefix the password with -" won't work here, though, because this connection is breaking before the username and password are supplied.
    – Alnitak
    May 11, 2009 at 15:38
  • 1
    and now I'm not so sure... the packet dumps do actually show the '220-Bienvenue' message getting through the NAT gateway, but being apparently ignored by the client machine.
    – Alnitak
    May 11, 2009 at 15:50
1

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.

0

You could try to use the debug command in Windows commandline ftp. Perhaps it will show you some extra information which leads to the solution.

1
  • @splattne : tried it, it didn't add any extra-information in this case. Thanks anyway.
    – Brann
    May 4, 2009 at 12:12
0

Patient: Doctor, Doctor! When I drink a cup of tea I get a stabbing pain in my eye.
Doctor: Try taking the spoon out of the cup!

The point being: why are you using your server as a NAT gateway? Doesn't your modem/router do that? Why not take the server out of the path?

0

The way our FTP server (proftpd) works is that it listens for connections on port 21, and then *once connected, bumps the connection up to the 60000 range** (set in proftpd.conf as PassivePorts)

Our NAT was originally set up to only forward port 21 to the FTP server, and we saw similar behavior to what you are seeing.

By restricting PassivePorts to a specific range, and forwarding that range in the NAT configuration, it solved our problem.

Of course, that is from the server side point of view

It could be easily tested however by temporarily NATting all ports, and seeing if it resolves the issue.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .