pptp

pptp server_address [--options...]
pptp [--options...] (when invoked as a pppd plugin)

server_address
    Required. The IP address or hostname of the PPTP VPN server to connect to.

--client-ip
    Requests a specific local IP address for the client's end of the tunnel.

--server-ip
    Requests a specific remote IP address for the server's end of the tunnel.

--nolaunchpppd
    Prevents pptp from automatically launching the pppd daemon after the GRE tunnel is established.

--debug
    Enables verbose debugging output, useful for troubleshooting connection issues.

--loglevel
    Sets the logging verbosity level (0=silent, 4=debug) for pptp's internal operations.

--timeout
    Sets the maximum time in seconds to wait for a connection to be established before timing out.

--pppd-call
    Instructs pptp to pass control to pppd using options defined in the configuration file /etc/ppp/peers/.

--sync
    Uses synchronous PPP framing, often necessary when pptp works in conjunction with pppd through --pppd-call.

--nobuffer
    Disables internal buffering of GRE packets, which can sometimes resolve specific performance or compatibility issues.

--refuse-
    Refuses specific PPP authentication methods, e.g., --refuse-chap, --refuse-mschap-v2.

--quirk-
    A collection of various workarounds (e.g., --quirk-welcome, --quirk-broken-asyncread) for compatibility with non-standard or buggy PPTP server implementations.

The pptp command is a client for the Point-to-Point Tunneling Protocol (PPTP), a VPN protocol developed by Microsoft. It enables Linux systems to establish tunneled connections to PPTP-compatible VPN servers, commonly found in older corporate networks or legacy ISP setups.

pptp itself handles the establishment of the PPTP control connection and the Generic Routing Encapsulation (GRE) tunnel that encapsulates PPP packets. Once the tunnel is set up, pptp typically launches the pppd (PPP daemon) utility, which then manages the actual PPP negotiation, authentication (e.g., PAP, CHAP, MS-CHAPv1/v2), IP address assignment, and routing table configuration.

While pptp was once a prevalent solution for VPN connectivity, it is now largely considered outdated and insecure due to known vulnerabilities in its underlying authentication and encryption mechanisms. It is generally recommended to use more modern and secure VPN protocols like OpenVPN, WireGuard, or IKEv2/IPsec for new deployments.

PPTP is widely considered insecure by modern standards. Its underlying authentication protocols (especially MS-CHAPv1/v2) have known vulnerabilities, and its encryption (MPPE) can be weak or easily compromised. It is not recommended for new VPN deployments or for securing sensitive data. Furthermore, PPTP connections using GRE can often encounter difficulties traversing Network Address Translation (NAT) devices.

The pptp command typically acts as a frontend to the pppd daemon. After pptp establishes the underlying GRE tunnel, it usually launches pppd to handle the PPP negotiation. This involves authentication, IP address assignment, and setting up routes. Configuration for the pppd part of the connection is often found in files under /etc/ppp/ or in specific peer files like /etc/ppp/peers/<connection_name>, where credentials might be stored in /etc/ppp/chap-secrets or /etc/ppp/pap-secrets.

It is crucial to understand that PPTP offers minimal security by modern standards. Exploits exist for breaking its authentication, and its encryption can be easily bypassed or cracked. Users should prioritize more secure VPN solutions like OpenVPN, IPsec/IKEv2, or WireGuard for any new deployments or for protecting sensitive communications. The use of pptp should be limited to legacy systems where no other VPN option is available, and even then, with extreme caution.

The Point-to-Point Tunneling Protocol (PPTP) was initially developed by Microsoft in collaboration with Ascend Communications and others, and was released in 1996. The pptp-linux client, which provides the pptp command, was developed to allow Linux systems to interoperate with these Windows-centric VPN servers. It gained significant usage in the late 1990s and early 2000s as a primary method for remote access VPNs, particularly for connecting to Microsoft Windows NT/2000/2003 servers. However, its security shortcomings led to its gradual deprecation in favor of more robust protocols.

pppd(8), ip(8), openvpn(8), wg(8)