Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I have a Windows 2003 Server that acts as a file, FTP, DNS and VPN server for a small (<10 user) company.

Periodically, remote users cannot connect to it via VPN or FTP. However when this happens it is still possible to connect to these services from within the local network and no other problems are reported by users locally.

I have enabled logging for the VPN connections. The log shows the 'internal' connections being made but nothing for the remote ones - not even a 'failed' login.

We also have 2 other servers for a website and email. These remain remotely accessible when we are having the problem.

To permit VPN / FTP connections, we have to reboot the server.

So, the server is running at all times and providing the services, the net connection and router are up and running fine. The only way back is to reboot the server.

Any clues ?

Thanks

PG

share|improve this question
    
Are there any entries in the System/Application event logs at all pertaining to this? –  Mike Fiedler Jun 3 '09 at 14:10
    
No - nothing in any of the event logs. Its almost as if the server was selectively ignoring packets from the router –  Anonymous Jun 3 '09 at 15:42
add comment

5 Answers

When you experience the problem again, try to reach the Internet from the server, by PINGing some Internet address and/or using Internet Explorer. So you can see if the problem is caused by the server losing (somewhat) Internet access, so becoming unable to respond to incoming requests, or specifically by the services it's providing.

Also, try restarting the Routing and Remote Access Service, instead of rebooting the whole servers, and see if this resolves it.

BTW, what service pack level is the server? Is it up-to-date with the latest patches?

share|improve this answer
add comment

I would venture to guess that your router does not fully support VPN passthrough. This happens with most free "business class" routers that ISPs hand out. We had the exact same problem until we took the router out of the equation. We had extra static IPs laying around so we put one on our exchange/vpn server and turned off all port forwarding and stuff for those services. We then installed a firewall on that server and blocked everything but the ports needed for exchange (webmail) and VPN connections to routing and remote access. We haven't had an issues in this configuration.

share|improve this answer
add comment

What do you exactly mean by "remote" and "local"? Are remote users connecting from another network segment or from the Internet? Are they connecting through a router/firewall/NAT?

If you mean "users connecting from the Internet can't reach the server while LAN users keep connecting happily", then it probably is a problem with your Internet connection, or your router/firewall/NAT, whatever it is; if the problem was on the server itself, local users wouldn't be able to connect.

How is the server connected? How many network interfaces does it have? What is it connected to (LAN/Internet)?

Are you running Windows Firewall, or any other software firewall (including the RRAS one), on the server?

share|improve this answer
    
Remote users are connecting via the internet, local users are on the same LAN. We have a router that is configured to port-forward ports to specific IP addresses, so port 1723 goes to 10.0.0.220, 80 goes to 10.0.0.222, 110 goes to 10.0.0.100 etc. At all times, port 80 and port 110 are accessible on the net so I don't see how it can be internet / router related. It is solved by rebooting the server not the router. Server has a single network card assigned 2 IP addresses (10.0.0.220 / 221) connected to our LAN. Router is also connected to the LAN. Not knowingly running a firewall on server. –  Anonymous Jun 3 '09 at 13:45
add comment

Could the fault be name resolution? Do you have both internal and external name servers with the same zone in a "split-brain" DNS?

Your VPN clients probably booted on an external network with differnt DNS servers, you might find that even after the VPN is established that they can't find the internal hosts due to some cached lookup. It doesn't explain why rebooting the server fixes the fault though.

The answer will probably lie in packet capture on the clients, at the time they experience the fault, which is almost impossible for a sysadmin to predict.

share|improve this answer
add comment

For info, after much messing around with Windows, I eventually replaced the Windows server with a Linux (Ubuntu) server. After 8 weeks, it has not missed a beat. Obviously something wrong with the Windows machine, but life is too short to try and fix it.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.