Fact-checked by Grok 2 weeks ago

Point-to-Point Tunneling Protocol

The Point-to-Point Tunneling Protocol (PPTP) is an extension to the (PPP) that encapsulates PPP frames into datagrams, allowing PPP connections to be tunneled over -based networks to create virtual private networks (VPNs) for remote access. Developed in the mid-1990s, PPTP was first introduced by in Server 4.0 in 1996 as a method to enable secure multiprotocol VPNs across the without requiring dedicated lines. It operates at the (Layer 2 of the ), separating network access server (NAS) functions into a PPP Access Concentrator (PAC) for physical and link control, and a PPP Network Server (PNS) for and , supporting many-to-many relationships between endpoints. The protocol establishes a control channel over port 1723 for session management and uses (GRE, IP protocol 47) with enhancements for sequencing, acknowledgment, and flow control via a sliding window mechanism to carry encapsulated PPP packets. PPTP was jointly developed by a including Corporation, Ascend Communications, 3Com Corporation (U.S. Robotics), and Copper Mountain Networks, with the specification published as RFC 2637 in July 1999 by the (IETF) as an informational document rather than a standards-track protocol. This status reflected its vendor-driven origins and positioned (L2TP) as the preferred IETF alternative for similar functionality. Key features include support for non-IP protocols like IPX and NetBEUI, dynamic assignment, and compression, with a (MTU) of 1532 octets for user data packets excluding headers. Early adoption was widespread due to built-in support in Microsoft operating systems and ease of configuration across platforms, making it a for dial-up and early VPNs in enterprise and home environments. Security in PPTP relies on underlying PPP mechanisms for authentication (e.g., PAP, CHAP, MS-CHAP) and encryption via Microsoft Point-to-Point Encryption (MPPE), which uses RSA RC4 with 40-bit or 128-bit keys as specified in RFC 3078; however, the GRE data tunnel itself provides no native cryptographic protection. Despite initial intentions to deliver security comparable to traditional VPN products, PPTP has been found vulnerable to serious flaws, including weak key derivation in MS-CHAP versions, susceptibility to brute-force attacks, man-in-the-middle exploits, and known plaintext attacks on its encryption, as detailed in cryptographic analyses from the late 1990s. These issues, combined with non-compliance to modern standards like FIPS 140-2/3 and challenges with Network Address Translation (NAT) traversal due to GRE, have led to its deprecation; U.S. Department of Defense security technical implementation guides explicitly prohibit PPTP in favor of protocols like IPsec. Today, PPTP is largely legacy, with recommendations to migrate to more secure options such as IPsec VPNs or TLS-based tunnels for protecting sensitive data; as of 2024, Microsoft has deprecated PPTP in future Windows Server versions, and it lacks native support in recent iOS and macOS releases.

History and Standardization

Development Origins

The Point-to-Point Tunneling Protocol (PPTP) was conceived in as a Microsoft-led initiative aimed at enabling virtual private networks (VPNs) over the public . This effort involved collaboration with several key industry partners through the PPTP Forum, including Ascend Communications, (incorporating Primary Access Point technology), ECI Telematics, and . These companies contributed expertise in and remote access solutions, pooling resources to develop a standardized approach that leveraged existing . The primary motivation for PPTP's development was to provide cost-effective remote access for corporate users, allowing secure connections to enterprise networks without the need for dedicated leased lines or additional hardware investments. At the time, businesses sought to extend dial-up capabilities over networks, building on the established (PPP) as the foundational mechanism for tunneling data. By encapsulating PPP frames within IP packets, PPTP addressed the growing demand for extensions across the , enabling remote workers to access internal resources as if connected directly to the local area network. Microsoft publicly announced PPTP in March 1996, alongside its partners, and released initial prototypes integrated into Server 4.0 later that year to support server-side functionality. Client-side support followed in 1997 through updates to Dial-Up Networking for and Workstation 4.0, allowing users to establish PPTP connections via standard modem or TCP/IP links. Early adoption of PPTP was propelled by corporate needs for secure extensions of dial-up remote over emerging IP-based internetworks, particularly in environments where traditional leased-line VPNs were prohibitively expensive. Enterprises quickly implemented PPTP to facilitate telecommuting and connectivity, capitalizing on its with existing PPP-based modems and routers from forum members.

RFC and Specifications

