What Is PPTP? The VPN Protocol That Was Retired

PPTP (Point-to-Point Tunneling Protocol) is a VPN protocol developed in the mid-1990s by the PPTP Forum.

PPTP was built natively into Windows from Windows NT 4.0 in 1996. From the late 1990s through the 2000s it was the dominant remote-access VPN standard in corporate deployments. Its authentication mechanism has been demonstrably crackable since 2012, its encryption derives from the same broken material, and it provides no data integrity checking or forward secrecy. It is deprecated across every major platform and has no acceptable security use case in 2026.

What PPTP Is

Definition and origin

PPTP is a tunnelling protocol that carries PPP (Point-to-Point Protocol) frames across public IP networks, enabling remote-access VPN connections without requiring third-party client software on the endpoint device. It was developed by the PPTP Forum, a vendor consortium comprising Microsoft, Ascend Communications, 3Com/Primary Access, ECI Telematics, and US Robotics. The specification is documented in RFC 2637, published as an Informational RFC in July 1999. Informational status means PPTP was never an IETF standard. The IESG note within RFC 2637 records that the PPP working group was simultaneously defining L2TP, a Standards Track protocol for tunnelling PPP.

PPTP shipped natively in Windows NT 4.0 in 1996, covering both Server and Workstation editions. It was available to Windows 95 users through the Dial-Up Networking upgrade (DUN 1.3 and later). All Windows versions from Windows 98 onward shipped with it. Because it required no third-party client software, it became the dominant remote-access VPN protocol for corporate deployments from the late 1990s through the 2000s.

PPTP, PPP, PPPoE and PPTP Passthrough

PPP (Point-to-Point Protocol) is the link-layer protocol whose frames PPTP encapsulates. RFC 2637 describes PPTP as “a new vehicle for carrying PPP.” PPP is the payload that PPTP tunnels; it is not itself a VPN or tunnelling mechanism. For VPN fundamentals, see what is a VPN and how does it Work.

PPPoE (Point-to-Point Protocol over Ethernet) carries PPP over Ethernet for ISP broadband access authentication, most commonly on DSL and some fibre connections (RFC 2516, February 1999). It is not a VPN protocol. The name overlap with PPTP is coincidental: both involve PPP, but they serve entirely different purposes.

PPTP Passthrough on a consumer or business router is a NAT accommodation, not a server role. It enables the router to pass PPTP traffic originating from devices behind it by translating GRE Call IDs in the absence of conventional port numbers. On ASUS routers, for example, this setting appears under WAN as “NAT Passthrough.” Enabling it does not mean the router is running a PPTP server; it means the router allows PPTP sessions to transit it.

Layer classification: PPTP is conventionally grouped with L2TP as a Layer 2 tunnelling protocol; both encapsulate PPP frames and carry them across an IP network. This framing reflects the grouping with L2TP, whose name makes the Layer 2 classification explicit, and RFC 2661 §1.0, which describes PPP as a protocol for carrying multi-protocol datagrams over Layer 2 point-to-point links.

Security verdict

PPTP is cryptographically broken. Its authentication protocol is reducible to a single 56-bit DES brute force, its encryption derives from the same broken authentication material, and it provides no data integrity checking or forward secrecy. No patch has been issued for any of these failures; the flaws are structural to the protocol design, not implementation errors. PPTP has no acceptable use case in 2026. For a full protocol landscape and current alternatives, see VPN protocols explained.

How PPTP Works

PPTP splits operation across two parallel channels. That split determines its NAT traversal behaviour, its firewall exposure, and the attack surface it creates.

The dual-channel architecture

Control channel: TCP port 1723. The control channel manages the session lifecycle between the PAC (PPTP Access Concentrator) and the PNS (PPTP Network Server), as defined in RFC 2637 §1.2. (In the dial-up context RFC 2637 was written for, the network access server acts as a PAC and connects to a PNS; in a direct client-to-server VPN deployment, RFC 2637 §1.1 treats the connecting client as the PNS.) The control channel handles session setup, parameter negotiation, call management, and teardown. Connectivity is maintained by Echo-Request (Control Message Type 5) and Echo-Reply (Type 6) keep-alive messages, per RFC 2637 §3.1.4: a peer that receives no control message for 60 seconds sends an Echo-Request, and closes the control connection if no Echo-Reply arrives within a further 60 seconds.

