Overview: Point-to-Point Tunneling Protocol (PPTP) remains one of the historically significant VPN technologies. While largely superseded by more secure protocols, PPTP is still encountered in legacy networks, embedded devices, and compatibility scenarios. Understanding PPTP thoroughly requires examining both its control and data planes: the PPP-based control channel and the GRE-encapsulated data packets. This article dives into the packet structure, the role of GRE, and practical considerations for network engineers, developers, and administrators who need to support, debug, or migrate from PPTP.

PPTP architecture: Control vs Data Plane

PPTP uses two logical channels between endpoints:

  • Control channel: A TCP connection on port 1723 carrying PPTP control messages used to establish, maintain, and tear down sessions. This channel negotiates the PPP parameters and manages tunnels.
  • Data channel: Uses Generic Routing Encapsulation (GRE) for transporting PPP frames. GRE encapsulation is stateless and occurs over IP using protocol number 47 (not to be confused with TCP/UDP ports).

The separation means troubleshooting often requires correlating events on TCP/1723 with GRE traffic. The control channel sets up session identifiers that the GRE headers use to map packets to specific PPP sessions.

PPP role inside PPTP

PPTP encapsulates PPP frames inside GRE. As such, the usual PPP sub-protocols are present:

  • LCP (Link Control Protocol) negotiates link parameters, MRU, and authentication method.
  • PAP/CHAP/MS-CHAP/MS-CHAPv2 perform authentication (MS-CHAPv2 being the most common in Windows environments).
  • IPCP (IP Control Protocol) negotiates IP addresses and DNS options.

PPP options affect fragmentation, MTU/MRU negotiation, and compression. When PPP negotiates MRU/MTU values, those directly influence how GRE payloads are sized and whether IP-level fragmentation will occur.

GRE basics used by PPTP

GRE is the encapsulation mechanism for PPTP’s data channel. GRE provides a simple header that can carry many different payload types; in the context of PPTP, the payload is a PPP frame. Key points:

  • GRE uses IP protocol number 47.
  • PPTP attaches an additional 4-byte PPTP-specific header after the standard GRE header to carry the PPTP Call ID for demultiplexing sessions.
  • GRE headers have optional fields: Checksum, Key, and Sequence Number. PPTP makes use of the Key (Call ID) field; checksum and sequence can be present depending on implementation settings.

Standard GRE header layout (relevant fields)

GRE header is at minimum 4 bytes; when Key present it becomes 8 bytes. The typical layout:

  • 0-1: Flags and Version (16 bits). Important flags include C (ChecksumPresent), K (Key Present), S (Sequence Number Present).
  • 2-3: Protocol Type (16 bits). For PPTP, this is usually 0x880B (PPP in HDLC-like framing) or specific PPP protocol values when encapsulated.
  • If K bit set: 4-7: Key field (32 bits). PPTP uses the low-order 16 bits as Call ID in practice.
  • Optional Checksum (if C bit set) appears before Key.

For PPTP, a commonly seen GRE header for a data packet looks like:

  • Flags/Version: 0x2000 or similar (K bit set, others clear)
  • Protocol Type: 0x880B (PPP)
  • Key: 0x0000XXXX where XXXX is the PPTP Call ID

PPTP-specific GRE characteristics

PPTP implementations set the K bit and include the Call ID in the Key field. The Call ID distinguishes multiple PPP sessions multiplexed on one tunnel. The GRE packet payload begins with a PPP header (Address=0xFF, Control=0x03) and then PPP protocol field (e.g., 0x0021 for IPv4).

Detailed packet breakdown: Example GRE + PPP data packet

Example in order (offsets are relative to GRE start):

  • 0-1: GRE Flags/Version (0x2001 or 0x2003 if sequence/checksum flags present)
  • 2-3: Protocol Type 0x880B
  • 4-7: Key (Call ID). Example: 0x00000005 → Call ID 5
  • 8-9: PPP Address/Control bytes: 0xFF 0x03
  • 10-11: PPP Protocol field: 0x00 0x21 (IPv4) or 0x00 0x57 (IPv6) etc.
  • 12-…: Encapsulated payload (IP packet, or PPP payload such as IPCP payloads during negotiation)

When sequence numbers or checksums are used, additional fields appear between Protocol Type and Key fields or after the Key depending on flag ordering. Wireshark and packet captures typically mark PPTP GRE packets and will decode Call ID and PPP encapsulation accordingly.

Call ID, Sessions, and Demultiplexing

The PPTP server creates a Tunnel and assigns a Tunnel ID. Within that tunnel, each client connection (PPP session) gets a unique Call ID. The Call ID is carried inside the GRE Key field (lower 16 bits). GRE packets with that Call ID map to a particular PPP session and its negotiated parameters (encryption option, IP address assignment, compression).

When inspecting traffic, ensure you correlate the TCP/1723 control channel’s Start-Control-Connection-Request/Reply and Start-Control-Connection-Connected messages. Those control messages contain the Tunnel IDs and will reveal the mapping between control events and GRE call IDs.

