Time Out problem

[newmaster]

I have a five node peer to peer network at my office. Wingate is installed on a NT 4 Workstation machine. I am trying to use the VPN software to access the office network from home. The office network and the remote client at home both access the internet via cable service. The VPN was up and running well until a couple of weeks ago. Now when I try to loggin to the network from home it reports that the remote server has timed out.

I have found little help for troubleshotting this problem. I have reinstalled the Wingate software on my server after downloading the latest version. I have also checked and upgraded the remote client to the latest version of the software. In order to deal with the problem of dynacically assigned IP addresses at the server, I use the dns2go software. The domain name is what the remote client uses, rather than an IP address to find the Wingate server and gateway.

Any suggestions for resolving this problem would be greatly appreciated.

[Pascal]

The connection will time out when the remote machine is not answering the TCP connection request. This can be for several reasons:

1. There is nothing listening on the port you specified. I'd check this first by running an "netstat -a" from the command prompt on the server to ensure that the VPN Server is listening on the port you expect it to.

2. The IP address is incorrect. This could be because of a change in configuration with your dynamic IP to name provider. Try from the client to ping the VPN Server by name, then by the IP you know it to be. If both work, double check the name in the client configuration. Also, you can try to telnet directly to the VPN Control Channel port from the client machine. This should give you an indication if anything is available there on the specified name / IP.

3. The port forwarding is not happening properly. I'm not 100% sure if this will be the case, but it is possible that some intermediary device (Cable setup?) might need to be configured to forward the traffic from one to the other. It 'should' be setup correctly, as you've had it working before, but it might pay to check that it's not something similar to that interfering with it.

[newmaster]

[quote="Pascal"]The connection will time out when the remote machine is not answering the TCP connection request. This can be for several reasons:

1. There is nothing listening on the port you specified. I'd check this first by running an "netstat -a" from the command prompt on the server to ensure that the VPN Server is listening on the port you expect it to.

The results were somewhat lengthy and I really am not aware of what I am looking for. It seems like the port which the VPN uses is 809. If that is correct, what response should I expect when I run that command on the server from the command prompt? Also my DOS is a little rusty, can you advise of the switch or command which will cause the results to be reported to me one screen at a time.

2. The IP address is incorrect. This could be because of a change in configuration with your dynamic IP to name provider. Try from the client to ping the VPN Server by name,

Got positive results when pinging the server from the remote client by name. Results were negative as to the IP address.

then by the IP you know it to be. If both work, double check the name in the client configuration. Also, you can try to telnet directly to the VPN Control Channel port from the client machine.

I will try this tonight with more information about the configuration of the server.

This should give you an indication if anything is available there on the specified name / IP.

]

[Pascal]

"netstat -an | more"

That will pause after a screenfull. You need to check for an entry that says:

0.0.0.0:809 LISTENING

If you're not getting a ping response from the IP though, that's interesting. How is your connection setup on the VPN Client ? Are you connecting by name or by IP ?

While you're running from a command prompt - try the following, please.

nslookup <servername> where <servername> is the name you used to ping. Is the IP address it returns the same as the one you were pingin ?

[newmaster]

"netstat -an | more"

That will pause after a screenfull. You need to check for an entry that says:

0.0.0.0:809 LISTENING

The server is listening on that port.

If you're not getting a ping response from the IP though, that's interesting.

Here at the office I get positve responses to both the name and the IP address. It is possible that last night, from the remote client, I did not put in the correct IP address for the server.

How is your connection setup on the VPN Client ? Are you connecting by name or by IP ?

No, I am using "dns2go", which is installed on the host server. The remote client is configured to contact the server by name and in turn the software will redirect to the appropriate IP address which is dynamically assigned by the cable company.

While you're running from a command prompt - try the following, please.
nslookup <servername> where <servername> is the name you used to ping. Is the IP address it returns the same as the one you were pingin ?

The last two lines of the return show the name and the proper IP address.

Tonight I will ping the server by name and IP again and attempt the telnet session you suggest.

I thank you for your help. The DOS lesson brought back memories.

[newmaster]

I have just tried to connect to the host server from the remote client and it timed out.

I have attempted to ping the host server from a command prompt on the remote client by both name and IP address and got time outs.

I attempted to telnet to the server at port 809 by name and IP address from the remote client and both timed out.

When I left the office I had performed the netstat -a test you asked me to and the server was listening on port 809. The server has that port cinfigured as both the control and data port.

[Pascal]