Data channel: Enhanced GRE (IP Protocol 47). User traffic flows over GRE (Generic Routing Encapsulation). PPTP uses an enhanced GRE header defined in RFC 2637 §4.1, extending the GRE format in use at the time (RFC 1701/1702): the Version field is set to 1 and the Protocol Type to 0x880B, the existing Key field is repurposed to carry a payload length and a Call ID, optional sequence numbers (S bit) are available, and the main addition is a new Acknowledgment Number field (A bit) that drives the sliding-window flow-control mechanism. RFC 2637 §4.1 states that the acknowledgment capability “is not used in conjunction with any retransmission of user data packets”; §4.2, titled “Sliding Window Protocol,” defines the flow-control mechanism itself. The sliding window exists for flow and congestion control only; retransmission is not performed by the tunnel peers.

PPTP deployments follow either a client-initiated model, where client software establishes the tunnel directly, or a network-initiated model, where the access infrastructure creates the tunnel on the user’s behalf without requiring VPN client software on the end device. These models are conventionally described as voluntary and compulsory tunnelling in RRAS and L2TP documentation rather than in RFC 2637 itself. For a full treatment, see what is a VPN tunnel.

Packet encapsulation and stack

The complete PPTP packet stack, from outermost to innermost layer: Outer IP Header, Enhanced GRE Header, PPP Header, Encrypted Payload. Per RFC 2637 §4, PPP frames traverse the tunnel stripped of all media-specific framing. The RFC specifies that no HDLC flags, bit insertion, control characters, control character escapes, or CRCs are included. (A CRC alone does not prevent deliberate modification under a stream cipher.)

NAT traversal: the GRE problem

PAT (Port Address Translation), the form of NAT used by nearly every home and small-business router, tracks connections through Layer 4 port numbers. GRE operates on top of IP with no port numbers, which means a PAT device has no mechanism to route returning GRE packets to the correct internal host. Static and dynamic NAT work with PPTP without special accommodation; it is PAT specifically that cannot handle GRE natively.

What consumer routers label “PPTP Passthrough” is, in vendor terminology, a PPTP Application Layer Gateway (ALG). Cisco’s IOS XE NAT documentation describes the mechanism: the PPTP ALG parses PPTP control packets on TCP 1723 and translates GRE Call IDs in place of port numbers, allowing PAT to track individual PPTP sessions across a shared public address.

In Carrier-Grade NAT (CGNAT) environments the problem is compounded. Because GRE carries no port numbers, a CGNAT sharing one public address across many subscribers can only demultiplex returning GRE packets if it translates Call IDs, and support for that varies by implementation. Cisco additionally documents that its PPTP ALG will not operate in CGNAT mode when the client and server select the same Call ID. Consumer-router passthrough does not resolve this, because the breakdown occurs upstream at the carrier’s translation layer.

SSTP was designed to address the NAT and firewall limitations of PPTP and L2TP/IPsec: it runs entirely over TCP port 443, which NAT handles natively without special accommodation.

The firewall problem

PPTP needs both a TCP control connection (port 1723 by default) and a GRE data channel (IP Protocol 47), so blocking either one breaks standard PPTP. Blocking GRE is the more thorough rule: a PPTP server listening on a non-standard control port would get past a port-1723 block, but cannot function without its GRE data channel. Blocking GRE will also block any other GRE-based tunnels on the network. There is no port-443 fallback, no TCP mode, and no obfuscation path.

PPTP’s Security: What Went Wrong

PPTP has five structural design failures, plus a separate record of implementation vulnerabilities. Each design failure is independently sufficient to condemn the protocol. The authentication and encryption failures are not independent in practice: the RFC 3079 key-derivation chain links them directly, so cracking the authentication automatically yields the encryption key. That cascading relationship is what makes PPTP unrecoverable rather than merely outdated.

MS-CHAPv2: the broken authentication layer

