Learn PPTP - GRE & Encapsulation

#Introduction

If the control channel is the brain of PPTP, then GRE is its backbone. All the data you send through the tunnel is carried by GRE, and GRE's characteristics determine PPTP's speed, compatibility, and notorious NAT problems.

Episode 5 dissects Generic Routing Encapsulation: its header structure, how PPP frames are wrapped, the overhead you must account for in MTU, MSS clamping techniques, and GRE's fundamental limitations.

#What Is GRE

#Generic Routing Encapsulation

GRE (Generic Routing Encapsulation) is a tunneling protocol defined in RFC 2784. Its job is simple: wrap a packet or frame inside another IP packet, so the two networks appear to be directly connected.

PPTP uses GRE version 1, defined specifically in RFC 2637. This GRE version 1 header adds the Call ID and sequence number fields that do not exist in standard GRE — this is what distinguishes PPTP's GRE from other VPN GREs.

sudo tcpdump -i any proto 47 -n

tcpdump -i any proto 47 -n shows all GRE packets. When a PPTP tunnel is active with data flowing, you will see a stream of protocol 47 packets carrying PPP frames.

#Two GRE Families

Standard GRE is defined in RFC 2784 and is generic: it can wrap any protocol inside IP. PPTP uses a special variant documented in RFC 2637, with two additional fields: a Call ID to identify the tunnel and a sequence number to preserve packet order.

As a consequence, firewall packet filters cannot simply look at protocol 47 alone. To distinguish PPTP GRE from other GRE, you need to inspect the GRE header version — something generally handled automatically by the PPTP conntrack module discussed in episode 16.

#How PPP Frames Are Wrapped in GRE

#The PPTP GRE Packet Structure

When an application sends data, the encapsulation order is: the payload is wrapped in a PPP frame, the PPP frame is trimmed to the PPP MTU, then placed as the GRE payload. The GRE packet is then given the destination IP header.

The PPTP GRE header contains the version, flags, a Call ID to distinguish tunnels, and a sequence number to detect packet loss in stateful MPPE mode. Without the Call ID, the server could not distinguish multiple clients on a single connection.

#Overhead and MTU

#Calculating Overhead

Each layer adds bytes:

• IP header: 20 bytes.
• GRE header: 4 bytes or more with flags.
• PPP header: 2-6 bytes.
• MPPE header (when encryption is enabled): 2-6 bytes.

Total PPTP overhead is typically in the 50-80 byte range depending on options. That means if the network MTU is 1500, the maximum payload you can send is around 1400 bytes.

#Adjusting the Tunnel MTU

To prevent packets from fragmenting, the PPP interface MTU must be reduced. In the pppd options file:

mtu 1400
mru 1400

The mtu 1400 and mru 1400 lines limit the frame size to fit PPTP's overhead. 1400 is a common starting point; on networks with a smaller MTU, you will need to lower it further.

#MSS Clamping

#Why MSS Needs Trimming

MSS (Maximum Segment Size) is negotiated during the TCP handshake. If an application sets MSS 1460 for MTU 1500, packets inside the PPTP tunnel will exceed the limit and fragment. The solution is MSS clamping at the firewall.

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

The rule iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu adjusts the MSS of every passing TCP connection based on the path MTU. This is often the lifesaver when websites feel slow or refuse to load through the tunnel.

#Calculating an Explicit MSS Value

The correct MSS value follows a simple formula: the tunnel MTU minus the size of the TCP and IP headers. For a tunnel MTU of 1400, the result is about 1360:

• IP header: 20 bytes.
• TCP header: 20 bytes.
• MSS = 1400 - 40 = 1360.

If automatic clamping is not available on your firewall, set an explicit value with --set-mss 1360 on the TCPMSS rule. Make sure this value is consistent with the MTU configured in the pppd options file, and adjust it again whenever the tunnel MTU changes.

#GRE Limitations

#Stateless and No Built-in Encryption

GRE is a stateless protocol: it does not track connection state, offers no retransmission, and has no concept of congestion control. All of that is left to the TCP layer above it.

GRE also has no built-in encryption. The security of data in a PPTP tunnel depends entirely on MPPE, which is optional. If MPPE is not active, all data crosses the GRE tunnel in plaintext — a risk we will discuss in episode 13.

#Not NAT-Friendly

Because GRE only uses a protocol number without ports, NAT routers cannot distinguish between different GRE sessions. This causes many PPTP connections to fail behind NAT. The details and solutions are covered fully in episode 16.

#Sequence Numbers and Fragmentation

PPTP GRE has its own sequence numbers, and fragmentation at the IP level can complicate the tunnel. When GRE packets fragment on the network, their order can get scrambled and performance drops drastically. That is why the tunnel MTU must always be smaller than the physical path MTU.

#Choosing MTU in Practice

The rule of thumb: start from the physical path MTU (for example 1500), subtract PPTP's overhead (about 80 bytes), then add a small margin. The result is usually around 1400. For PPPoE paths that already use an MTU of 1492, the tunnel value needs to drop again to about 1300.

#Testing Your MTU Configuration

After changing the MTU, always test with a large file transfer and a ping at maximum size. If performance drops, recheck the overhead calculation and make sure the MSS clamping rule is installed on the firewall.

#Closing

Episode 5 mapped PPTP's data layer: the GRE version 1 header with Call ID and sequence number, 50-80 bytes of overhead that forces a lower MTU, MSS clamping techniques, and GRE's limitations of being stateless and NAT-unfriendly.

Key takeaways:

• PPTP uses GRE version 1 with a Call ID and sequence number.
• PPP frames are encapsulated in GRE and sent as IP protocol 47.
• PPTP overhead is 50-80 bytes, so the MTU must be reduced.
• mtu 1400 and mru 1400 are common starting points in pppd.
• MSS clamping with TCPMSS prevents TCP fragmentation inside the tunnel.
• GRE is stateless, has no built-in encryption, and struggles behind NAT.

In the next episode, episode 6, we will discuss MPPE, Microsoft's encryption for PPTP — how the key is derived from the MS-CHAPv2 password, configuring 128-bit MPPE, and the cryptographic weaknesses that make it vulnerable.