Someone attempted a very noisy attack against my router’s built-in OpenVPN server today. While there was no chance this person could guess my encryption parameters to gain access, he or she did manage to cause a denial of service.
I just tried taking a Windows 10 laptop on the road for the first time. Everything was great until I tried the VPN for the first time. Suddenly, I was getting Access Denied errors, and “You do not have permissions” errors for all files made available offline. I confirmed the VPN tunnel and even browsed to other shared folders on the same server. The offline files errors persisted after dropping the VPN.
When I returned to the domain Wi Fi, file synchronization completed normally and there were no errors at all.
Am I to believe that Windows 10 is completely incompatible with VPN synchronization? I never had a problem with this on Windows XP, and I am dreading the months of research and experimentation normally involved in fixing this kind of Microsoft failure.
Back in August, I mentioned the importance of disabling most versions of PPTP for security reasons, and included my own tutorial for How to Secure a Windows VPN with PEAP. That solution works great for Windows, but is not compatible with iPads.
Now I will offer a solution that works great for iPad, but may not work on Windows computers. In addition, I will explain how to get the two solutions to work together securely so that both Windows and iPad computers will be able to connect to a Windows VPN simultaneously without using the insecure versions of PPTP.
The Layer 2 Tunneling Protocol (L2TP) is an obvious choice for the iPad because it is the only supported protocol other than the insecure PPTP option. On the server side, however, there are some implementation nuances that could easily discourage the use of L2TP. I took the time to research L2TP in more depth before writing this article, because I felt that a generic recommendation could leave readers totally confused about the security issues involved. So before delving into a new tutorial, I want to explain two new concepts: L2TP Pre-Shared Key, and L2TP NAT Traversal.
A careful reading of the Microsoft recommendation against NAT-T will reveal that the underlying security problem with NAT-T is not a server problem but a client problem. In other words, Microsoft recommends that Windows XP computers not attempt to use NAT-T to connect to privately-addressed servers. The Windows 2003 server itself fully supports NAT-T out of the box and doesn’t even need to be configured to use it. This is perfect for iPad users, because iPad also supports NAT-T out of the box, and this almost eliminates the address translation challenges of using L2TP.
Two years ago, I devised a Windows XP split tunneling solution that involved static routing. That solution had the advantage of being cheap, but also had the disadvantage of scaling poorly with any number of client computers.
Now I have a second solution that eliminates the static routing problems.
While researching new VPN security issues recently, I came across an obscure piece of information about the Windows VPN client. It is nestled cryptically in this one sentence from a Microsoft whitepaper:
When the Use default gateway on remote network check box is cleared, a default route is not created, however, a route corresponding to the Internet address class of the assigned IP address is created.
Absent any other explanation, that sentence requires some mental gymnastics to understand. Allow me to help with this.
In light of last month’s announcement by Moxie Marlinspike and David Hulton that they developed a method for decrypting Windows VPN traffic in under 24 hours, it is now important to stop using MS-CHAPv2 as a means of authenticating VPN passwords.
There is a relatively simple fix for this. Microsoft VPN servers have the ability to authenticate passwords using another protocol called PEAP, also known as PEAP-EAP-MSCHAPv2. The only reason one might avoid using PEAP in the first place is that the Microsoft documentation is confusing and describes a requirement for Public Key Infrastructure (PKI) deployment. The PKI as described in Deploying Remote Access VPNs requires anywhere from one to three servers just to issue certificates. However, it only specifies the PKI requirement for a slightly different protocol called EAP-TLS.
To be clear, PEAP does not require a full-blown PKI or even an internal Certificate Authority. You can, in fact, use the same certificate that has been, or would be, issued to a web server for SSL encryption. There is no reason to add a second certificate just for a VPN server. This also means there is no investment required in PKI if a free certificate issuer is used, such as startssl.com.
Below is a brief tutorial for configuring an existing RRAS installation with PEAP-MS-CHAPv2.
I enjoy the one-click facility for connecting to my VPN in Windows XP. It gets the job done, but I sometimes struggle with the famous dead connection bug. This is a very common problem in Windows that causes the VPN to become unresponsive after two to five minutes of inactivity, even though the status still says “Connected.”
I created a one-click solution for both connecting and maintaining a VPN. Setting it up is simple. It involves just these steps, which I will explain below:
Set the VPN “idle time before hanging up” period to “5 minutes” instead of “never.” This forces Windows to properly reflect any disconnection.
Create a new batch file, which I have provided below.
Edit the batch file to match the name and address of your connection.
Create a desktop shortcut to the batch file.
Edit the shortcut properties so that the batch automatically runs minimized with a nice icon.
I’ve stumbled upon a seemingly undocumented authentication error in the Windows VPN system.
Error 691: Access was denied because the username and/or password was invalid on the domain.
This can be caused simply by elevating the VPN server’s LM authentication level to 5, which refuses the NTLM protocol. According to KB823659 requiring NTLMv2 should not break Windows XP connections unless older systems are involved. However, this configuration does cause client and server authentication errors.
Anyone who has attempted a Virtual Private Network (VPN) connection in Windows XP has run into this problem: You want to have access to computers at your home or office, but Windows accomplishes this by routing all of your activity to the home network. If your work involves transferring files to a server and surfing the Internet, then your Internet activity has to piggyback on the VPN and travel twice within your limited home bandwidth. This means your slow VPN is even slower when you load a website, and any interruption of the VPN will break all of your connections to FTP sites, IM services, etc.
You may have tried to coerce Windows into routing your traffic to two different gateways, but quickly realized it wasn’t designed to do that. Adding entries to the local routing table can solve the problem temporarily, but doing so requires administrative privileges and ugly dynamic logic to handle a gateway address that changes every time you connect the VPN.
My solution for this scenario comes in two parts: 1. A static address for the VPN client computer, and 2. A persistent route for the VPN client’s static address. This is a bit easier said than done, so the following tutorial includes screenshots and details.