MS-CHAPv2 (Microsoft Challenge Handshake Authentication Protocol version 2), specified in RFC 2759, is the authentication method PPTP uses. The protocol’s challenge-response structure contains two compounding structural flaws, both confirmed in Microsoft’s MSRC engineering analysis published alongside Security Advisory 2743314 (August 2012).

MS-CHAPv2 pads the 16-byte NT password hash to 21 bytes and splits the result into three 7-byte DES keys.

• Flaw 1 (K3 zero-padding). The third key (K3) is constructed from only 2 bytes of real key material; the remaining 5 bytes are set to zero. The effective key space is 2¹⁶, brute-forceable in seconds on any modern hardware.
• Flaw 2 (K1/K2 identical plaintext). K1 and K2 independently encrypt the same plaintext block. A single 2⁵⁶ DES search recovers both keys simultaneously.

Combined, the entire MS-CHAPv2 exchange reduces to the strength of a single 56-bit DES encryption.

At DEF CON 20 in July 2012, Moxie Marlinspike, David Hulton of Pico Computing and Marsh Ray presented “Defeating PPTP VPNs and WPA2 Enterprise with MS-CHAPv2.” Hulton designed and built the FPGA cracking hardware that made the attack operationally viable. Marlinspike released chapcrack, an open-source tool (GPLv3) that parses a captured PPTP handshake, extracts the DES challenge-response material, and produces a submission token for the CloudCracker cracking service. Once CloudCracker returned the recovered key, chapcrack decrypted the full packet capture. According to IDG News Service reporting at the time, CloudCracker returned results within 24 hours.

Microsoft issued Security Advisory 2743314 in August 2012. No patch was issued. The recommendation was to tunnel the MS-CHAPv2 exchange inside PEAP, or to migrate away from PPTP. The flaws are structural to RFC 2759’s challenge-response construction: correcting them would require redesigning the authentication protocol.

MPPE/RC4: the broken encryption layer

PPTP encrypts data using MPPE (Microsoft Point-to-Point Encryption), specified in RFC 3078 (Informational, March 2001), with the RC4 stream cipher.

MPPE’s key derivation links the authentication and encryption failures into a single cascade. Per RFC 3079 §3, session keys are derived from the NT password hash via MD4, then combined with the NT-Response field from the MS-CHAPv2 exchange to produce a master key, from which transient session keys and the RC4 key schedule are generated. Every input beyond the password hash is transmitted on the wire during the authentication exchange. Cracking MS-CHAPv2 via chapcrack directly yields the MPPE decryption key. The authentication break and the encryption break are one cascade, not two independent attacks. For what authenticated encryption provides that MPPE does not, see VPN encryption explained.

MPPE is negotiated inside the Compression Control Protocol (CCP option 18), which is why MPPE is sometimes mistaken for a compression scheme.

MPPE supports three key lengths: 40-bit (L-bit flag), 56-bit (M-bit flag), and 128-bit (S-bit flag). RFC 3078’s own introduction states only “40-bit and 128-bit” even though the same document’s option section defines the 56-bit M-bit flag; RFC 3079’s abstract names all three explicitly.

RC4 also carries well-documented statistical biases in its keystream output. The key published analysis is AlFardan, Bernstein, Paterson, Poettering, and Schuldt, “On the Security of RC4 in TLS,” presented at USENIX Security 2013 (Royal Holloway Information Security Group). That paper targeted RC4 as used in TLS (the same team separately applied the biases to WPA/TKIP), not MPPE directly. The IETF found the biases significant enough to prohibit RC4 from TLS via RFC 7465 (February 2015). PPTP depends on a cipher the IETF has ruled unsuitable for secure communications.

No data integrity

PPTP provides no message authentication on the encrypted payload: no MAC, authentication tag, or HMAC. The enhanced GRE header carries sequence and acknowledgment numbers for flow control but no integrity protection. Under RC4, a stream cipher, an attacker who flips bits in the ciphertext can also recalculate and adjust any CRC, since CRCs are linear under XOR, the same property that defeated WEP. RFC 2637 §4 specifies that no CRCs traverse the tunnel. An attacker intercepting PPTP traffic can modify the encrypted payload without detection at the VPN layer. The absence of data integrity checking was documented by Schneier and Mudge in their 1998 cryptanalysis.