Alright, so what we know now is that your server is listening on the correct port, name resolution works because it gets the correct IP from the name. However, it does not respond in any shape, size or form.

This would indicate to me that the method you're using to connect to the internet (Server side) has some form of firewall / NAT ability. You mentioned cable - do you know if this is the case ?

If it is - you should open a hole / redirect traffic to your VPN Server. This will need to be done for both UDP and TCP traffic. If your VPN Client goes through the same type of connection (With an intermediary firewall / NATr) then it needs to have the same holes / redirections opened for it.

[newmaster]

I have contacted the solution center of Cableone who provides tha intrnet access at both locations. They advise that they have made no recent changes and are not blocking port 809 in any way.

The only NAT firewall is that created by the Wingate software, there is not a hub or router at either end and no software firewalls are used at any of the nodes on the network in the office.

I look forward to hearing from you as to where we go from here.

[jono659]

I assume the dynamic IP is up to date? I find out here

http://all-nettools.com/

JonO

[newmaster]

I assume the dynamic IP is up to date? I find out here

http://all-nettools.com/

JonO

I am not sure that I understand what you mean. I have checked DNS2Go and am satisfied that it has the current dynamically assigned IP address. All indications are that it is properly re-directing all calls to the domain name to the proper address. Every effort to log in to the host server times out.

[Pascal]

If you look in GateKeeper, under ENS properties. Can you see Port Security actions that shows port 809 TCP and UDP is allowed in ? They should be, but might not be. Short of that, it sounds as if WinGate is doing what I'd expect it to do. It's listening on the correct port, etc. but something external to that is blocking or preventing access to it.

[newmaster]

If you look in GateKeeper, under ENS properties. Can you see Port Security actions that shows port 809 TCP and UDP is allowed in ?

Yes, in Gatekeeper which runs on the host server at my office, under "Connections from the Internet" both TCP and UDP have entries to allow port 809 to be used with default timeout as the "hole for VPN"

They should be, but might not be. Short of that, it sounds as if WinGate is doing what I'd expect it to do. It's listening on the correct port, etc. but something external to that is blocking or preventing access to it.

[genie]

What other software do you have installed on your host machine? From what's been discussed here it looks like something blocks your client to connect or your client tries connecting to the port which the server knows nothing about (like, server listens on port 809 while the client is trying to connect to port 810).

[genie]

Just a thought - what if you change VPN port numbers both on the host and the joiner - say, to 1200 - will it help?

[newmaster]

What other software do you have installed on your host machine?

The host machine is the file server for the office and also receives all faxes via WinFax. It is also the gateway for sharing the our connection to the internet at the office. As far as I am aware, no new software has been installed on the server since the day the any effort to connect to the server from the remote client resulted in timeouts.

From what's been discussed here it looks like something blocks your client to connect or your client tries connecting to the port which the server knows nothing about (like, server listens on port 809 while the client is trying to connect to port 810).

[newmaster]

Just a thought - what if you change VPN port numbers both on the host and the joiner - say, to 1200 - will it help?

Apparently not. Last night I changed the port numbers to 1200 and the remote received a "timeout" message when I tried to connect to the server from the remote client. I made the change any place the old port number, 809, appeared under the "Extended Network Services" settings. I also changed it in the settings for VPN.

[jono659]

Did you find a solution for this yet?

JonO

[newmaster]

No, I haven't. I also think I have almost exhausted the resources which are within my area of expertice. The cable company has checked the line at both ends and confirmed there is a good signal and that they have done nothing to limit access to the ports I need. I have now replaced the cable modem, which is the only other exterior factor I know of which would keep it from working. I have uninstalled and reinstalled Wingate Pro on the host server twice, hoping that if there was a setting error it would restore settings to default which might correct the problem. I have uninstalled and reinstalled the DNS2GO program on the host server which addresses the issue of a non-static IP address.

I have a sense that the answer lies some place in the settings of the machines and am going to go back over all of them and the on line documentation and white papers. What is so frustrating to me is that this was working perfectly for six months and then just decides not to work. I have racked my brain to try and remember any hardware or software change which might have caused this problem and nothing occures to me. Any trouble shooting suggestions would be appreciated.

[newmaster]

There is good news and bad news!

The good news is that the VPN is back up and running!!!!!


The bad news is I am not entirely sure what I did to make it start running again. I uninstalled and re-installed DNS2GO. I also monkeyed with the user database and changed from the NT user database to the Wingate database for authentication. Also I installed a new cable modem yesterday. Probably will never know

Thanks to all for your generosity in responding to my request for help.