Encryption and MPPE

PPTP on its own does not provide encryption for GRE payloads. Instead PPTP relies on Microsoft Point-to-Point Encryption (MPPE) applied to PPP payloads. MPPE is negotiated during PPP’s EAP or IPCP phase and can use session keys derived from MS-CHAPv2 authentication. Important considerations:

  • MPPE works at the PPP layer — GRE transparently carries the encrypted PPP frames.
  • MPPE supports 40-bit, 56-bit (historical) and 128-bit encryption keys, though the key strength depends on negotiation and licensing.
  • MPPE is vulnerable when combined with weak authentication (MS-CHAPv1) and is subject to known cryptographic attacks against MS-CHAPv2 (online/offline password cracking). Consequently, PPTP+MPPE is considered insecure for modern threat models.

Fragmentation, MTU, and Performance

Because GRE adds header overhead (minimum 8 bytes for GRE+Key plus PPP overhead), the effective MTU for the tunneled payload is reduced. If the client and server do not negotiate MRU/MRU appropriately, you can see fragmentation or PMTU issues. Practical recommendations:

  • Negotiate PPP MRU/MTU to account for GRE and PPP headers (typical safe MTU inside the tunnel is around 1400–1450 for IPv4 over GRE to avoid fragmentation on networks with 1500-byte MTU).
  • Consider enabling MSS clamping on firewalls to rewrite TCP SYN MSS values to avoid IP fragmentation over the tunnel.
  • Monitor for GRE fragmented packets — some networks and firewalls do not correctly reassemble GRE fragments, which can lead to packet loss and blackholing.

Firewall and NAT implications

Because GRE is IP protocol 47, many stateful firewalls and NAT devices that are only configured for TCP/UDP may block or mishandle GRE. Additional practical points:

  • When PPTP travels across NAT, NAT devices need to be PPTP-aware (application layer gateway, ALG) to rewrite embedded addresses and track call IDs. Non-aware NATs will break GRE traffic.
  • Some enterprise firewalls provide explicit PPTP passthrough and will translate port 1723 control traffic and manage GRE bindings. Verify vendor documentation for limitations (e.g., concurrent sessions, fragmented GRE handling).
  • Inspection systems that attempt to decode GRE payloads may add latency or drop packets if not configured for high throughput.

Security considerations and why PPTP is deprecated

From a security standpoint, PPTP has multiple weaknesses:

  • MS-CHAPv2 weaknesses: The authentication protocol allows brute-force/wordlist recovery of passwords due to weaknesses in its cryptographic design. Tools exist to recover NTLM hashes from MS-CHAPv2 exchanges.
  • MPPE key derivation: MPPE keys depend on the authentication exchange. If authentication is compromised, MPPE can be trivially broken.
  • GRE lacks integrity protection: GRE headers are not authenticated unless optional checksum/sequence are used, and even then they provide limited protection.

For modern deployments, prefer protocols such as OpenVPN (TLS-based), IKEv2/IPsec with modern ciphers, or WireGuard, which offer stronger cryptographic primitives and simpler NAT traversal strategies.

Practical debugging tips

When troubleshooting PPTP:

  • Capture both TCP/1723 and GRE (IP proto 47) simultaneously to correlate control messages and data packets.
  • Look for GRE packets with K bit set and examine the Key / Call ID to map to the PPP session.
  • Check PPP LCP negotiation failures on the control channel — many “tunnel up but no traffic” cases are because PPP failed to bring the link up.
  • Watch for MTU/MRU mismatches and fragmented GRE packets. Use tcpdump/WinDump with filters like “proto 47” for GRE and “tcp port 1723” for control.
  • On NAT devices, ensure PPTP passthrough is enabled and review NAT translation tables for GRE flow entries.

When to migrate away from PPTP

For any deployment requiring strong confidentiality or regulatory compliance, PPTP is not acceptable. Migration should be prioritized when:

  • Users access sensitive data or corporate resources.
  • Regulatory frameworks mandate strong encryption (e.g., GDPR, HIPAA).
  • Interoperability with modern clients is required on mobile or cloud environments.

Migrating involves selecting a modern protocol (IKEv2/IPsec, OpenVPN, WireGuard), updating client configuration, and planning for NAT traversal, firewall rules, and user re-provisioning.

Conclusion: PPTP’s design—separating a TCP-based control channel and GRE-encapsulated data—made it flexible and widely compatible in the early days of VPNs. However, the GRE packet format, Call ID demultiplexing, and PPP-based encryption (MPPE) do not compensate for fundamental cryptographic weaknesses. For engineers and administrators maintaining legacy systems, understanding GRE header fields, PPP negotiation details, and the interplay with NAT/firewalls is essential for troubleshooting. For new deployments, the recommended course is to adopt stronger, modern VPN protocols.

For additional guides on VPN protocols, configuration tips, and migration strategies, visit Dedicated-IP-VPN at https://dedicated-ip-vpn.com/.