I thought I was going nuts I tell ya. I’d been a Microsoft VPN end-user for years, and had even administered an MS VPN infrastructure back in the dark ages of NT4. I’d used the MS VPN client (aka “Connection Manager”) in all kinds of network environments and under the whole spectrum of security conditions, and I’d never been denied like I was denied this weekend.
Blame it on Windows OneCare I say – no, wait, that’s not fair – can’t blame it on a beta product. Heck, I guess it was my own fault for putting a beta product in production, eh? Live and learn. Hopefully this tale will help you avoid the same hair-pulling foolishness.
So: Windows XP Professional SP2, Toshiba Tecra M2 notebook, MN-700 802.11b/g wireless router, Comcast broadband service. I’d configured the MS VPN client connectoid for default settings, filled in the appropriate authentication details, and couldn’t complete the connection. The client would connect to the VPN server, and would count approx. 33 seconds while attempting to authenticate my credentials, and just kicked me out.
According to all the googl’ing I did, all suggested solutions revolved around configuring port forwarding on my wireless router. I hadn’t had to configure the router’s network settings for a year or so, and I’d had to reset the firmware once this summer, so while I didn’t think this was the problem, I certainly wasn’t sure. I certainly did know for sure that the Windows XP SP2 firewall would allow any outbound communications, and would allow back any responses to requests initiated from the computer, so I really didn’t think about it any further.
I diddled with the router’s configuration a few different ways:
- I tried to find the setting in the Connection Manager software that would allow me to override the automatic protocol selection, but despite my best efforts, it’s been well-hidden by the good folks in our IT department who setup this well-designed end-user configuration.
- I forwarded 1723/tcp, 1723/udp, 1721/tcp, 1721/udp, thinking each time I added one, “Well maybe I’ve just forgotten my protocol settings – I’ll just try one more”.
- I forwarded 500/udp, since one article reminded me that IPSec NAT-T (NAT Traversal) worked over 500/udp.I used dynamic forwarding; I used persistent forwarding (I ifgured dynamic was sufficient, since the router would detect my requests, but after that failed I figured persistent *had* to work. Nope.)
- I finally configure the virtual DMZ to point to my computer’s IP address. I’d avoided it to this point since it would remove most protections the router afforded from my PC, but at this point I was getting desparate.
No dice. That’s when I finally gave in, and despite my better judgment (I’d NEVER had to do this before), disconnected the wireless router and connected the computer directly to the broadband “modem”. When I couldn’t make the connection even then, I knew the problem wasn’t with the port forwarding…
I finally had another look at the Windows Firewall configuration, and this time I really wondered why it continually reported that the firewall was “Off”, even though it also said that “For your security, some settings are controlled by Group Policy”. Did our IT group really disable the Windows Firewall on us through GPO? If so, what was it they were using to secure our systems? I knew I hadn’t installed any third party firewall like BlackIce… [oh hell. That’s right.]
That’s when it finally dawned on me to dig into the Windows OneCare software. Now, when I look at the client, there’s nothing that jumps out at me related to Windows Firewall – the three main blocks of reported info in the main window are “Protection Plus”, “Performance Plus” and “Backup and Restore”. Buried in the middle of the Protection Plus category is a single line simply labelled “Firewall: Auto”, which had until now escaped my attention.
I engaged my brain and chose the “View or change settings” selection, then grabbed the Firewall tab and hit the “Advanced settings…” button. While you can choose either “Program List” or “Ports and Protocols” to enable new exceptions in the OneCare firewall, I knew that there was no typical executable that uniquely identifies the VPN client connectoid, and thus it’d be difficult to nail down an .exe to add to the “Program List”.
Turning to the “Ports and Protocols” list, I finally had a stroke of luck. There appears to be a default configuration already set up for the “GRE” protocol – IP protocol 47, the control channel used by PPTP. I simply added another exception that I named “PPTP”: Protocol TCP, Port range 1723 to 1723, and retried the VPN client.
Of course it went through immediately.
I assume this’ll help any of those of you who are also running the beta of Windows OneCare Live, but I hope this’ll be made easier for folks by the time this releases. I’ll file a bug on this and see if the OneCare Live folks can’t help automate this somehow – if I got tripped up by it, I’m sure there must be others who’ll also be stumped.
Epilogue: I haven’t bothered to check which of the router configurations are still necessary once the OneCare firewall was properly configured. It may be that the DMZ setting is still needed, or perhaps the MN-700 actually does tranparently forward MS VPN traffic correctly (as I’d originally expected). Let’s leave that as an exercise for the class, shall we? Until next time…