Monitoring VPN traffic on a network is a necessary task for administrators and security teams who need visibility into endpoints, compliance checks, or troubleshooting tunnels. This article gives a practical, technically detailed walkthrough for identifying and analyzing PPTP-based VPN traffic using Wireshark. It focuses on protocols, filters, interpretation of packets, and limitations—helpful for webmasters, enterprise operators, and developers who manage or audit VPN-enabled environments.

Why PPTP still matters

PPTP (Point-to-Point Tunneling Protocol) is an older VPN protocol that remains in use because of legacy devices and simple setup. Although it has known security weaknesses (notably in MS-CHAPv2 authentication and MPPE encryption strength), detecting PPTP flows on a network is often needed for migration, compliance, or incident response. Unlike modern VPNs that employ UDP ports or TLS, PPTP combines a control channel over TCP and a data channel over GRE, which makes it identifiable by metadata even if payloads are inaccessible.

Overview of PPTP traffic components

Understanding PPTP requires recognizing two separate components that Wireshark can inspect:

  • PPTP control channel: TCP port 1723. Used to establish control/messages (e.g., Start-Control-Connection-Request).
  • GRE data channel: IP protocol number 47 (Generic Routing Encapsulation). Carries PPP frames with encapsulated IP payloads.

These two channels together form the tunnel. The control channel negotiates parameters such as call IDs and session states, while GRE carries the actual tunneled traffic.

Preparing Wireshark for captures

Before capturing, ensure you have appropriate authorization and legal permission to monitor traffic on the target network. For best results:

  • Capture on a network segment that sees the gateway or VPN concentrator. If capturing on a client segment, you may not see GRE if NAT or routing hides it.
  • Use promiscuous mode and adjust capture buffer sizes for high-throughput links. In Wireshark’s Capture Options enable “Promiscuous mode” and increase file rotation/size if needed.
  • Save captures to disk as .pcapng. Use ring buffers if you expect long-running captures: this mitigates file-size issues.

Initial capture filters

To reduce noise, apply capture filters that target PPTP-related traffic. Capture filters run in libpcap and are more efficient than display filters:

  • Capture TCP 1723 only: tcp port 1723
  • Capture GRE only: ip proto 47
  • Both combined: tcp port 1723 or ip proto 47

Note: a capture filter like host 198.51.100.5 and (tcp port 1723 or ip proto 47) narrows to a single endpoint, reducing storage and analysis cost.

Using display filters to analyze captures

After capture, Wireshark display filters let you inspect specific packets and protocol fields. Useful display filters include:

  • Show PPTP control messages: pptp
  • Show TCP port 1723 traffic only: tcp.port == 1723
  • Show GRE traffic: ip.proto == 47
  • Filtered by IP endpoint: ip.addr == 203.0.113.10 and (tcp.port == 1723 or ip.proto == 47)

Wireshark has a PPTP dissector that interprets control messages if the capture includes TCP 1723 traffic.

Examining PPTP control channel (TCP 1723)

The control channel contains the handshake and status exchanges that reveal session-level metadata. Key points to inspect:

  • Start-Control-Connection-Request/Reply: Sent at the start of a PPTP session. Look for version, framing capabilities, and result codes.
  • Echo Request/Reply: Keepalive messages used to validate reachability.
  • Outgoing-Call-Request / Incoming-Call-Reply: These frames include Call ID values—these are critical for mapping GRE packets to a specific PPTP session.
  • Call Clear / Call Disconnect: Termination messages.

When you click a PPTP control packet in Wireshark, expand the PPTP protocol block to view fields such as Message Type, Magic Cookie, Call ID, and Result Codes. The Call ID ties the control and GRE channels: GRE encapsulated packets contain a call ID that matches the control channel’s call ID, enabling you to correlate the tunneled data.

Analyzing GRE (protocol 47)

GRE frames carry the encapsulated PPP payload. In Wireshark, GRE will be decoded and, if possible, PPP and higher-layer protocols will be shown. Points to inspect:

  • GRE header flags: Determine if sequence numbers or routing are present (important for ordering and reassembly).
  • Call ID field: Matches the PPTP control channel call ID. Use this to group packets belonging to the same tunnel.
  • PPP protocol field: The PPP header reveals whether the payload is IP, IPv6, or other (e.g., PPP IPv4 protocol 0x0021).

Display filter to show GRE frames with call ID 0x1234: gre.callid == 4660 (4660 decimal == 0x1234 hex). You can also filter by PPP payload: ppp && ip will show PPP frames that contain IPv4.

