Learn PPTP - Core Concepts & Main Architecture

#Introduction

Now that you know the history from episode 1, it is time to understand the engine of PPTP. You cannot troubleshoot or assess its security without knowing exactly how packets flow from an application on the client to the network behind the server.

Episode 2 dissects the PPTP protocol stack, its main components, and the role of the two different connection paths: the control channel and the data channel. By the end of this episode, you will be able to draw a PPTP session flow diagram from connection to data transfer.

#The PPTP Protocol Stack

#Layered Encapsulation

PPTP wraps data in four layers. An application produces a payload, the payload is wrapped in a PPP session, the PPP session is encapsulated in GRE, and the GRE packet is carried inside an ordinary IP packet:

Payload → PPP → GRE → IP

The PPP layer provides a point-to-point connection with authentication and compression. The GRE layer provides the tunnel. The IP layer lets the packet travel across any public network. This is what made PPTP flexible in the 1990s: as long as IP was available, a tunnel could be built.

#Two Channels in One Session

A key part of PPTP's architecture is the separation of two channels:

• Control channel: a TCP connection to port 1723, used to manage the tunnel and negotiate sessions.
• Data channel: GRE protocol 47, used to carry PPP frames containing the actual data.

sudo tcpdump -i any tcp port 1723 -n

The output of tcpdump -i any tcp port 1723 -n shows the handshake and control message exchange. You will see packets with the SYN flag establishing the connection, followed by PPTP control messages such as Start-Control-Connection-Request.

#Main Components

#Server: pptpd and pppd

On the server side, two processes work together. pptpd (PoPToP) is the daemon that listens on port 1723, accepts control connections, and then invokes pppd for each PPP session. pppd performs authentication, assigns IP addresses, and manages the point-to-point connection.

ps aux | grep -E "pptpd|pppd" | grep -v grep

With ps aux | grep -E "pptpd|pppd", you will see the pptpd daemon that always runs plus one pppd process per connected client. This one-pppd-per-client pattern is characteristic of PPTP and important for troubleshooting.

#Client: pptp-linux and Windows

On the client side, pptp-linux provides the tunnel driver plus control logic. When a connection is made, the pptp binary on the client communicates with the server over TCP 1723, then creates a ppp0 interface managed by the local pppd.

The Windows client works the same way through the built-in VPN feature, but the entire process is wrapped in a GUI.

#The Control Channel: Tunnel Manager

#Control Channel Duties

The control channel manages the entire tunnel lifecycle: establishing the TCP connection, exchanging version and vendor information, opening sessions, and closing them. Its messages include Start-Control-Connection, Outgoing-Call-Request, and Set-Link-Info.

Control messages are sent in the PPTP format defined by RFC 2637, starting with a header containing the message length and the control message type.

#The Data Channel: GRE and PPP Frames

#Data Channel Duties

Once a session is opened, data flows through the GRE tunnel. GRE in PPTP is GRE version 1 with a special header that carries a Call ID and a sequence number. The Call ID is used to distinguish multiple tunnels within a single connection.

PPP frames are encapsulated inside GRE packets and sent as IP packets with protocol 47. In stateless mode, MPPE does not use the sequence number for synchronization — this detail will be covered in episode 6.

#The PPTP Session Flow

#From Connection to Data Transfer

Here is a concise overview of the PPTP session flow:

1. The client opens a TCP connection to the server's port 1723.
2. Both sides exchange Start-Control-Connection and send each other their protocol versions.
3. The client sends an Outgoing-Call-Request, and the server replies with an Outgoing-Call-Reply.
4. The server and client each run pppd and negotiate PPP.
5. LCP, authentication, and IPCP run inside the GRE tunnel.
6. The ppp0 interface comes up and traffic starts flowing.

ip addr show ppp0

After step 6, ip addr show ppp0 shows the tunnel interface with its virtual IP address. This is the simplest proof that the whole architecture is working.

#Negotiating Options at Connect Time

In step 4, the client and server negotiate various PPP options inside the tunnel: the authentication method, the MTU size, and the MPPE status. The negotiation result determines whether the connection is accepted or rejected, and it is the main source of problems we will discuss in episode 8.

Note that this entire negotiation runs over the GRE tunnel, not over the TCP control channel. In other words, the data channel must be alive before authentication can begin.

#When a Channel Fails

Sometimes the control channel forms perfectly but the data channel never works. This usually means GRE is blocked along the path — a NAT and firewall problem we will cover in episode 16. Understand this two-channel division first, because nearly all PPTP troubleshooting is rooted here.

#Closing

Episode 2 gives you a complete picture of PPTP's architecture: the protocol stack from PPP to GRE to IP, two channels working in parallel, server and client components, and the session flow from handshake to an active tunnel interface.

Key takeaways:

• PPTP wraps the payload with PPP, then GRE, then IP.
• The control channel uses TCP 1723 to manage the tunnel.
• The data channel uses GRE protocol 47 to carry PPP frames.
• pptpd serves the control connection; pppd handles one PPP session per client.
• PPTP GRE uses a Call ID and sequence number in its special header.
• The ppp0 interface appears on both client and server after a successful session.

In the next episode, episode 3, we will install and set up PPTP for the first time — a minimal /etc/pptpd.conf configuration, creating users in /etc/ppp/chap-secrets, connecting a pptp-linux client, and testing the first connection with a Windows client.