Soussan DAS Computer Consultants

Our Team
Cool Stuff
KeyholeKeyboardLaptop ComputerComputer Chip

Error 691 When connecting VPN

My client was having problems connecting remotely to their workplace from their new Microsoft Surface Pro 3 running Windows 8.1. The exact error reads:

Error 691: The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.

This worked fine when connecting from Windows XP and Windows 7, but suddenly stopped working when connecting from Windows 8 and 8.1.

Why? Read on for the details, or Click Here to skip the geeky analysis stuff and jump to the answer.

Click Here for Press Release


Sniffing the glue that holds the internet together 

That tag line used to be on the Ethereal download page, which is now called wireshark. Wireshark is a network sniffer - it captures the data flowing across a network and interprets it into easier to read geek speak instead of hard to read network bits. Normal people plug things in and expect them to work. Engineering geeks like analyzing why things don't work and figuring out how to make them work.

Fortunately for my clients, I'm the latter.

Here is the error screen caught with a camera phone:

Error 691

If you have a propeller hat, now is the time to put it on and get the propeller spinning full speed!

How it used to work 

Since it works on other systems, the short distance to diagnosing the problem is often comparing what system "Works Great!" does with system "It Doesn't *&*!@#-ing Work", finding where they diverge, and using that as a pointer to further analysis. So rather than analyze one then the other, I think it will make more sense to compare them side by side.

PPP Sniffing

That isn't an eye chart - it is a thumbnail. Click on it and look at it full screen or scroll around while you read the analysis.

The left side is the sniff that fails, the right side works. The first three packets up top on each trace are the SYN / SYN-ACK/ ACK of a TCP session establishing - 51,52,53 on the left, 30,31,32 on the right.

The two traces are mostly the same, up till the highlighted in yellow on both sides.

When two systems are attempting to establish a VPN tunnel between them, there is a lot of negotiation back and forth. There are different options for how to encrypt, what key lengths, how to authentcate, if we are compressing data or not, ... and two systems need to figure out how each other wants to talk in order to establish how they will interoperate. Incidently, this is a similar process when you type "https://" into your browser, but that is another story.

So that first block on both sides in white background are the same on both traces except for a little bit of negotiation NAK / ACK-ing where I highlighted in yellow.

Then both sides diverge.

On the left, the one that doesn't work, the computer is using PPTP (Point to Point Tunneling Protocol) and attempting to authenticate with the server using TLS EAP (EAP-TLS) which is the Extensible Authentication Protocol and you can read more at the link I provided whereas the right side which will work is "PPP CHAP" which is the Challenge-Handshake Authentication Protocol, also with more info at the link. I marked those packets with red pen marks around them.

I'm not expecting you to read any of those links and you don't need to even understand them or what they mean to you. Other than the evidence that TLS EAP isn't working with this connection and CHAP is working. That is the big difference - Windows 8 disabled CHAP as an allowable authentication mechanism.


Good question. I don't have the answer.

But that is the key difference - Microsoft changed options and left it to users to figure things out.

On the left, the two systems decide they really don't like talking with each other, agree to disagree, and nicely stop talking to each other by saying "Good Bye!" which are the packets with the green highlights 81 through 89.

On the right, the two systems do their CHAP negotiation - packets 54 & 55, I erased the server name and user name from the Info column, and then a 'Success' message appears in packet 57 followed by a whole lot of successful communications over the VPN tunnel.

So what do I do about this?

The fix is trivially easy - once you know the secret!

TLS-EAP doesn't work, CHAP does work. If you skipped here, don't worry - configure the VPN via the VPN Properties page to allow CHAP, which has been disabled by default in Windows 8 and 8.1 on the two screens shown here:

VPN Properties before

Above, "Use Extensible Authentication Protocol (EAP)" was clicked by default. Instead, click on the lower radio button "Allow these protocols":

VPN Properties that work for Windows 8 8.1

Check on the box to allow "Microsoft CHAP Version 2 (MS-CHAP v2)" and hit OK.

Your VPN should connect and work now. 4 or 5 mouse clicks and you should be good again.


If you found this helpful (or not), please send me a brief email -- one line will more than do. If I see people need, want, and / or use this kind of information that will encourage me to keep creating this kind of content. Whereas if I never hear from anyone, then why bother?

I can be reached at:
das (at-sign) dascomputerconsultants (dot) com


David Soussan

(C) 2015 DAS Computer Consultants, LTD.  All Rights Reserved.