What do Microsoft SSTP and SonicWall SSL have in common?

Microsoft SSTP and SonicWall SSL are two completely different protocols, but interestingly enough, they have two important things in common, and those two things are: TLS (also known as SSL) and PPP.

Introduction to PPP

PPP is one of those legacy protocols that just refuses to ever die. Like in the song from Mojo Nixon: "You can’t kill me, I will not die, not now, not ever, no never!"

It has already been extended to be directly used as a VPN protocol with PPTP and was used again as a tunneling protocol by L2TP. What do these two protocols have in common? Microsoft. PPTP was actually a Microsoft idea, and Microsoft was also involved in the development of L2TP. So, when Microsoft introduced a new VPN protocol called SSTP back in 2007, it came as no great surprise to most experts that it was another protocol based on PPP.

How does SSTP work?

The basic idea of SSTP is: rather than modifying PPP to support VPN features like PPTP, and instead of running PPP over IPsec to protect PPP like L2TP, to just run a PPP tunnel over TLS and make PPP an SSL VPN protocol.

Microsoft’s relationship with PPP

So why does Microsoft love PPP so much? Microsoft was not involved in the development of the PPP protocol, but like every operating system manufacturer, it had to add support for this protocol to its products, as PPP soon became the de facto standard for modem dial-up connections and thus the way just about everyone got on the internet.

PPP Authentication protocols

Dissatisfied with the way PPP performed authentication, Microsoft developed a new authentication scheme called MS-CHAP, which was later updated to MS-CHAP v2. The problem with the simple PAP (Password Authentication Protocol) was that passwords were sent in clear text over the PPP connection – a pretty bad idea.

CHAP

The password problem was circumvented by CHAP (Challenge Handshake Authentication Protocol), where the password is never sent directly to the server. However, to authenticate the user, the server still needs to have access to the plaintext password, meaning the plaintext passwords need to be stored somewhere (also not a good idea.)

Ideally, passwords are never stored anywhere – rather hashes of them; however, neither PAP or CHAP can work with hashed passwords. This is the unique advantage of MS-CHAP: Just like CHAP, no passwords are sent, but unlike CHAP, the passwords can be stored on the server in a hashed form. Today, MS-CHAP v2 is the main standard for PPP authentication. PPTP would not be possible without it, and it is used far beyond that.

EAP

Instead of adding new authentication schemes directly to the protocols, a new protocol called EAP (Extensible Authentication Protocol) was created in 2004, and the first protocol to receive EAP support was PPP. Not only does PPP use it, IKEv2 does as well, and guess which authentication scheme was among the first to be added to EAP? It was MS-CHAP v2. In fact, this scheme was even added twice: once as EAP-MSCHAP-V2 by Cisco, because Cisco didn't want to wait until MS-CHAP v2 was supported in EAP, and once as MS-EAP-Authentication by Microsoft itself a bit later. Learn more.

How is EAP used today?

Today, EAP is deeply integrated into Windows as a general authentication protocol that also supports more modern authentication methods, but MS-CHAP v2 is still widely used and is the most common EAP user authentication method in IKEv2.

Microsoft is certainly proud that its authentication scheme is so widely used. Without it, EAP would not have become so popular and PPP would have probably become obsolete by now. Therefore, it's not surprising that they don't want to give up their winning ticket!

SSTP was an attempt to save PPP for at least another decade, and of course MS-CHAP v2 is still the most common option for SSTP connections with username and password authentication – whether in raw form (as a PPP authentication scheme) or via EAP (EAP embedded in PPP).

In particular, once MS-CHAP v2 has been configured for SSTP access, the Windows server can easily fall back to L2TP or even PPTP without having to configure authentication for these protocols, as they can also use MS-CHAP v2 directly or embedded in EAP. One authentication for all.

SonicWall’s relationship with PPP

It is a little surprising that SonicWall has also opted for PPP as the tunneling protocol for its SSL VPN. MS-CHAP or EAP was certainly not the reason for this, as neither is supported. SonicWall's SSL protocol is completely different from SSTP in terms of authentication and configuration provisioning; neither uses PPP for this, although it can do both (except for remote network provisioning).

In fact, the PPP protocol is only used by SonicWall to tunnel traffic after authentication and provisioning have already occurred successfully, but ultimately this is also a PPP tunnel over a TLS connection.

Drawbacks of SonicWall SSL VPN

Unlike Cisco AnyConnect and Fortinet Fortigate SSL, neither SSTP nor SonicWall SSL support an optional datagram tunnel to improve performance. Traffic is always sent over TLS and TLS requires a TCP connection – as we already know, TCP is a poor choice for a VPN protocol, making this probably the biggest drawback of both of these protocols.

SonicWall SSL Alternatives

Microsoft has no plans to change their setup and recommends that professional users opt for IKEv2 over SSTP if maximum performance and low latency are important. SonicWall, on the other hand, seems to be slowly phasing out SSL VPN in favor of using WireGuard® as a transport protocol.

WireGuard VPN certainly has its own issues but SonicWall will not be affected, as they already have their own solution for authentication and configuration provisioning. Moreover, WireGuard is currently unbeatable in terms of raw performance.

How to get better SonicWall VPN performance

Don’t forget: SonicWall continues to offer excellent IPsec support! If you're unhappy with SonicWall's SSL performance, we recommend giving IPsec a try – speed wise it comes in just below WireGuard, but it's stable, reliable, secure and still pretty fast (certainly in comparison to SSL 😉)

VPN Tracker supports the two most important IKE extensions that SonicWALL invented: A modified version of DHCP over IPsec, which we believe is much better than the standardized version, and a proprietary client provisioning protocol called SCP (Simple Client Provisioning.) SCP requires no extra configuration other than the gateway address and the information required for authentication (e.g. username and password, possibly a pre-shared key or certificate). With SCP, client setup is no more difficult than with SSL VPN, but the performance is so much better!