RFC 2637, titled "Point-to-Point Tunneling Protocol (PPTP)," was published in July 1999 as an informational document by the (IETF), authored by representatives from Corporation, Ascend Communications, Corporation, Copper Mountain Networks, and ECI . This specification defines PPTP as a protocol enabling the encapsulation and tunneling of (PPP) frames over (IP) networks in a client-server . The RFC outlines PPTP's core mechanisms, including a TCP-based control channel for session establishment, management, and teardown, as well as (GRE) for transporting tunneled data packets. It aims to deliver security and remote access capabilities comparable to contemporary (VPN) solutions, relying on for authentication and optional encryption of payload data. Despite its detailed specification, RFC 2637 did not advance to IETF standards-track status and remains informational, primarily due to security vulnerabilities identified during review, such as weaknesses in and that were publicly analyzed in 1998. In response, the IETF's Point-to-Point Protocol Extensions Working Group prioritized the development of (L2TP) as a more robust standards-track alternative. PPTP incorporates extensions from related PPP specifications, including the (CHAP) in RFC 1994 for peer authentication and Microsoft Point-to-Point Encryption (MPPE) in RFC 3078 for data confidentiality, but these integrations lack IETF-mandated interoperability requirements.

Technical Architecture

Protocol Components

The Point-to-Point Tunneling Protocol (PPTP) extends the (PPP) by enabling its packets to be tunneled over networks, without altering the underlying PPP mechanisms. PPTP achieves this by encapsulating PPP frames within an enhanced (GRE) mechanism, which provides flow and congestion control for reliable transport across IP infrastructures. This layered approach allows PPP's , , and features to operate transparently within the tunnel, treating the IP network as a virtual point-to-point link. While the description here emphasizes the dial-up remote access , PPTP also supports direct IP connections such as LAN-to-LAN, where PAC and PNS functions may be co-located. PPTP's architecture relies on three primary entities to facilitate secure remote access. The PPTP Access Concentrator () resides on the server side, typically integrated with a (NAS) connected to public switched telephone networks (PSTN) or integrated services digital networks (ISDN), where it terminates the PPP Link Control Protocol (LCP), handles the telco interface, and performs PPTP tunneling functions. The PPTP Network Server (PNS), often implemented on general-purpose computing platforms, manages the PPP Network Control Protocol (NCP) termination, including and address assignment, while coordinating with the PAC to establish and maintain tunnels. On the , the PPTP client—usually software or on a remote device such as a or mobile system—initiates the PPP connection over the telco network (PSTN/ISDN) to the PAC, which then encapsulates the PPP traffic for transmission over the IP network to the PNS. Central to PPTP operations are two distinct channels: the control connection and the data channel. The control connection, established over , serves as a signaling pathway for managing tunnel lifecycle events, including call establishment, modification, and teardown through a series of request-reply messages such as Start-Control-Connection-Request and Call-Clear-Request. In contrast, the data channel employs GRE packets to carry the actual tunneled PPP frames between the client and the PAC or PNS, supporting multiplexing of multiple sessions within a single tunnel via assigned call IDs and incorporating sequence numbers for orderly delivery and flow control. PPTP is inherently designed for integration with networks, where the GRE-encapsulated packets are routed as standard datagrams, enabling seamless traversal of internetworks without requiring specialized . The original specification supports addressing and headers exclusively, with no provisions for native compatibility, limiting its applicability in modern dual-stack environments unless extended by external mechanisms.

Network Ports and Encapsulation

The Point-to-Point Tunneling Protocol (PPTP) establishes its control channel over a connection using port 1723, which facilitates initial negotiation, tunnel management, and the exchange of control messages such as the Start-Control-Connection-Request. This port serves as the entry point for the protocol's signaling, enabling the (PPP) Network Server (PNS) to listen for incoming connections from the PPTP Access Concentrator (). For the data tunnel, PPTP employs Generic Routing Encapsulation (GRE), utilizing IP protocol number 47 to carry encapsulated PPP frames between the PAC and PNS. This encapsulation method supports the tunneling of multiprotocol datagrams, including non-IP protocols such as IPX or AppleTalk, by leveraging PPP's ability to handle diverse network layer payloads within an IP overlay network. The GRE variant in PPTP includes enhancements for session multiplexing via a key field and optional sequencing for payload ordering. PPTP packets follow a layered structure consisting of an outer , a GRE header, and the PPP . The GRE header incorporates specific s, including the Key (K=1) to indicate the presence of a 32-bit Call ID for session , the Sequence (S=1 for data packets) for ordering, and the (A=1 when an acknowledgment number is included for flow control); the Checksum (C=0) and Routing (R=0) s are typically unset. Fragmentation handling adheres to IP mechanisms, with no additional protocol-specific provisions beyond the recommended (MTU) of 1532 octets for the PPP (excluding IP and GRE headers). A notable operational challenge for PPTP arises from GRE's use of IP protocol 47, which is neither nor , complicating traversal through firewalls and (NAT) devices that primarily inspect or permit / traffic. Deployment often requires explicit allowance of protocol 47 in rules to permit the data tunnel, in addition to opening port for control signaling.

