Vista FTP connection delay?

June 2, 2008 10:54 PM

Vista FTP 15 second connection delay?

From my Vista system, when I try to make an FTP connection to my server across my LAN (using the server's IP directly, no DNS involved), there's always a delay of about 15 seconds. This happens no matter what FTP program I use (I've tried 3, including the "FTP" command from the DOS box). However, when I disabled the Windows Firewall as an experiment, connection was instant. I don't want to leave the firewall turned off, for obvious reasons, so I need to figure out what I have to do to the firewall to make this work better.

I ran into this problem once before with XP, and the solution was to make a firewall rule change, but I can't remember what I did. (And I don't have that computer anymore so I can't check it.)

I did some searching on the net and found this:

"When SecureFX/AbsoluteFTP makes an outgoing connection to some FTP servers (wu.ftpd is known to have this problem, for example), the FTP server tries to authenticate a user based on auth/ident service (RFC 912, 931, and 1413) by attempting to connect to the client's machine on port 113."

"With the Windows XP SP2 firewall enabled, such packets are dropped and the FTP server continues to attempt auth/ident connections on port 113 until a timeout occurs."

"Once the ident/auth timeout occurs on the FTP server side, the FTP server will move on to normal authentication via USER and PASS."

"To resolve this time lag issue, create a port exception in the Windows firewall for port 113. Since there isn't anything listening on port 113 on the XP machine, the port exception will cause the FTP server to receive a "Connection Refused" error when the auth/ident connection attempt is made to port 113. Once the FTP server receives this error, the server will switch to normal USER and PASS authentication, significantly reducing the lag time before connection."

Which certainly sounds like exactly the problem I'm having. But I just tried this, and it didn't make any difference. Maybe I did it wrong, though, or maybe there's something else I have to do instead, or in addition. Help?

I opened up the Firewall from the control panel.
I clicked "change settings" and got a popup.
(This is "Vista Home Premium" so I got asked for admin privilege, which I granted.)
I selected the "Exceptions" tab.
I clicked "Add Port".
In the popup I entered "Auth TCP" for the name.
I entered port number 113.
I selected TCP.
I didn't mess with the scope.
I entered "OK".
I did the same for Auth UDP.
Both of my new entries show with checkmarks.
Then I hit OK on the settings popup.
I closed all windows and rebooted.

And the result? No change in behavior, no matter what FTP program I use. With the DOS box FTP, there's still a long delay before I'm asked to log in to my server.

(Note: My FTP program is listed in the "Exceptions" panel and is check-marked. But if the description above is correct, this is not a problem with my FTP program. Please do not suggest alternate FTP programs to try; I'm sure that's not the solution.)

posted by Class Goat to computers & internet (11 comments total)

Hmm. The problem you've described is indeed common with internal ftp servers, and you have opened up the ident port correctly. I assume you're not running an additional firewall like norton or zonealarm, as turning off the built in firewall fixed it. As you say, changing ftp client will not help.

I also assume you don't run the ftp server on the lan (otherwise, you could just turn off ident checks on the server - they're a security risk anyway since ident is definitely obsolete)

The reason for turning the firewall off for that port is to basically allow it to connect; but since there's no ident server running, it fails instantly, rather than just being ignored silently by the firewall. You can test this using another pc on your lan; run "telnet 10.1.2.3 113" from another pc (where 10.1.2.3 is your own IP) - you should get
"connecting to 10.1.2.3...could not open connection to the host, on port 113: connect failed" pretty much instantly. If it takes a while before failing, or it just times out, you've still got the original problem.

If it works, then you've got a different problem with the ftp server, such as your pc not having a proper reverse dns entry or something (but since turning off the firewall works, it's pretty likely to be ident)

What you could do is turn on full connection logs in the ICF (vista firewall) and see what specifically it drops or rejects when you try to connect to the ftp server. You need to turn on security logging; I'm not in front of a vista pc atm, but I think it should be under Start -> Control Panel -> Administrative Tools -> Windows Firewall with Advanced Security.
posted by ArkhanJG at 12:08 AM on June 3, 2008

Another thought; actually run an ident server on vista! windows ident server is reported as working on vista 32 bit by other sites.
posted by ArkhanJG at 12:13 AM on June 3, 2008

The problem is that the FTP protocol is ancient and not friendly towards NAT based networking. Not to mention the madness of doing IDENT on windows machines.

The fix for this is to tell your FTP app to use Passive Mode. Some details here.
posted by damn dirty ape at 9:27 AM on June 3, 2008

DDA, passive mode had no effect when I tried it just now. Which isn't too surprising; that controls how transfers are handled once authentication is complete, and it is the authentication step where the problem lies.

ArkhanJG, a telnet from another computer as you describe takes a long time to time out, alas. What I fear is that even though the port is open in the firewall now, Vista doesn't send an immediate refuse.

The suggestion to put an IDENT server on my Vista client gives me the willies, but thanks for the idea.
posted by Class Goat at 9:50 AM on June 3, 2008

Whats probably happening is that the server is configured to do active first then drop back to passive after the timeout, thus the delay. The change needs to be server-side as well as client side. What ftp server are you using? Youd also want to disable any ident junk server-side too.
posted by damn dirty ape at 10:47 AM on June 3, 2008

It's ProFTPD 1.2.5 and I don't have any server-side controls for changing its configuration. (Most of my server stuff is controlled by menus; digging into text configuration files and mucking with them also gives me the willies.)

I think I'm just going to have to live with the delay. It's not intolerable, it's just annoying.
posted by Class Goat at 12:08 PM on June 3, 2008

DDA, I don't believe that passive mode is the answer. When I use FTP from a command prompt, the delay happens before I'm prompted to log in. The "active/passive" stuff described on your link is a function of doing transfers after logging in.

It would be interesting to learn that there was an FTP program for Vista which included an Auth server that ran port 113. Anyone know of such a beast?
posted by Class Goat at 12:10 PM on June 3, 2008

Do you lose the delay with the client firewall turned off? If so, port 113 is not the right (or only) port you need turned off.

Try this:
1. Turn the client firewall off (temporarily).
2. Try your FTP connection.
3. If it works, turn your firewall back on.
4. Try your connection again.
5. Look at C:\Windows\System32\LogFiles\Firewall\pfirewall.log and see if you can determine what ports are being blocked.

Hope that helps.
posted by cnc at 1:38 PM on June 3, 2008

The firewall doesn't normally log. I tried going in and turning on every kind of logging I could find, and the resulting log file (at the path you mentioned) didn't show anything useful. The problem is that I don't think it shows external accesses that are blocked, which is what I would have needed to figure out what was going on.
posted by Class Goat at 2:27 PM on June 3, 2008

The likely solution when using proftpd would be to add (or change from on to off) the following lines in proftpd.conf

IdentLookups off
UseReverseDNS off

The config file is usually in /etc/proftpd.conf

If you're unwilling to change that, FTP Rush is a paid for ftp client with free trial that has an ident server built in - would be worth testing.
posted by ArkhanJG at 4:34 AM on June 5, 2008

Also, if you're much happier using GUI interfaces to your configuration files on a linux server, webmin is a great project that allows you to configure pretty much everything, including proftpd, via a web based GUI.
posted by ArkhanJG at 4:47 AM on June 5, 2008