Learn PPTP - Logging & Troubleshooting

#Introduction

A healthy tunnel suddenly refusing connections is the moment that most often sends SysAdmins into a panic. In episode 8, you will turn that panic into a procedure: reading logs correctly, enabling debug output, and using the right tools to find the root cause.

This episode is your PPTP troubleshooting toolkit. You will learn where logs come from, how to make pppd talk more, the most frequent problems, and the tools that can narrow down the search area.

#Log Sources: pptpd and pppd

#Where the Logs Live

On systemd-based distributions, PPTP logs live in journald and are copied to /var/log/syslog. There are two log streams to distinguish: logs from the pptpd daemon (connections, tunnels) and logs from pppd (authentication, IPCP, MPPE).

sudo journalctl -u pptpd -f

journalctl -u pptpd -f shows the daemon log in real time. On this screen you will see messages such as CTRL: Client ip_address control connection started and CTRL: Starting call.

#Filtering pppd Logs

pppd logs are more detailed and often more important. Since pppd writes to syslog, filter with grep:

sudo grep pppd /var/log/syslog | tail -50

grep pppd /var/log/syslog shows log lines containing pppd, including LCP negotiation, authentication results, and the IP address assigned by IPCP.

#Enabling pppd Debug Mode

#The debug Option

By default pppd only records significant events. For troubleshooting, add debug to the options file so pppd records all PPP control frames:

debug

After adding debug, restart the service and repeat the connection. The log will now show LCP packet details, authentication exchanges, and MPPE. For even deeper debugging, run pppd manually on the command line with the -d -d -d flags — this surfaces the lowest-level details.

#Common Problems and How to Read Them

#GRE Blocked by NAT or Firewall

Typical symptom: the control channel forms, authentication succeeds, but data does not flow. GRE (protocol 47) is most likely blocked along the path. The log usually ends after Outgoing call reply with no data transfer.

Check with tcpdump on both sides:

sudo tcpdump -i any proto 47 -n -c 50

If tcpdump -i any proto 47 -n -c 50 only captures packets on one side, GRE is blocked in the middle. Full details are covered in episode 16.

#MS-CHAPv2 Authentication Failure

Symptom: the connection is rejected with a CHAP authentication failed or EAP authentication failed message. Check the log lines:

sudo journalctl -u pptpd | grep -i auth

If grep -i auth shows MS-CHAPv2 authentication failed, the most common causes are a wrong password in chap-secrets, or a client that does not support the MPPE the server demands.

#MTU and Routing Issues

Symptom: slow websites, stuck downloads, or small pings succeeding while large pings fail. These are signs of an MTU problem. The solution is lowering the tunnel MTU (episode 5) and adding MSS clamping.

#Reading Logs as a Timeline

Read the log as a sequence of events, not random fragments. Note timestamps on the server side and compare them with the moment of failure from the client side. A clear sequence of events will point you to the troubled layer — network, authentication, or routing.

This habit is what separates amateur troubleshooting from professional work: not just finding one error, but understanding the full flow of why a connection failed.

#Troubleshooting Tools

#Building a Diagnosis Flow

Follow this flow when a problem occurs:

1. Check the service status: systemctl status pptpd.
2. Follow the log: journalctl -u pptpd -f.
3. Test TCP 1723: nc -vz server 1723.
4. Check GRE: tcpdump -i any proto 47.
5. Check the tunnel interface: ip addr show ppp0.
6. Inspect routing: ip route show.

nc -vz 192.168.1.10 1723

nc -vz 192.168.1.10 1723 verifies whether TCP port 1723 is open from the client's location. This is the first step that separates a network problem from a configuration problem.

#Closing

Episode 8 gave you a structured troubleshooting procedure: reading pptpd and pppd logs, enabling debug mode, recognizing common symptoms, and building a diagnosis flow with the right tools.

Key takeaways:

• pptpd and pppd logs live in journald and /var/log/syslog.
• journalctl -u pptpd -f follows the daemon log in real time.
• Add debug to options.pptpd for PPP negotiation details.
• Blocked GRE is characterized by a live tunnel with no data flowing.
• CHAP authentication failed usually means credentials or MPPE do not match.
• Use nc, tcpdump, ip addr, and ip route to narrow down the cause.

In the next episode, episode 9, we will dissect server configuration in depth — every important directive in /etc/pptpd.conf, options in /etc/ppp/options.pptpd, IP pool management, and syslog integration.