Operational Mechanism

Connection Setup

The connection setup process in the Point-to-Point Tunneling Protocol (PPTP) initiates when the client, functioning as the PPTP Network Server (PNS), establishes a Transmission Control Protocol (TCP) connection to the PPTP Access Concentrator (PAC) on port 1723. This control connection serves as the foundation for signaling and management messages exchanged between the PNS and PAC. Once the TCP session is open, the PNS transmits a Start-Control-Connection-Request message to the PAC, specifying key parameters such as the protocol version (e.g., 0x0100 for version 1.0), framing capabilities (asynchronous framing indicated by value 1 or synchronous framing by value 2), bearer capabilities (analog indicated by 1 or digital by 2), and vendor-specific information including firmware and host details. The PAC processes the request and responds with a Start-Control-Connection-Reply message, which includes a result code (1 for success) and mirrors the supported protocol version, framing, and bearer capabilities from the request to confirm compatibility. If the reply indicates success, the control connection is established, enabling further negotiation; otherwise, an details the failure reason, such as unsupported version or capabilities mismatch. , if configured, occurs via challenge-response mechanisms integrated into the subsequent steps, though primary authentication is deferred to the (PPP) phase. Following control connection confirmation, the PNS sends an Outgoing-Call-Request to initiate the tunnel session, including the called number, minimum and maximum bearer speeds, framing type (async or sync), window size for flow control, and subaddress if applicable. The PAC evaluates the request and replies with either an Outgoing-Call-Reply confirming the call (result code 1, with assigned Call IDs, connect speed, and quality parameters) or a Call-Clear-Request to reject it (e.g., due to resource unavailability or invalid parameters). Upon successful call , the (GRE) tunnel is established for data transport, using enhanced GRE headers with Call IDs for multiple sessions. With the GRE tunnel active, the setup transitions to PPP negotiation over the encapsulated channel, where Link Control Protocol (LCP) packets configure link options such as Maximum Receive Unit (MRU, default 1500 octets) and protocols, followed by Network Control Protocol (NCP) exchanges for assignment and compression settings. This phase completes the session establishment, allowing secure PPP frames to flow through the tunnel.

Data Transmission

After the PPTP tunnel is established, data transmission occurs by encapsulating Point-to-Point Protocol (PPP) frames, such as IP datagrams, within (GRE) packets, which are then transmitted over IP networks using IP protocol number 47. This enhanced GRE mechanism allows PPP packets to be tunneled between the PPTP Access Concentrator (PAC) and the PPTP Network Server (PNS) while providing flow and congestion control. To maintain the tunnel's operational status during transmission, PPTP employs control messages exchanged over the TCP control channel, including Echo-Request and Echo-Reply packets that monitor link quality and detect connectivity issues. These messages help ensure reliable ongoing communication by periodically verifying the tunnel's health without interrupting data flow. GRE headers incorporate sequence numbering to preserve packet order and prevent reordering during transit; out-of-sequence packets are discarded to maintain integrity. Optional flow control is implemented via the Window Size field in the control channel's Start-Control-Connection-Reply and related messages, allowing endpoints to negotiate a sliding window for data acknowledgments piggybacked on GRE packets, with an initial window size typically set to half the maximum allowable value. A single control connection supports multiple concurrent tunnels, enabling efficient management of several sessions. Tunnel teardown is initiated by a Call-Clear-Request message over the control channel, which prompts the closure of both the TCP session and the associated GRE data tunnel. For error handling, PPTP relies on PPP's built-in link-level recovery mechanisms for basic or corruption, supplemented by PPTP-specific messages such as WAN-Error-Notify for reporting wide-area network errors and Call-Disconnect-Notify for disconnection reasons, including "No Carrier" to indicate physical link failure.

Security Features and Vulnerabilities

Authentication Protocols

