Link to home
Start Free TrialLog in
Avatar of boxoffrogs
boxoffrogs

asked on

SBS 2003 Anonymous FTP Issues - "This is a private system - No anonymous login" "Connection closed by remote host."

Dear all, as some of you are aware, I am new to Windows SBS 2003, see here http://www-new.experts-exchange.com/questions/22106670/problems-trouble-joining-a-2003-business-server-domain-for-the-first-time-brand-new-server-just-out-of-the-box.html?qid=22106670&anchorAnswerId=18219200#a18219200 .

Now that we appear to have all our DNS woes out of the way, and all clients are connected to the domain, we currently have one drawback. Using passive FTP.

I should state now that the company I work for is an agent for a delivery network (think franchise, but slighlty different).  As such we have no choice but to use their bespoke software.  One of the major parts, in this case, is an FTP Client, which uses passive FTP.

It would appear that we can log in via the SBS server, but every time we try to log in on a client, we get the following...

ftp> open [censored for security reasons]
connected to [censored for security reasons]
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 31 of 200 allowed.
220-Local time is now 06:53. Server port: 21.
220-This is a private system - No anonymous login
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 2 minutes of inactivity.
User ([censored for security reasons]:(none)): [censored]
Connection closed by remote host.

Just in case you are not sure, the setup is NET -> Router -> SBS -> Switch -> Clients

We have enable FTP (Port 21) in the additional firewall settings when running the CEICW, and we also created and added Port 20 (TCP).  From speaking to the tech support guys in our network, who unfortunately have no experience of SBS 2003's firewall, it looks like I may also need to open some ports for the random FTP response.  Looking here http://www.newagedigital.com/cgi-bin/newagedigital/articles/ms-firewall-ftp.html I note that they are in the 1024-65535 range.  Thats a lot of ports.

The problem is, and I may well be being blind here, that I cannot find any other way of configuring the firewall other than in the CEICW.  And if that IS the route to take, I am not exactly sure what additional ports other than 20 and 21 I should add.

We did try to follow the instructions at http://www.newagedigital.com/cgi-bin/newagedigital/articles/ms-firewall-ftp.html but fell over at:

Type the following command where the range is specified in "..". cscript.exe adsutil.vbs set /MSFTPSVC/PassivePortRange "5001-5201"

... with the error:

Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

The path requested could not be found.
ErrNumber: -2147024893 (0x80070003)
Error Trying To Get the Object: MSFTPSVC

But I am not sure that that is the right thing to do anyway, as everything I am currently coming accross appears to indicate connecting to an FTP site ON the server, from the outside world.  We just need to be able to connect to and FTP site IN the outside world.

If there is anymore information required, ie output of specific files or logs please let me know and I will provide them ASAP.
Avatar of Olaf De Ceuster
Olaf De Ceuster
Flag of Australia image

Does your SBS has the following registry key?
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msftpsvc\Parameters\EnableDataConnTo3rdIP
Needs to be set to enabled or in other words set to 1. You can add it as DWORD
OlafDC

Avatar of boxoffrogs
boxoffrogs

ASKER

No, that registry entry does not exist.  More to the point, there is no Msftpsvc directory in CurrentControlSet.

I don't know if it makes any difference, I don't think I have mentioned it before.  We are running SBS 2003 SP1 Standard, but we are NOT using ISA.

As the entry does not exist, I am loathed to create an entire directory.  I think that it would be there so maybe there is something else I am missing.
addendum - From mis-reading I should advise that contrary to my previous statement we are using SBS 2003 R2 Standard, Not SP1.  Still no ISA though.
Sorry I didn't read this properly. Correct me if I am wrong.
Server can access FTP, but not clients. IF that's the case did you check the firewall setting on the clients?
If you used the connect computer wizard this should be set automatically but check it anyway.
OlafDC
Also make sure that DNS points to your server IP  under the TCP/IP properties for your lan card.
Control Panel>Network Connections>Local Area Connection>Properties> General>Tick : Use the following DNS Server address and type your server IP in the preferred DNS server.
Yes, you are correct.  Server can connect, but clients cannot.

As far as the client firewall settings are concerned, only one client is XP and therefore (to my knowledge) has the windows firewall.  the rest are Win 2kPro.