Mapping GRE flows to user sessions

To identify which user or endpoint owns a given PPTP tunnel, combine control-channel IP/TCP analysis with GRE call IDs:

  • Find the Start-Control-Connection-Request from a client IP to the server (TCP 1723). Note the source IP and TCP session.
  • Inspect subsequent Outgoing-Call-Request to obtain the Call ID.
  • Filter GRE frames by that call ID to see the tunneled traffic originating from the same client/server pair.

This mapping is essential for troubleshooting, bandwidth accounting, and incident investigations where you must attribute traffic to specific users.

Authentication and MS-CHAPv2 details

PPTP commonly uses PPP authentication mechanisms such as PAP, CHAP, or MS-CHAPv2. While MPPE encryption protects data, the initial authentication exchanges can be inspected if captured on the control or PPP negotiation phases:

  • Look for PPP LCP and PAP/CHAP frames inside GRE/PPP if authentication happens in-band.
  • MS-CHAPv2 exchanges appear in PPP and reveal challenge/response pairs but not cleartext passwords. Tools such as Hashcat can attempt offline cracking of captured MS-CHAPv2 hashes if you have legal authorization.

Important limitation: Wireshark cannot decrypt MPPE-protected PPP payloads without the encryption keys. In most practical scenarios you cannot obtain plaintext tunneled traffic unless you have the session keys or the client/server reveal them.

Common Wireshark display filters and examples

Handy filters you can copy-paste:

  • Show PPTP control messages: pptp
  • Show TCP 1723 only: tcp.port == 1723
  • Show GRE only: ip.proto == 47
  • GRE for a specific call ID: gre.callid == 1234 (replace 1234 with the decimal ID)
  • Show PPP IPv4 payload inside GRE: ppp && ip

Practical troubleshooting scenarios

Some practical scenarios where this analysis helps:

  • VPN not establishing: Inspect TCP 1723 for connection resets, PPTP control result codes, and check LCP negotiation failures.
  • Missing routed traffic: Confirm GRE frames exist for the session’s call ID and check PPP protocol fields. Lack of GRE indicates server/client didn’t bring up the data channel.
  • Split tunneling verification: When GRE carries IP traffic to an enterprise gateway, verify destination addresses inside PPP/IP payloads to determine whether traffic is tunneled or sent directly.

Limitations and security/ethical considerations

When monitoring VPN traffic remember:

  • Legal and privacy constraints: Capturing and attempting to decrypt user VPN traffic may violate laws, company policy, or privacy expectations. Obtain explicit authorization.
  • Encryption limits: MPPE-encrypted PPP payloads cannot be decrypted in Wireshark without the session keys. You can still infer metadata such as IPs, timing, packet sizes and correlate sessions, but not read content.
  • Obfuscation and tunneling variants: Some PPTP implementations may be wrapped in additional transports or NATs; GRE fragments or missing fields may complicate analysis.

Advanced tips and automation

For larger environments, consider automating aspects of capture and analysis:

  • Use tshark for headless capture and filtering: tshark -f "tcp port 1723 or ip proto 47" -w pptp_capture.pcapng
  • Scripted parsing: Export fields such as pptp.MessageType, gre.callid, and ip.src/ip.dst using tshark -T fields to create session tables for correlation.
  • Alerting: Integrate correlation rules in network monitoring platforms to flag unexpected PPTP sessions (e.g., a PPTP concentration outside approved gateways).

Example tshark command to extract call IDs and endpoints

Extract basic session metadata to CSV for offline analysis:

tshark -r pptp_capture.pcapng -Y "pptp || ip.proto==47" -T fields -e frame.time -e ip.src -e ip.dst -e pptp.call_id -e gre.callid -E header=y -E separator=, > pptp_sessions.csv

This produces a CSV with timestamps, endpoints, and call IDs you can analyze in spreadsheets or scripts.

Summary and best practices

To summarize the practical steps:

  • Capture TCP 1723 and GRE (protocol 47) traffic; use focused capture filters to reduce noise.
  • Correlate PPTP control messages and GRE call IDs to map tunnels to endpoints.
  • Inspect PPP headers for authentication methods and PPP-encapsulated protocol types.
  • Respect legal constraints, and remember you cannot decrypt MPPE without keys.
  • Automate capture/analysis for scale using tshark and scripted exports where appropriate.

With these techniques, administrators and security teams can reliably detect and analyze PPTP VPNs on their networks, perform troubleshooting, and gather session metadata for audits—while being mindful of the limitations imposed by encryption and legal boundaries.

Published on Dedicated-IP-VPN