The Point-to-Point Tunneling Protocol (PPTP) inherits its authentication mechanisms from the (PPP), enabling secure verification of user credentials over the established tunnel. PPTP supports several PPP authentication methods, including (PAP) for plaintext password transmission, (CHAP) using hashing for one-way authentication, Microsoft Challenge Handshake Authentication Protocol version 1 (MS-CHAP v1) and version 2 (MS-CHAP v2) for Microsoft-specific extensions, and (EAP) for more advanced methods. These protocols operate within the PPP session encapsulated in the PPTP tunnel, allowing the Point-to-Point Tunneling Protocol Access Concentrator (PAC) or Network Server (PNS) to handle authentication. MS-CHAP v1, defined as an extension to PPP CHAP, provides one-way authentication tailored for Windows networks. In this process, the authenticator (server) generates and sends an 8-octet challenge to the peer (client). The peer then computes responses using the challenge, its username, and password-derived hashes: a 24-octet (LM) response (now deprecated and typically zero-filled) based on the LM hash, and a preferred 24-octet NT response derived from the NT password hash via repeated encryptions. The peer sends these along with the encrypted username and a flag indicating the use of the NT response; the authenticator verifies the response against stored credentials to authenticate the peer. MS-CHAP v2 builds on with enhancements for stronger security, including mutual authentication and resistance to replay attacks, while remaining compatible with frameworks like PPTP. The initiates with a 16-octet challenge, to which the peer responds with its own 16-octet peer challenge, a 24-octet NT response (generated similarly to but using the combined challenges), and the username. Upon successful peer verification, the sends a success packet containing a 42-octet response, computed using on the peer challenge, NT response, and , allowing the peer to mutually verify the . This version negotiates via CHAP algorithm identifier 0x81 and still relies on an initial phase for key derivation. Authentication negotiation in PPTP occurs during the Link Control Protocol (LCP) phase of the session, which follows the initial tunnel establishment via the PPTP control connection. The peers exchange LCP options to select a compatible method (e.g., v2 preferred over v1), with the PAC or PNS potentially delegating to a backend server. If authentication fails, the session terminates, leading to clearance of the PPTP call and disconnection. This integration ensures identity verification before proceeding to data transmission, though it leverages PPP's link control for overall session management.

Encryption Implementation

The Point-to-Point Tunneling Protocol (PPTP) employs Microsoft Point-to-Point (MPPE) as its primary mechanism for providing confidentiality to tunneled PPP data. MPPE utilizes the stream cipher, with supported key lengths ranging from 40-bit to 128-bit, where the effective encryption strength depends on the negotiated . These keys are derived from the NT hash of the user's password, obtained during the authentication process, which precedes encryption setup. Session keys for MPPE are generated by hashing the hash with additional material from the exchange to produce master keys, from which the initial send and receive session keys are computed using SHA-1. In stateless mode, keys are updated on a per-packet basis to enhance security; this involves synchronous updates, where both endpoints use the same key derivation input for coherency, or asynchronous updates, allowing independent send and receive keys. For 40-bit and 128-bit keys in stateless operation, the update process truncates or pads the derived key material accordingly to match the cipher's requirements. MPPE negotiation occurs during the Compression Control Protocol (CCP) phase of PPP link establishment, following authentication, where endpoints exchange configuration options to select the key length and mode. The CCP options include flags for 128-bit ('S'), 40-bit ('L'), and stateless ('H') modes, enabling stateful operation by default, in which keys are reused but refreshed every 256 packets or via asynchronous historyless updates. In stateful mode, the sender initiates key changes by incrementing a coherency count, prompting the receiver to derive new keys from the shared master key. MPPE provides no inherent integrity protection for encrypted data, relying solely on PPP's basic frame check sequence for error detection. This design exposes PPTP to bit-flipping attacks, as modifications to ciphertext can alter plaintext without detection in the absence of authentication tags.

Documented Weaknesses

One significant vulnerability in PPTP lies in its use of MS-CHAP version 1 for authentication, which permits an attacker who intercepts the authentication response to extract the user's NTLM hash directly from the exchanged packets. This extraction enables pass-the-hash attacks, where the hash can be replayed to authenticate to other systems without knowledge of the plaintext password, compromising network access beyond the initial tunnel. MS-CHAP version 2, intended as an improvement, was also found to be insecure; in 2012, researchers demonstrated a method to reduce its security to a single DES encryption operation, allowing offline recovery of the NT hash using precomputed rainbow tables. With relatively low computational resources, this recovery can be achieved quickly, as demonstrated by tools and services available since 2012 that could crack it in under a day using cloud computing. The Point-to-Point Encryption (MPPE) scheme in PPTP, which relies on for , is susceptible to known-plaintext attacks due to the prevalence of predictable packet structures in tunneled traffic, such as SMB headers. Additionally, the absence of protection in early implementations allows bit-flipping attacks, where an adversary can modify to alter without detection, and the use of predictable initialization vectors exacerbates keystream reuse vulnerabilities. At the protocol level, PPTP provides no cryptographic protection for its TCP-based control channel, leaving it open to man-in-the-middle attacks where an interceptor can impersonate the and or alter negotiation messages. Furthermore, the (GRE) tunnel carrying the data lacks inherent encryption enforcement, making its contents inspectable if MPPE keys are compromised or not applied, exposing sensitive traffic to eavesdropping. These vulnerabilities have contributed to PPTP's ; in October 2024, Microsoft announced plans to remove support for PPTP in future versions, urging migration to secure alternatives.