Higher-layer checksums such as TCP checksums can detect accidental corruption, but an attacker who deliberately flips bits in the encrypted payload can adjust those checksums as well.

No forward secrecy

PPTP performs no ephemeral key exchange. There is no Diffie-Hellman or elliptic-curve component. MPPE session keys derive entirely from the user’s password material, per RFC 3079. RFC 3079 §5.1 frames its MS-CHAP guidance in terms of password strength and rotation, the only mitigation available when no ephemeral key exchange exists.

The consequence is permanent: every recorded PPTP session that includes its authentication exchange becomes decryptable once the user’s password hash is recovered. For how ephemeral key exchange prevents this, see perfect forward secrecy in VPNs.

Unauthenticated control channel

The TCP 1723 control channel has no authentication or integrity protection. RFC 2637 §§1.4 and 2.1 through 2.16 define no authentication mechanism, integrity verification, or replay protection for control messages. The only per-message check is a fixed Magic Cookie (value 0x1A2B3C4D), described in the RFC as a stream-synchronisation sanity check, not a security mechanism.

Because control messages carry no authentication, an attacker able to inject into the control connection (on-path, or by predicting TCP sequence numbers) can forge a Stop-Control-Connection-Request, which closes the control connection and implicitly clears all active calls (RFC 2637 §2.3). This vulnerability was listed as unaddressed in a 1999 Bugtraq analysis of Microsoft’s PPTP security fixes.

Implementation CVEs

Separate from the protocol design failures, the Windows RRAS PPTP implementation has its own implementation CVEs.

CVE-2022-23270 (“Windows Point-to-Point Tunneling Protocol Remote Code Execution Vulnerability”) carries a CVSS 3.1 base score of 8.1 (High). It is exploitable by an unauthenticated remote attacker via the PPTP control channel on TCP 1723, requiring the attacker to win a race condition. It was patched in the May 2022 Patch Tuesday update. Corelight published a detection package for exploitation of this CVE, keyed on large numbers of PPTP EchoRequests sent to port 1723.

CVE-2022-21972 is a separate remote code execution vulnerability in the RRAS PPTP implementation. It carries the same CVSS 3.1 score of 8.1, the same unauthenticated-attacker attack vector, and the same race-condition exploitation requirement. It was addressed in the same May 2022 patch cycle. Microsoft’s MSRC advisory describes it as triggered by a specially crafted protocol message sent to an RRAS server.

CVE-2003-0213 is a negative-read buffer overflow in ctrlpacket.c in PoPToP, the Linux PPTP server daemon, before version 1.1.4-b3. A supplied length field of 0 or 1 causes the daemon to read an unbounded amount of client data into the packet buffer. The CVE record catalogues its impact as denial of service; CERT/CC’s vulnerability note lists code execution as a possible impact. PoPToP has been at version 1.4.0 for an extended period, with distribution maintainers carrying the frozen upstream tarball forward via compatibility patches.

The two 2022 CVEs and the 2003 CVE represent distinct failure classes: the 2022 vulnerabilities are implementation defects in Microsoft’s PPTP stack; the 2003 vulnerability is a defect in a third-party Linux daemon. Neither class represents a new protocol-level break. The protocol design was already cryptographically broken before any of them were discovered, and Microsoft’s response to the 2012 MS-CHAPv2 demonstration (recommending encapsulation rather than issuing a patch) is consistent with the structural failures not being correctable within PPTP.

The Deprecation Timeline

The industry’s withdrawal of PPTP support spans more than two decades, proceeding from academic cryptanalysis to practical demonstrations and finally formal platform deprecation.

1998. Schneier and Mudge published “Cryptanalysis of Microsoft’s Point-to-Point Tunneling Protocol (PPTP)” at the 5th ACM Conference on Computer and Communications Security. The paper broke PPTP’s authentication (MS-CHAPv1) and documented the absence of data integrity protection. Microsoft responded with Security Bulletin MS98-012 (August 1998), patching several of the reported issues, and followed with MS-CHAPv2 as a replacement authentication protocol.

