Stop draggin’ my port around
Problem: Remote user reports he is unable to connect to shared network drive over PPTP VPN.
Troubleshooting:
- Tried connecting to VPN from my computer. Could not connect. Conclusion: remote user is neither stupid nor crazy.
- Tried to telnet to server over port 1723. Could not connect.
- Checked firewall logs for dropped connections on port 1723. None there.
- Disabled VPN access at firewall. Tried to connect again. Failed again. Checked logs again. Showed dropped connection. Conclusion: firewall is not the problem; when the rule is enabled, it is successfully letting PPTP traffic through.
- Checked status of Routing and Remote Access Service. Looked fine. Restarted service anyway. Still can’t connect to VPN.
- Ran netstat -a on server to see if server was listening for connections on port 1723. It was, but it was in CLOSE_WAIT status. A-ha! Now we’re on to something.
- Ran netstat -b -v -o to see what exactly is using port 1723. Surprise! The executable involved is store.exe, i.e., Microsoft Exchange. What the hell is Exchange doing using port 1723?
- Restarted Exchange Information Store. (Not easy — had to try several times before it successfully stopped.) Ran netstat again after services restarted. Now server not listening on port 1723 at all. Progress, I suppose, but not good enough.
- Restarted RRAS. Still not listening on 1723. Started swearing. Didn’t help.
- Started Blackberry Enterprise Server Dispatcher, Policy, and Synchronization services, which had to be stopped in order to stop Exchange store. Tried VPN again. It works!
Conclusion: I have no idea why Exchange hijacked the VPN port. But I will remember that netstat is my friend.
This gave me an excellent clue to a similar problem here – never had a problem with RRAS here until today port 1723 and 1701 suddenly stop listening. Closed all the Blackberry services down, restarted RRAS – now ports are listening okay – restarted Blackberry – seems to have done the trick.