VPN – miqrogroove

OpenVPN tls-auth Option is Critical

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.

The log excerpt looks like a whole lot of these:

Sep  6 12:40:15 vpnserver1[535]: 148.163.126.72:22475 TLS: Initial packet from [AF_INET]148.163.126.72:22475 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:15 vpnserver1[535]: 148.163.126.72:57036 TLS: Initial packet from [AF_INET]148.163.126.72:57036 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:17 vpnserver1[535]: 148.163.126.72:20089 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep  6 12:40:17 vpnserver1[535]: 148.163.126.72:20089 TLS Error: TLS handshake failed
Sep  6 12:40:17 vpnserver1[535]: 148.163.126.72:20089 SIGUSR1[soft,tls-error] received, client-instance restarting
Sep  6 12:40:18 vpnserver1[535]: 148.163.126.72:35987 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep  6 12:40:18 vpnserver1[535]: 148.163.126.72:35987 TLS Error: TLS handshake failed
Sep  6 12:40:18 vpnserver1[535]: 148.163.126.72:35987 SIGUSR1[soft,tls-error] received, client-instance restarting
Sep  6 12:40:19 vpnserver1[535]: 148.163.126.72:55183 TLS: Initial packet from [AF_INET]148.163.126.72:55183 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:19 vpnserver1[535]: 148.163.126.72:12142 TLS: Initial packet from [AF_INET]148.163.126.72:12142 (via [AF_INET]%eth0), sid=6a22eb44 5adb63fe
Sep  6 12:40:20 vpnserver1[535]: 148.163.126.72:50926 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Sep  6 12:40:20 vpnserver1[535]: 148.163.126.72:50926 TLS Error: TLS handshake failed
Sep  6 12:40:20 vpnserver1[535]: 148.163.126.72:50926 SIGUSR1[soft,tls-error] received, client-instance restarting

Continue reading OpenVPN tls-auth Option is Critical

Offline Files Access Denied over VPN

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.

Continue reading Offline Files Access Denied over VPN

How to Secure iPad VPN with Windows L2TP

VPN diagram showing both Windows and iPad remote clients. — Different protocols for different clients.

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.

NAT Traversal could be a major concern for any L2TP implementation, because Microsoft wrote a very technical and rather intimidating knowledge base article called IPSec NAT-T is not recommended for Windows Server 2003 computers that are behind network address translators. If you’ve seen that article, I want to assure you that the Microsoft recommendation is not relevant here.

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.

Continue reading How to Secure iPad VPN with Windows L2TP

Split Tunnel VPN, Part 2

Diagram of the split tunnel VPN configuration that does not require static routing — Updated Split Tunnel Design

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.

Continue reading Split Tunnel VPN, Part 2

How to Secure a Windows VPN with PEAP

Authentication Methods page in the RRAS Remote Access Policy Wizard — Setting up PEAP

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.

Continue reading How to Secure a Windows VPN with PEAP

Windows VPN Keep Alive

Batch file properties window. — Batch Shortcut

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.

Continue reading Windows VPN Keep Alive

Windows VPN Requires NTLMv1

LAN Manager authentication level set to Send NTLMv2 response onlyrefuse LM — Solution Screenshot

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.

Continue reading Windows VPN Requires NTLMv1

Split Tunnel Virtual Private Network

Detailed overview of a split tunnel VPN system. — Split Tunnel VPN is Faster for Multitasking

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.

Continue reading Split Tunnel Virtual Private Network