1999. Schneier, Mudge, and David Wagner published “Cryptanalysis of Microsoft’s PPTP Authentication Extensions (MS-CHAPv2)” at CQRE ’99, extending the analysis to the newly introduced MS-CHAPv2. Microsoft’s 1998 fix addressed the original break; the 1999 analysis of its replacement prompted no comparable response.

2012. Marlinspike, Hulton and Ray presented at DEF CON 20, publishing chapcrack and the CloudCracker pipeline. MS-CHAPv2 moved from theoretically broken to practically crackable within 24 hours on FPGA hardware. Microsoft issued Advisory 2743314 with no patch and recommended PEAP wrapping or migration away from PPTP. Schneier, whose 1998 paper with Mudge had broken the original protocol, wrote that it had been “broken again.”

2016. Apple removed PPTP from iOS 10 (13 September 2016) and macOS Sierra 10.12 (20 September 2016) in a single coordinated release. Apple’s support documentation states that upgrading removes PPTP connections from any VPN profile on the device. Apple’s iOS 10 readiness notes show the same release deprecated RC4 cipher suites and SSLv3 across iOS, macOS, tvOS, and watchOS; RC4 is the cipher PPTP’s encryption layer depends on.

2018. NordVPN withdrew server-side and manual-configuration PPTP support on 1 December 2018.

2021. Android 12, released 4 October 2021, removed PPTP from the native VPN client’s type picker. New PPTP profiles could no longer be created through the built-in interface.

2022. Android 13, released 15 August 2022, removed the legacy VPN stack entirely. Existing PPTP profiles ceased to function. Google published no formal deprecation notice for either Android change; the removal is documented through the Google Issue Tracker (issue 249682648) and a Fortinet technical note showing Android 13 offers only IKEv2 VPN types.

October 2024. Microsoft published “PPTP and L2TP deprecation: A new era of secure connectivity” on the Windows Server News and Best Practices TechCommunity blog, announcing that future versions of Windows RRAS Server will not accept incoming PPTP (or L2TP) connections. Outgoing PPTP client connections from Windows endpoints remain supported. The named replacements are SSTP and IKEv2.

Current status (2026). Windows Server 2025 does not enable PPTP in new RRAS installations by default. In-place upgrades from earlier Server versions retain their existing PPTP configuration, which is why active PPTP servers still exist. ExpressVPN no longer supports PPTP manual configurations; no removal date has been published.

Where PPTP Still Turns Up in 2026

PPTP in 2026 is almost always inherited rather than chosen.

Windows Server in-place upgrades. When an organisation upgrades a Windows Server installation to Windows Server 2025, the existing RRAS configuration is retained. A server that was accepting PPTP connections under Windows Server 2016 or 2019 continues to do so after an in-place upgrade unless PPTP is explicitly disabled. New RRAS installations on Windows Server 2025 do not enable PPTP by default.

Router and firewall firmware. Consumer and business routers built before the major platform removals often include a PPTP server option in their VPN server menu, independent of the PPTP Passthrough toggle. That firmware ships with the PPTP server menu available regardless of whether any client platform still supports PPTP natively.

Mid-migration enterprise networks. A single legacy device or vendor appliance that only negotiates PPTP can hold an entire network’s migration schedule. A typical scenario is an older site-to-site router or a hardware VPN concentrator from the mid-2000s. Until that device is replaced or upgraded, PPTP remains in the network even though every surrounding system has moved on.

The legacy-hardware edge case. “It is the only thing this hardware supports” is a hardware replacement decision, not a security exception. There is no PPTP configuration that addresses the MS-CHAPv2 break. The only mitigation Microsoft documented was tunnelling MS-CHAPv2 inside PEAP, which changes how authentication is protected but leaves the data channel on RC4 with no integrity protection. Legacy hardware that cannot support any current VPN protocol should be decommissioned, not maintained on PPTP.

PPTP vs Modern Protocols

The “Origin / defining spec” row identifies the specification or release that defined each protocol’s current form.

PPTP’s speed reputation and what actually caused it