Current Status and Legacy

Reasons for Obsolescence

The obsolescence of the Point-to-Point Tunneling Protocol (PPTP) stems primarily from a series of security revelations that exposed fundamental weaknesses, beginning with a 1998 by and Mudge, which identified flaws in password hashing, challenge-response authentication, encryption key generation, and the unauthenticated control channel, allowing attackers to recover passwords, impersonate servers, and crash systems. These issues were compounded by the 2012 demonstration at by and David Hulton using the chapcrack tool, revealing that v2—the authentication mechanism integral to PPTP—could be cracked offline using tables derived from captured handshakes, enabling theft without active compromise. Consequently, the (IETF) never advanced PPTP to standards-track status; its specification in 2637 was published solely as an informational document due to its origins in a vendor consortium led by , while the IETF's Point-to-Point Protocol Working Group prioritized (L2TP) as the standardized alternative for tunneling. issued warnings via Security Advisory 2743314, highlighting the cryptographic vulnerabilities in PPTP with v2 and recommending migration to more secure protocols, effectively signaling the protocol's unsuitability for ongoing use. By the early 2000s, superior alternatives emerged that addressed PPTP's shortcomings, further accelerating its decline. L2TP, combined with as specified in RFC 3193, provided robust security through (IKE) for key negotiation and (AES) for confidentiality, offering authentication, integrity, and replay protection absent in PPTP's Microsoft Point-to-Point Encryption (MPPE). Similarly, , first released in 2001 as an open-source solution, utilized for flexible, strong cryptographic implementations including AES and supported for better performance, quickly gaining adoption for its configurability and resistance to known attacks. These protocols rendered PPTP's reliance on weaker RC4-based MPPE and vulnerable obsolete, as they met evolving demands for enterprise-grade VPN security without PPTP's inherent design limitations. Regulatory pressures in the 2010s intensified PPTP's marginalization, as compliance standards mandated strong cryptography incompatible with its outdated mechanisms. The Payment Card Industry Data Security Standard (PCI DSS) Requirement 4 requires strong cryptography for protecting cardholder data in transit over public networks, implicitly excluding protocols like PPTP that depend on deprecated RC4 encryption, which fails to provide adequate protection against modern threats. Under the General Data Protection Regulation (GDPR), Article 32 demands appropriate technical measures including encryption to ensure data security; PPTP's weak authentication and encryption do not satisfy this, exposing organizations to fines for inadequate safeguards during data processing and transmission. Additionally, PPTP has never achieved Federal Information Processing Standards (FIPS) 140-2 validation, as its core algorithms—such as RC4 and non-approved key derivation in MPPE—do not meet NIST-approved cryptographic module requirements for government and regulated environments. Performance limitations also contributed to PPTP's obsolescence in high-speed modern networks, where its encapsulation using (GRE) over introduces significant overhead and compatibility issues. The combination of GRE (IP protocol 47) for data packets and port 1723 for control exacerbates problems in NAT-heavy environments, as firewalls often block GRE, leading to connection failures or forced reliance on less efficient tunneling modes that increase and reduce throughput on broadband links exceeding 100 Mbps. In lossy or congested networks, this setup suffers from meltdown—where triggers excessive retransmissions across the tunnel—making PPTP unsuitable for bandwidth-intensive applications like video streaming or cloud access, unlike UDP-based alternatives that handle variability better.

Implementation in Modern Systems