I understand what you say about the DNS, however in my very first question on the subject of Windows SBS http://www-new.experts-exchange.com/questions/22106670/problems-trouble-joining-a-2003-business-server-domain-for-the-first-time-brand-new-server-just-out-of-the-box.html?qid=22106670&anchorAnswerId=18219200you#a18219200you will note that we had significant problems due to our ham-fisted attempts to get it set up originally.  Once i followed TechSoEasy's guide to the letter we got it up and running.  So right now, while it may be down to DNS, I am loathed to manually set anything (as they are all set to DHCP) and the normal internet works fine on all machines.  Surely, if the DNS was broke, I would lose http as well as ftp?

i checked the Windows Firewall on the XP machine, and even added exceptions for ports 20 & 21, but still it does not work.

The client machines are running Norton Internet Security 2006, but I have disabled that and still cannot connect on the client machines.
You can't harm anything by making you primary DNS the server IP at workstation level. This is the way it should be configured. You can always change it again. Jeff I am sure would agree.
FTP and HTTP are two diffrent protocols and both use DNS.
If it makes you feel better wait for Jeff to come on line and see what he thinks.
OlafDc
Well I tried changing the primary dns on 1 of the workstations to point to 192.168.16.2 instead of being DHCP.

It didn't work, so I set it back to DHCP.
OK, IE was set with

Enable folder view for FTP sites - Enabled
Use Passive FTP - Enabled

I Disabled both, apply the changes and testing inbetween.  I then Re-Enabled Use Passive FTP.

But still the connection gets closed.  The server meanwhile is working fine.
Update.

This may not be just Passive FTP.

We have wiseFTP installed on one of our machines, and that cannot connect ineither active OR passive mode (it tries active first by default).

I am sorry if I have led anybody on a bit of a wild-goose chase regarding the passive side of thing, but the fact still remains that we are unable to use FTP on ANY client machine, but it appears to work fine on the SBS.
Avatar of Jeffrey Kane - TechSoEasy
boxoffrogs,

When you say you changed the primary DNS of your workstations to use 192.168.16.2 instead of DHCP, what do you mean?  Because DHCP should be providing them with 192.168.16.2 anyhow.

Do you not have DHCP running from your SBS?

As far as opening ports, you should not have to do that because you are going out on port 21, or 20 perhaps, but the request to open a higher port is automatic because you initiated the transaction.  However, there are some issues with using ports above 5000 with regards to buffer space.  You didn't mention the specific error generated when the connection dropped, but take a look at this anyhow:
http://support.microsoft.com/kb/196271

You can also review this page for full info on FTP:
http://support.microsoft.com/kb/283679

However, I would suspect that perhaps your workstations were not joined to the network using ConnectComputer as I had instructed in your previous question.  If they were not joined in this manner, but instead you manually joined them using the Change Computer Name tab of the systems properties, you need to fix the problem by following these steps:


At the client machine:
1.  Log in with THAT machine's LOCAL administrator account.
2.  Unjoin the domain into a WORKGROUP
3.  Change the name of the computer (this is not an option, you must use a name that is unique and hasn't been used before on your SBS)
4.  Delete or rename the following directory C:\Program Files\Microsoft Windows Small Business Server\Clients if it exists
5.  Make sure that the network settings are configured to get an IP address automatically (DHCP enabled)
6.  Reboot

Then on the server, from the Server Management Console:
1.  Remove the client computers if it still shows in the Client Computer screen on the Server Management Console
2.  Add the client with it's NEW name using the Add Computer wizard

Then, go back to the client machine, log back in with the local Administrator account and join the domain by opening Internet Explorer and navigating to http://<servername>/connectcomputer

Jeff
TechSoEasy
Hi TSE.

Regarding the DNS - The primary DNS server IS being automaticallt allocated by DHCP from the SBS.  I was responding to Olafdc who instructed me to manually point to the DNS server

quote: "Also make sure that DNS points to your server IP  under the TCP/IP properties for your lan card.
Control Panel>Network Connections>Local Area Connection>Properties> General>Tick : Use the following DNS Server address and type your server IP in the preferred DNS server."

I did query this with him as I had followed your steps religiously to reconnect everything and get it working, to which he replied

quote: "You can't harm anything by making you primary DNS the server IP at workstation level. This is the way it should be configured. You can always change it again. Jeff I am sure would agree.
FTP and HTTP are two diffrent protocols and both use DNS.
If it makes you feel better wait for Jeff to come on line and see what he thinks."

When I said it didn't work, I meant it didn't change anything.  I could still access the internet on that client, but the FTP was still unavailable.
====================================================================================

As far as the error goes, I posted what I had in the very original question.  If there is a log file I should be looking at, please point me to it, in the mean time

quote: "...but every time we try to log in on a client, we get the following...

ftp> open [censored for security reasons]
connected to [censored for security reasons]
220---------- Welcome to Pure-FTPd [privsep] [TLS] ----------
220-You are user number 31 of 200 allowed.
220-Local time is now 06:53. Server port: 21.
220-This is a private system - No anonymous login
220-IPv6 connections are also welcome on this server.
220 You will be disconnected after 2 minutes of inactivity.
User ([censored for security reasons]:(none)): [censored]
Connection closed by remote host."

The above, if you hadn't guessed, was using the command promp.  This method is successful on the server, but the moment we enter the username to log on to the FTP site we get "Connection closed by remote host".  To my knowledge, I am NOT receiving the error "'WSAENOBUFS (10055)" but I will keep that in mind.  I will look for and NBSD logs, is there a pointer to where I might find them?

I didn't realise that using the command line was an active connection until reading that second article - my bad.

And just to confirm, I most definately DID follow your advice and all 6 workstations (1 XP 5 2k) were joined by using http://ROADLINK-SERVER/ConnectComputer - All join successfully, migrating the previous user configurations fairly well.  There is one machine where the user files played up, but that is another matter, and is not critical to the running of the network.

Jeff I really do appreciate your help on this, many thanks.
OK.  I think I have solved this one now.  I will leave the question open for a few more days to be certain, but in the mean time....

NB: I found these instructions on another forum, they had been posted by an anonymous user, pointing towards a google group with an identical post in it.  Anyway, the rest of the group looked inappropriate, so I will not post a link.

but here is what was suggested.

On the Server, go to...

Start -> Control Panel -> Administrative Tools -> Services

Right Click on "Application Layer Gateway Service" and select restart.

The moment I did this, FTP on the client machines started to work.

Jeff, I would appreciate your opinion on to why this might have needed to be done.

Many thanks.
No problem... glad you got it settled.  The issue is (and I'm sorry I didn't catch it sooner) that you first attempted Active FTP instead of PASV FTP which throws a little wrench into XP's Firewall.  

For further information, please see this article,  http://technet2.microsoft.com/WindowsServer/en/library/3ccb6af5-d960-4a8d-b12b-70692dc47bf41033.mspx#BKMK_dependencies

Jeff
TechSoEasy
Addendum - it having re-started the server to check if we would have to re- restart the service, we found that we did indeed have to follow the above procedure again.  This time we changed the enabling of the service from manual to automatic in addition to restarting the service.

After the following re-start of the server ... we still had to re-restart this service.

It seems that whatever else happens, for a client to be able to use FTP of any kind, the ALGS has to be restarted every time thhe server is restarted.

This in itself is annoying, once the server is fully configured, it should rarely have any downtime.  but with that in mind, we don't want to have to do extra jobs every time we restart the system.

Short of getting some kind of script to restart the service for us, which is probably a bad idea anyway, how do we get this sorted?
It's true that once you have your server all settled it will rarely need to be rebooted.  However, you may want to implement a script to run when the server is rebooted to just reboot all of the clients.  That, in effect, would restart the service.

You'll find a sample of this kind of script here:  http://mcpmag.com/columns/article.asp?EditorialsID=692

Jeff
TechSoEasy
I will have a good look at that script.

Whilst it may be the only solution available, would it not be possible to create a script that just restarts ALGS?  I am not overly sure about resetting the whole network in one go, thats all.
OK, for the time being I think I will settle on the following approach unless there is something that I have overlooked.

I know the link to the script you posted was an example, unfortunately I do not have enough VB knowlegde to change anything other than was mentioned in commented out lines.  Reading through some of the comments left, the fact it would fall down without error at a workstation that was already shut down also put me off.

So with that in mind, I have gone for the following method.  A simple, old fashioned, batch file with the following commands

REM - This line STOPS the Application Layer Gateway Service
NET STOP ALG
@ECHO OFF
REM - This line waits for 10 seconds before continuing
CHOICE /T 10 /C yn /N /D y
ECHO ON
REM - This line STARTS the Application Layer Gateway Service
NET START ALG

this batch file is set to start automatically under the main administrative account.  I know this means that someone will have to log into that account first, but that is the way we have chosen to go for now.

once we are completely sorted, we will consider getting it to run before login by adding to the AutoExNT
NB - taken out the delay after having realised it was not needed.

REM - This line STOPS the Application Layer Gateway Service
NET STOP ALG
REM - This line STARTS the Application Layer Gateway Service
NET START ALG
ASKER CERTIFIED SOLUTION
Avatar of Jeffrey Kane - TechSoEasy
Jeffrey Kane - TechSoEasy
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Many thanks.

Sorry for the delay in replying.