PPTP has a longstanding reputation for speed. The common explanation, that PPTP is fast because RC4 is cheaper than the ciphers its successors use, does not hold on modern hardware. Crypto++ benchmark tables and the project’s ChaCha20-Poly1305 comparison show RC4 costs roughly as much per byte as a modern vectorised ChaCha20-Poly1305, and AES-GCM with hardware acceleration is several times cheaper than either. RC4’s per-byte cost gives PPTP no meaningful advantage over its successors.

The actual historical advantages of PPTP, documented in Microsoft’s Windows NT 4.0 reference materials and the 1998 O’Reilly guide to VPNs, were different:

• Built into Windows from NT 4.0 at no additional cost.
• Easy to implement: PPTP was integrated with the Remote Access Service already built into Windows NT.
• Multiprotocol tunnelling: PPTP could carry IPX and NetBEUI packets alongside IP, which mattered in corporate networks running legacy Novell or Microsoft network protocols.
• Lower connection costs: PPTP over the public telephone network and the Internet replaced more expensive leased lines and long-distance dial-in for remote access.

None of these advantages apply in 2026. Windows has provided IKEv2 and SSTP natively at no cost. Multiprotocol support is irrelevant on current IP-only networks. PPTP appeared faster than early OpenVPN because early OpenVPN ran entirely in userspace with high context-switch overhead per packet; that gap has narrowed as OpenVPN DCO (Data Channel Offload) moved the data channel into the kernel on supported platforms. Whatever speed PPTP shows today cannot be credited to its cipher being meaningfully cheaper than its successors’.

PPTP vs OpenVPN

OpenVPN was the main open alternative to PPTP from 2001 until the platform removals began: Apple in 2016, Android in 2021–22. On authentication: PPTP uses MS-CHAPv2, reducible to a single 56-bit DES search. OpenVPN uses TLS with certificate-based authentication; no known practical attack exists against well-configured TLS certificate authentication. On encryption: PPTP uses MPPE/RC4 with no integrity checking; the encryption key derives from the broken authentication. OpenVPN uses AES-256-GCM, an AEAD cipher that encrypts and authenticates in a single pass with no separate MAC step. On forward secrecy: PPTP has none; OpenVPN provides it via ECDHE. On firewall traversal: PPTP has no TCP 443 path; OpenVPN on TCP 443 crosses firewalls that block standard VPN ports. On speed: OpenVPN DCO has narrowed what was once a substantial gap in favour of PPTP.

WireGuard is faster than both, has a smaller codebase, and uses a fixed modern cryptographic suite. IKEv2 handles mobile network transitions via MOBIKE and is native to Windows, iOS, and macOS.

What to Use Instead

Use WireGuard for everyday VPN use. It is the fastest mainstream protocol, has the smallest codebase of any current option, and uses a fixed modern cryptographic suite with no negotiation surface.

Use IKEv2/IPsec for mobile use or any scenario where the device switches frequently between networks. The MOBIKE extension maintains the VPN session across network transitions without reconnecting from scratch.

Use SSTP or OpenVPN on TCP port 443 when the network blocks standard VPN ports. SSTP requires no additional software on Windows. OpenVPN on TCP 443 is available on all platforms through provider applications.

For Windows Server RRAS migration from PPTP, use SSTP or IKEv2. Both are named in Microsoft’s October 2024 deprecation announcement as the supported replacements for PPTP on Windows Server.

How to Check For and Remove PPTP

If PPTP is running anywhere in your network, it is almost always because someone inherited it rather than chose it.

Check whether PPTP is in use

Client side (Windows 11). In Windows 11, open Settings, go to Network and internet, then VPN. Select any connection and open its Advanced options to confirm whether its type is PPTP. Any PPTP connection should be migrated. Windows 11 allows PPTP outgoing connections to be configured; the October 2024 deprecation applied only to incoming connections on Windows Server RRAS, not to Windows client machines.

Server side (Windows Server RRAS). Open Server Manager, go to Tools, and open Routing and Remote Access. Expand the VPN server node, right-click Ports, and select Properties. In the Ports Properties window, select WAN Miniport (PPTP) and click Configure. The “Maximum ports” field shows how many incoming PPTP connections the server is configured to accept. If Maximum ports is greater than zero and either “Remote access connections (inbound only)” or “Demand-dial routing connections (inbound and outbound)” is checked, the server is accepting PPTP. Windows Server 2025 disables these by default in new installations; in-place upgrades from earlier versions retain whatever was previously configured.