Despite its , PPTP retains limited native support in certain operating systems as of 2025. In Microsoft Windows, client support persists in versions up to , though it has been disabled by default since in 2015; server-side implementation is deprecated in 2025 and later, where it is disabled by default in new Routing and Remote Access Service (RRAS) setups but remains manually enableable, with full removal planned for future versions beyond 2025. On Apple platforms, PPTP was natively supported in macOS versions prior to (10.12, released in 2016), when Apple removed it entirely; similarly, iOS dropped PPTP support with in 2016. Open-source implementations continue to enable PPTP on Linux distributions, though they are widely flagged as insecure. The pptp-linux package, which provides client support for Microsoft's protocol, remains available in repositories for distributions like as of 2025, allowing users to install and configure PPTP connections via command-line tools. Additionally, the pppd daemon with the pptp plugin facilitates custom PPTP setups on various systems, including servers and desktops, often used for compatibility with older VPN endpoints. These tools, based on the protocol defined in RFC 2637, are installable through standard package managers but come with explicit warnings against use in security-sensitive environments. In router and , PPTP lingers primarily in older devices and custom builds. It is embedded in legacy and from the early , where it can still be enabled for basic VPN passthrough, though modern firmware updates discourage its activation due to vulnerabilities. like , as of its 2023 releases and ongoing 2025 builds, includes PPTP server and client options out-of-the-box for compatible , but documentation recommends disabling it in favor of more secure alternatives. Newer distributions, such as version 2.7 and above (released starting 2023), do not include PPTP support, having removed it in earlier versions around 2018. PPTP's remaining use cases are confined to isolated, low-risk scenarios without reliance on current certifications. It persists in air-gapped networks or systems where needs outweigh modern demands, often in environments like outdated . No new certifications or compliance approvals for PPTP have emerged since the early , prompting administrators to employ tools that convert PPTP configurations to IPsec-based VPNs for enhanced .

