Search for previous posts

Blog History


Unifi L2TP VPN + Windows 10

This was my 3 day journey figuring out how to get Windows 10 to successfully VPN into the Unifi USG L2TP VPN.

TLDR; No CCP, means no MPPE, means no VPN.

First, my Android and a MacBook connect successfully everytime. It's just my Windows 10 machine that wouldn't connect, no matter how many settings I tried. Here's the list:
  • Verified and reverified PSK, login details, CHAPv2
  • Deleted and re added VPN
  • Registry "AssumeUDPEncapsulationContextOnSendRule"
  • Registry "ProhibitIpSec"
  • Registry "AllowL2TPWeakCrypto"
  • Reinstall WAN miniport drivers
  • Disabled firewall
  • Ran powershell commands for the cipher changes
  • Ran "netsh advfirewall set global ipsec ipsecthroughnat serverandclientbehindnat"
  • Rebooted 5 Million times
  • Reinstalled Windows, TWICE!
Nothing worked. Finally, after combing through the USG log file, I noticed:

USG pppd[11896]: Unsupported protocol 'Compression Control Protocol' (0x80fd) received

After some digging around for CCP information, I stumbled across this post at Superuser, where it was mentioned:
"MPPE is negotiated through the CCP (compression) protocol and not through LCP"
After reading most of RFC1962, there were some tidbits of info:

          Point 2 - CCP Timeouts
"CCP packets may not be exchanged until PPP has reached the Network-Layer Protocol phase.  An implementation should be prepared to wait for Authentication and Link Quality Determination to finish before timing out waiting for a Configure-Ack or other response. It is suggested that an implementation give up only after user intervention or a configurable amount of time....(previous to the above)....CCP packets received before this phase is reached should be silently discarded."

          Point 4 - CCP Configuration Options
"CCP Configuration Options allow negotiation of compression algorithms and their parameters. CCP uses the same Configuration Option format defined for LCP, with a separate set of Options. Configuration Options, in this protocol, indicate algorithms that the receiver is willing or able to use to decompress data sent by the sender. As a result, it is to be expected that systems will offer to accept several algorithms, and negotiate a single one that will be used. There is the possibility of not being able to agree on a compression algorithm. In that case, no compression will be used, and the link will continue to operate without compression."
Obviously, Windows was not going to "continue to operate without compression" so the whole VPN negotiation fails. From the above, it would seem Windows is blasting out CCP packets, and Unifi is just dropping them without waiting long enough for Windows to negotiate another form of compression. Or Windows won't negotiate and just keeps blasting, upon which Unifi gets tired of the game and terminates.

After reading that Microsoft Point-to-Point Encryption is how
"MPPE provides data security for the PPTP connection that is between the VPN client and the VPN server....negotiation of MPPE happens within the CCP." would seem that Windows 10 Edu requires CCP to compress the MPPE data as the client and the server try to negotiate the VPN connection. So no CCP, means no MPPE, means no VPN.

The Superuser poster goes on to say that in


there is a "noccp" entry that you must remove. So I VPN with my OnePlus 3T, launch JuiceSSH, navigate to the file and DELETE noccp. Save. Reboot the USG. Press connect on the Windows machine.....and I'm in!

Not sure if this is Unifi's fault for not allowing CCP or Window's fault for not negotiating another form of compression, or even what the best practice is, but obviously Android and Apple negotiates MPPE VPN connections somehow without CCP. So yeah, there's that.

UPDATE 12/31/18:
So I figured out that if I just go into Windows 10 VPN settings, and press "Clear sign-in info", the VPN will work every time. What is irritating is that I have to re-input my credentials every time, but at least I have a consistent workaround so I can get work done. I assume this is Windows fault, since my Android never has this issue. Par for the course. See screenshot below.

No comments:

Post a Comment