Router menus. On consumer and business routers, the PPTP server configuration and the PPTP Passthrough toggle are distinct settings. The Passthrough toggle is a NAT feature, typically listed under WAN settings, that allows PPTP traffic to transit the router from devices behind it. The router’s PPTP server role is configured in a separate VPN Server section. Disabling Passthrough does not disable the server role, and vice versa.

Disable PPTP on Windows Server RRAS

To stop Windows Server RRAS from accepting incoming PPTP connections:

1. Open Server Manager, go to Tools, and select Routing and Remote Access.
2. In the RRAS console, expand the server node, right-click Ports, and select Properties.
3. Select WAN Miniport (PPTP) and click Configure.
4. Clear the Remote access connections (inbound only) checkbox and the Demand-dial routing connections (inbound and outbound) checkbox.
5. Click OK to close each dialog, then right-click the server node, select All Tasks, and click Restart to apply the change.

Block PPTP at the network edge

At the perimeter firewall, deny IP Protocol 47 (GRE). This is the more thorough rule than blocking TCP 1723: a PPTP server on a non-standard control port gets past a port-1723 block, but cannot operate without its GRE data channel. Blocking GRE will also block any other GRE-based tunnels on the network; confirm no legitimate GRE tunnels exist before applying the rule.

Denying TCP 1723 alone is sufficient to block standard PPTP deployments where the server uses the default control port. Apply both rules where possible: deny TCP 1723 and deny IP Protocol 47.

If You Have Used PPTP: What to Do Now

PPTP’s most serious property is not that it fails today but that it fails backwards: every recorded session that includes the authentication exchange remains readable to anyone who captured it.

What an attacker who captured the traffic obtained. Anyone who recorded a PPTP session that included the opening MS-CHAPv2 handshake could run the chapcrack tool to extract the DES challenge-response material, submit it to a DES-cracking service such as CloudCracker (2012), and recover the key. With the key recovered, chapcrack decrypts the entire packet capture. The capture must include the opening handshake; a recording of mid-session GRE traffic without the authentication exchange is not sufficient. Because PPTP has no forward secrecy, recordings made years ago are as exposed as recent ones.

The credential blast radius. The MS-CHAPv2 exchange exposes the NT password hash for the account used to authenticate. That hash can be used directly to impersonate the user on services that accept it (a pass-the-hash attack) without cracking the hash itself. It can also be cracked offline to reveal weak plaintext passwords. If that password was reused on other services, those accounts are also at risk. Force a password reset for every account that authenticated over PPTP, regardless of when that was. This is true even if the PPTP server has already been decommissioned.

Does PPTP still hide your IP address? Partially, and conditionally. When a PPTP server is configured to forward traffic to the internet and split tunnelling is not enabled, destination websites see the server’s IP address rather than yours. The tunnel’s routing and NAT functions operate independently of the encryption layer. What broken encryption removes is confidentiality: anyone who captured the traffic can read it. Configured that way, PPTP can defeat basic geographic IP checks. It defeats nothing else against an adversary who has or had access to the traffic path.

Is PPTP better than no VPN? For changing the IP address a destination sees: marginally, and only when the server is configured to forward internet traffic and split tunnelling is not enabled. It also introduces a risk that browsing without a VPN does not: the MS-CHAPv2 exchange exposes the account’s NT hash to anyone who captures the opening handshake. Traffic already protected by TLS stays protected inside the tunnel; what a captured PPTP session exposes is everything else: unencrypted traffic, DNS queries, session metadata, and the credential. For any use case where that matters, PPTP provides no protection.

Frequently Asked Questions

What does PPTP stand for?

PPTP stands for Point-to-Point Tunneling Protocol. The name derives from PPP (Point-to-Point Protocol), the link-layer protocol whose frames PPTP encapsulates and carries across IP networks.

Is PPTP still used in 2026?

Yes, active PPTP servers exist in enterprise environments that have not yet completed migration, in legacy router firmware, and in Windows Server instances that were upgraded in-place from earlier versions. Active use does not indicate safety. The protocol is broken regardless of whether a given deployment has been targeted.