References

  1. [1]
    RFC 2637 - Point-to-Point Tunneling Protocol (PPTP)
    This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network.
  2. [2]
    Microsoft Ships Beta 2 Versions of Windows NT Server, Workstation ...
    May 13, 1996 · To enable the creation of virtual private networks across the Internet, Windows NT Server 4.0 offers point-to-point tunneling protocol (PPTP) ...
  3. [3]
    [PDF] Guide to IPsec VPNs - NIST Technical Series Publications
    Jun 1, 2020 · IPsec is a network layer security control for protecting communications. It is a framework of open standards for private communications over IP ...
  4. [4]
    Virtual Private Network (VPN) Security Requirements Guide
    Dec 19, 2024 · The Remote Access VPN Gateway must be configured to prohibit Point-to-Point Tunneling Protocol (PPTP) and L2F. The PPTP and L2F are obsolete ...<|control11|><|separator|>
  5. [5]
    [PDF] Virtual Private Networks
    PPTP. ❑ PPTP = Point-to-point Tunneling Protocol. ❑ Developed jointly by Microsoft, Ascend, USR, 3Com and ECI Telematics. ❑ PPTP server for NT4 and clients ...
  6. [6]
    Special Edition Using Windows NT Server 4.0 -- Chapter 4 - rigacci.org
    The new PPTP (Point-to-Point Tunneling Protocol)-announced by Microsoft, 3Com Corp., Ascend Communications, ECI Telematics, and U.S. Robotics in March 1996- ...
  7. [7]
    MS helps move private WANs to Net - CNET
    Mar 4, 1996 · Microsoft announced that it will incorporate the PPTP protocol in version 4.0 of its Windows NT Server. Ascend will implement PPTP in its entire ...
  8. [8]
    Understanding Point-to-Point Tunneling Protocol (PPTP)
    Point-to-Point Tunneling Protocol (PPTP) is a network protocol that enables the secure transfer of data from a remote client to a private enterprise server by ...Missing: origins collaborators
  9. [9]
    https://www.cnet.com/tech/services-and-software/ms-helps-move-private-wans-to-net/
  10. [10]
    Dial-Up Networking 1.2 Upgrade Available
    Point-to-Point Tunneling Protocol (PPTP) for Windows 95 is another component of the Dial-Up Networking 1.2 Upgrade. The PPTP client allows a Windows 95-based ...
  11. [11]
    Information on RFC 1994 - » RFC Editor
    RFC 1994. PPP Challenge Handshake Authentication Protocol (CHAP), August 1996 ... RFC 1994. Abstract. This document defines a method for Authentication using ...
  12. [12]
    Information on RFC 3078 - » RFC Editor
    This document describes the use of the Microsoft Point to Point Encryption (MPPE) to enhance the confidentiality of PPP-encapsulated packets. This memo provides ...
  13. [13]
    Everything VPN is New Again - ACM Queue
    Nov 23, 2020 · It was never widely deployed. The first unambiguous VPN was PPTP (Point-to-Point Tunneling Protocol). It was created in 1996 and standardized ...Missing: motivation | Show results with:motivation
  14. [14]
    https://www.rfc-editor.org/info/rfc3078
  15. [15]
    https://datatracker.ietf.org/doc/html/rfc2637#section-1.2
  16. [16]
    https://datatracker.ietf.org/doc/html/rfc2637#section-1.3.1
  17. [17]
    https://datatracker.ietf.org/doc/html/rfc2637#section-1.3.2
  18. [18]
    https://datatracker.ietf.org/doc/html/rfc2637#section-1.1
  19. [19]
    RFC 2637: Point-to-Point Tunneling Protocol (PPTP) - » RFC Editor
    This document specifies a protocol which allows the Point to Point Protocol (PPP) to be tunneled through an IP network.Missing: collaborators | Show results with:collaborators<|control11|><|separator|>
  20. [20]
    RFC 2784: Generic Routing Encapsulation (GRE)
    This document specifies a protocol for encapsulation of an arbitrary network layer protocol over another arbitrary network layer protocol.
  21. [21]
    Error when establishing a VPN connection - Windows Client
    Jan 15, 2025 · GRE is IP Protocol 47. PPTP uses GRE for tunneled data. Resolution. To resolve this issue, configure the network firewall to permit GRE protocol ...
  22. [22]
    https://learn.microsoft.com/en-us/troubleshoot/windows-client/networking/error-when-establishing-vpn-connection
  23. [23]
    https://datatracker.ietf.org/doc/html/rfc2637#section-4.1
  24. [24]
    https://datatracker.ietf.org/doc/html/rfc2637#section-2.5
  25. [25]
    https://datatracker.ietf.org/doc/html/rfc2637#section-2.6
  26. [26]
    https://datatracker.ietf.org/doc/html/rfc2637#section-4.3
  27. [27]
    https://datatracker.ietf.org/doc/html/rfc2637#section-4.2
  28. [28]
    https://datatracker.ietf.org/doc/html/rfc2637#section-1.3
  29. [29]
    https://datatracker.ietf.org/doc/html/rfc2637#section-2.12
  30. [30]
    https://datatracker.ietf.org/doc/html/rfc2637#section-2.14
  31. [31]
    RFC 2433: Microsoft PPP CHAP Extensions
    ### Summary of MS-CHAP v1 Authentication Process (RFC 2433)
  32. [32]
    RFC 2759 - Microsoft PPP CHAP Extensions, Version 2
    This document describes version two of Microsoft's PPP CHAP dialect (MS-CHAP-V2). MS-CHAP-V2 is similar to, but incompatible with, MS- CHAP version one.Missing: PPTP | Show results with:PPTP
  33. [33]
    RFC 3078: Microsoft Point-To-Point Encryption (MPPE) Protocol
    ### Summary of MPPE Encryption from RFC 3078
  34. [34]
    Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)
    RFC 3079 describes methods to derive MPPE session keys from MS-CHAP-1, MS-CHAP-2, and TLS credentials, for 40, 56, and 128-bit keys.
  35. [35]
    Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP)
    Cryptanalysis of Microsoft's Point-to-Point Tunneling Protocol (PPTP). B. Schneier and Mudge. Proceedings of the 5th ACM Conference on Communications and ...
  36. [36]
    Weaknesses in MS-CHAPv2 authentication - Microsoft
    Aug 20, 2012 · A recent presentation by Moxie Marlinspike [1] has revealed a breakthrough which reduces the security of MS-CHAPv2 to a single DES encryption (2 ...Missing: Defcon | Show results with:Defcon
  37. [37]
    Analysis of Microsoft PPTP Version 2 - Schneier on Security
    In 1998, Bruce Schneier and Mudge released an analysis of Microsoft PPTP. We found serious flaws in the following areas: password hashing—weak algorithms ...Missing: critique | Show results with:critique
  38. [38]
    The PPTP VPN protocol: Is it safe? - Infosec Institute
    Sep 11, 2019 · Discover why PPTP VPN protocol may not be the safest choice for your business. Learn about its flaws and explore more secure alternatives.
  39. [39]
    Microsoft Security Advisory 2743314
    Aug 20, 2012 · Only VPN solutions that rely on PPTP in combination with MS-CHAP v2 as the sole authentication method are vulnerable to this issue.Microsoft Security Advisory... · Frequently Asked Questions · Suggested Actions
  40. [40]
    RFC 3193: Securing L2TP using IPsec
    ### Confirmation
  41. [41]
    What Is the History of VPN? - Palo Alto Networks
    The oldest VPN protocol is PPT. Introduced in the mid-1990s by a consortium led by Microsoft, PPTP was one of the first technologies to allow secure connections ...Missing: 1996 | Show results with:1996
  42. [42]
    [PDF] Summary of Changes from PCI DSS Version 3.2.1 to 4.0
    This document provides a high-level summary and description of the changes from PCI DSS v3.2.1 to. PCI DSS v4.0 and does not detail all document revisions.
  43. [43]
    PPTP vs IPSec IKEv2 vs OpenVPN vs WireGuard - IVPN
    PPTP uses TCP port 1723 and GRE (Protocol 47). PPTP can be easily blocked by restricting the GRE protocol. IKEv2 uses UDP 500 for the initial key exchange, ...<|control11|><|separator|>
  44. [44]
    TCP Issues Explained - Fasterdata - ESnet
    Aug 19, 2025 · There are three major factors that affect TCP performance (there are others, but these are the Big Three): Packet loss, latency (or RTT -Round ...
  45. [45]
    Everything You Need to Know About PPTP VPNs
    Jul 6, 2025 · These vulnerabilities make PPTP susceptible to man-in-the-middle (MITM) attacks. ... GRE traffic, so the PPTP tunnel works properly. This ...
  46. [46]
    PPTP and L2TP deprecation: A new era of secure connectivity
    Oct 8, 2024 · We are deprecating the PPTP (Point-to-Point Tunneling Protocol) and L2TP (Layer 2 Tunneling Protocol) protocols from future Windows Server versions.Missing: setup | Show results with:setup
  47. [47]
    What is the Point-to-Point Tunneling Protocol (PPTP)? - JumpCloud
    Aug 4, 2025 · Developed in the 1990s and defined in RFC 2637, PPTP was once the go-to solution for creating Virtual Private Networks (VPNs) by ...
  48. [48]
    How to Connect to PPTP on macOS Sierra Despite Apple's Support ...
    Jan 3, 2025 · In other words, if you have set up a VPN server using PPTP, iOS and macOS Sierra users will no longer be able to connect to it.
  49. [49]
    pptp-linux package : Ubuntu - Launchpad
    pptp provides support for Microsoft's point to point tunneling protocol. There are no registered releases for the pptp ⇒ main.
  50. [50]
    Linux configure point to point tunneling PPTP VPN client ... - nixCraft
    Jun 11, 2007 · PPTP Client is a Linux, FreeBSD, NetBSD and OpenBSD client for the proprietary Microsoft Point-to-Point Tunneling Protocol, PPTP.
  51. [51]
    PPTP Setup: Debian/Ubuntu/Mint Command Line - StrongVPN
    Sep 19, 2025 · Follow the steps below to configure StrongVPN PPTP on Debian Ubuntu. This guide uses Linux Mint for demonstration purposes.
  52. [52]
    Configuring PPTP VPN with alternate Linksys Router Firmware
    Feb 12, 2006 · Step 1 - Get a Dynamic DNS Hostname · Step 2 - Configure VPN on the Router · Step 3 - Configure the (Windows) Client.Missing: pfSense | Show results with:pfSense
  53. [53]
    PPTP Server Configuration - DD-WRT Wiki
    Mar 18, 2018 · One of the big advantages of using PPTP over OpenVPN with DD-WRT is that PPTP is supported out-of-the-box for 4Mb firmware images and up. For an ...
  54. [54]
    View topic - PPTP server set up - DD-WRT Forum
    Mar 26, 2025 · I am trying to set up the DD-WRT router as a PPTP server and having some problems. I have set up the PPTP server as follows but can't connect either from ...View topic - [Solved] PPTP VPN Tunneling through DDWRT RoutersVPN PPTP tunnel - can't connect with other login and passwdMore results from forum.dd-wrt.comMissing: Cisco pfSense 2025
  55. [55]
    How To Setup Your Own VPN With PPTP - DigitalOcean
    Mar 20, 2013 · A Point-To-Point Tunneling Protocol (PPTP) allows you to implement your own VPN very quickly, and is compatible with most mobile devices.
  56. [56]
    PPTP Protocol: Benefits, Risks, and Alternatives - Group-IB
    Known Vulnerabilities and Security Flaws in PPTP. PPTP's known vulnerabilities include fundamentally broken MS-CHAP authentication that can be cracked within ...Missing: plaintext | Show results with:plaintext
  57. [57]
    Microsoft to Deprecate PPTP, L2TP Protocols in Windows Server
    Oct 15, 2024 · PPTP is considered obsolete due to its known vulnerabilities and weak encryption. Meanwhile, L2TP lacks built-in encryption or authentication ...Missing: 2012 | Show results with:2012