Learn PPTP - Troubleshooting Deep Dive

#Introduction

Everything from episode 0 to 19 now converges on a single skill: systematically diagnosing PPTP problems. Episode 20 is a troubleshooting deep dive — not a list of random solutions, but a procedure you can follow step by step.

You will learn to recognize the five most common classes of problems, the right packet capture techniques, and how to tie together logs from multiple sources into one coherent story.

#Blocked GRE

#Symptoms and Diagnosis

The symptom of blocked GRE is always the same: the tunnel forms, authentication succeeds, but data never flows. To confirm, capture packets at both ends:

sudo tcpdump -i eth0 proto 47 -n

If tcpdump -i eth0 proto 47 -n captures packets on the server but the client receives nothing, GRE is lost in the middle. Check the firewall on every device between the client and the server, plus the ALG settings on routers (episode 16).

#Testing from Both Sides

Always capture at both ends. A pattern present only on one side shows the blocking direction. An empty pattern on both sides means the problem is deeper in the path or in the interface configuration.

#Checking Encapsulation on Routers

If GRE packets disappear in the middle, check whether devices on the path are fragmenting or preventing the forwarding of protocol 47. Some routers treat GRE as traffic that must be enabled through a separate passthrough option.

Test with a large ping from both sides to rule out MTU factors before blaming GRE. Two different problems can produce the same symptom, so disciplined elimination is the key.

#Authentication Failures

#Reading Error Messages

An MS-CHAPv2 authentication failure appears in the pppd log as CHAP authentication failed. To find the details, check the full log:

sudo journalctl -u pptpd | grep -i -E "chap|eap|auth"

journalctl -u pptpd | grep -i -E "chap|eap|auth" filters all lines related to authentication. Common causes: a wrong password in chap-secrets or RADIUS, a server name that does not match the server column in chap-secrets, or a client that does not meet the MPPE requirements.

#Checking chap-secrets Consistency

Verify that the server name in the options file (name pptpd) matches the second column of chap-secrets. A mismatch here is the most commonly overlooked cause of failure.

#MTU and MSS Issues

#Typical Symptom Patterns

MTU problems show a characteristic pattern: slow websites, downloads stuck at a certain size, or small pings succeeding while large pings fail. This happens when packets exceed the tunnel MTU and get fragmented or dropped.

#Verifying with a Large Ping

ping -c 3 -M do -s 1400 192.168.1.10

ping -c 3 -M do -s 1400 192.168.1.10 sends a 1400-byte packet with the do not fragment flag. Lower the size gradually until you find the maximum value that passes — that is the tunnel MTU limit that must be configured, and then install MSS clamping (episode 5).

#Routing Asymmetry

#Why Traffic Does Not Return

Routing asymmetry happens when packets travel one way but return via another path. With PPTP, this often appears when the client and server routing tables are inconsistent, or NAT is not symmetric.

ip route get 192.168.1.10

ip route get 192.168.1.10 shows the interface that will be used to reach the tunnel address. Compare the results on both sides; if there is a striking difference in interface selection, look for the cause of the inconsistent routing.

#Advanced Packet Capture Techniques

#Wireshark for Deep Analysis

For the hardest cases, save a capture and analyze it with Wireshark:

sudo tcpdump -i any tcp port 1723 or proto 47 -w pptp-all.pcap

tcpdump -i any tcp port 1723 or proto 47 -w pptp-all.pcap saves all control and data traffic to a file. In Wireshark, the pptp and gre filters will show the negotiation and payloads — this is the best way to see problems that are invisible in logs.

#Log Correlation

Log correlation means aligning timestamps across the server, client, and firewall. A single event produces entries in several places; stitching the story together points to the root cause quickly.

#Quick Diagnosis Checklist

When time is short, run this checklist in order:

1. Check that port 1723 is open and reachable from outside.
2. Verify the pppd log for authentication status.
3. Capture GRE at both ends and compare.
4. Test MTU with a stepped -M do ping.
5. Check ip route get on both sides for asymmetry.

This checklist resolves most cases without deep analysis. Save it as a runbook so every team member follows the same path during incidents, and results are easy to compare across events.

#Closing

Episode 20 combined all the material into a troubleshooting procedure: blocked GRE, authentication failures, MTU and MSS issues, routing asymmetry, and packet capture and log correlation.

Key takeaways:

• Blocked GRE is characterized by a live tunnel with no data flowing.
• Capture packets at both ends to determine the blocking direction.
• CHAP authentication failed is usually due to credentials, server name, or MPPE.
• ping -M do helps find the tunnel MTU limit.
• ip route get reveals routing asymmetry.
• Wireshark with a tcpdump capture gives the deepest analysis.

In the next episode, episode 21, we will discuss PPTP production considerations and lifecycle — PPTP's status as not recommended for production, end-of-life management, communicating with users, and meeting compliance requirements.