Why was PPTP deprecated?

Microsoft deprecated PPTP on Windows Server in October 2024, citing its known vulnerabilities and the availability of stronger replacements in SSTP and IKEv2. Apple removed it in 2016 and Android removed it by 2022.

Can PPTP be hacked?

Yes. A recorded session that includes the MS-CHAPv2 handshake can be decrypted offline using chapcrack and a DES-cracking service, with no ongoing network access required; because PPTP has no forward secrecy, captures made years ago are as decryptable as recent ones.

Is PPTP faster than WireGuard?

There is no current evidence that it is; WireGuard is the fastest mainstream protocol available. PPTP appeared faster than early OpenVPN implementations because OpenVPN ran in userspace with high context-switch overhead; that gap has narrowed. The conventional explanation that PPTP is fast because RC4 is a cheap cipher does not hold on modern hardware: Crypto++ benchmarks show RC4 costs roughly as much per byte as a modern vectorised ChaCha20-Poly1305, and AES-GCM with hardware acceleration is several times cheaper than either. Whatever speed PPTP shows in older benchmarks cannot be attributed to its cipher being meaningfully cheaper than WireGuard’s. The comparison is also not operationally relevant: PPTP does not provide a secure connection, so throughput figures are irrelevant for any privacy or security use case.

Does PPTP work on Windows 11?

Windows 11 supports outgoing PPTP client connections. A PPTP VPN connection type can be configured in Settings. Microsoft’s October 2024 deprecation applied to incoming connections on Windows Server RRAS, not to outgoing client connections from Windows endpoints. The protocol is cryptographically broken regardless of whether Windows allows its configuration.

What replaced PPTP on Windows?

Microsoft’s October 2024 deprecation announcement named SSTP and IKEv2 as the supported replacements for PPTP on Windows Server RRAS. SSTP is native to Windows and runs over TCP port 443, addressing the firewall traversal problem PPTP lacked. Both are available in Windows Server 2025.

Is PPTP good for streaming?

PPTP provides no privacy or security for any purpose, including streaming. Any current protocol achieves the same IP routing function without exposing the account’s NT hash or leaving recorded traffic readable.

What is the difference between PPTP and L2TP?

Both PPTP and L2TP carry PPP frames, but they differ in architecture and security profile. PPTP uses enhanced GRE as its data transport and bundles authentication (MS-CHAPv2) and encryption (MPPE/RC4) into the protocol itself; both are broken. L2TP provides tunnelling but no encryption; for VPN use it is paired with IPsec (RFC 3193), which supplies encryption, integrity, and key exchange. In Windows and Apple implementations this has typically relied on IKEv1. L2TP/IPsec is cryptographically stronger than PPTP, though it was formally deprecated by Microsoft in the same October 2024 announcement. L2TP was developed by the IETF as the Standards Track successor to PPTP, combining elements of PPTP and Cisco’s L2F into a consolidated specification published as RFC 2661 in August 1999.

Is PPTP the same as PPPoE?

No. PPPoE (Point-to-Point Protocol over Ethernet, RFC 2516) carries PPP over Ethernet for ISP broadband access authentication, most commonly on DSL and some fibre connections. It is not a VPN protocol. Both PPTP and PPPoE involve PPP, but they serve entirely different purposes: PPTP tunnels PPP frames across an IP network to create a VPN connection; PPPoE carries PPP frames across an Ethernet link so an ISP can authenticate a subscriber.

What are the advantages and disadvantages of PPTP?

PPTP’s historical advantages (built into Windows, no client install, easy configuration) are now obsolete; current alternatives are natively available on every platform at no cost. Its technical weaknesses are: MS-CHAPv2 authentication is reducible to a single 56-bit DES brute force; MPPE/RC4 encryption derives from the authentication and fails with it; there is no message authentication on the encrypted payload; there is no forward secrecy; GRE-based transport is blocked by a single firewall rule with no fallback path; the protocol is deprecated across every major platform.

WireGuard, IKEv2, SSTP, and OpenVPN are available on every current platform at no cost and carry none of PPTP’s vulnerabilities. There is no case for running PPTP.