Connect to a PPTP VPN Safely with pptp on Linux

pptp is how Linux still talks to old-school PPTP VPNs, a protocol you should reach for only because the far end insists on it. This gets you a working shape for starting a client connection through pppd, a way to verify the installed client, and a short failure checklist. Prefer a modern protocol whenever you control both ends.

Twenty minutes for a prepared VPN account, plus time to check the remote server's settings. You need the pptp-linux package, ppp, the server hostname or address, and the provider's authentication and encryption requirements. Nothing below contains real credentials or contacts a server until you replace the placeholders.

1. Check the installed client

Confirm the binary and package version first. Ordinary read-only commands, no elevated privileges needed:

$ command -v pptp
/usr/sbin/pptp
$ pptp --version
pptp version 1.10.0
$ dpkg-query -W -f='${Package} ${Version}\n' pptp-linux
pptp-linux 1.10.0-1build4

The local manpage and executable both describe pptp 1.10.0. Option details shift between releases, so keep this version in mind when comparing notes with another host. The first non-option argument is always the PPTP server hostname or IP address.

2. Keep the PPP settings with the connection

pptp places the PPTP call and, by default, starts pppd to actually carry the traffic. Non-option arguments pass straight to pppd, and -- is the useful boundary: pptp options before it, PPP options after.

If your distribution's PPP setup uses /etc/ppp/peers/, create a root-owned peer configuration there. This changes persistent system configuration, so back it up before editing and lock the file down if it ends up holding anything sensitive:

$ sudo install -m 600 /dev/null /etc/ppp/peers/work-vpn
$ sudoedit /etc/ppp/peers/work-vpn

Use the following as a shape, replacing every placeholder with the values supplied by the VPN administrator:

pty "pptp VPN_SERVER.example --nolaunchpppd"
name 'DOMAIN\\USERNAME'
remotename PPTP
require-mppe-128
noauth
nobsdcomp
nodeflate
file /etc/ppp/options.pptp

That pty form is pptp's documented connection-manager mode. --nolaunchpppd tells pptp to treat standard input and output as the network connection, because here pppd owns the PPP session instead. Everything after the quoted command is a PPP option, not a pptp one.

Keep the password out of this peer file and out of any shell command. Put the matching account in the PPP secrets file your host uses, commonly /etc/ppp/chap-secrets, following its existing format and permissions. A typical entry has the account name, server name, password and an optional address field; ask the administrator which name goes in the server column. Check the file's owner and mode before connecting:

$ sudo stat -c '%A %U:%G %n' /etc/ppp/chap-secrets
-rw------- root:root /etc/ppp/chap-secrets

Exact output is host-specific. If the file turns out readable by other users, stop and fix its permissions under your site's credential-handling policy before entering a password.

3. Check routing before starting the tunnel

A PPTP tunnel usually installs a default route or otherwise redirects traffic. pptp normally looks up the route to the server first and adds a host route so control and GRE traffic keep using the original path. The manpage flags that this route is not currently removed when pptp exits, which catches people out later.

Record the current route as an ordinary user:

$ ip route get VPN_SERVER.example
VPN_SERVER_ADDRESS via 192.0.2.1 dev eth0 src 192.0.2.20

Your interface, gateway and source address will differ. Do not reach for --nohostroute casually: it switches off pptp's protection against an encapsulation loop when the tunnel supplies a route covering the server. It exists for a deliberate routing design, such as one built on --rtmark and a separate policy-routing table; --rtmark itself needs root privileges or CAP_NET_ADMIN and marks both the TCP control and GRE packets.

4. Start the connection

Peer and secrets entries checked, start pppd using the peer name. This needs elevated privileges because it creates a PPP interface and changes routing:

$ sudo pon work-vpn

Without pon, use the installed PPP launcher or invoke pppd call work-vpn per that distribution's PPP configuration. Neither command wants a pasted password.

Inspect the result after a few seconds:

$ ip link show ppp0
$ ip addr show dev ppp0
$ ip route
$ journalctl -b --no-pager | tail -80

A successful connection normally gives you a ppp0 interface and peer addresses, though interface names and logs are host-specific. A route table alone proves nothing about authentication or application traffic actually working; test a destination reachable only through the VPN, using the service's approved diagnostic method.

5. Stop the tunnel and remove a stale route

Stop a connection started with pon using poff. Service-disrupting, and it needs elevated privileges:

$ sudo poff work-vpn

Confirm that the PPP interface has gone:

$ ip link show ppp0
Device "ppp0" does not exist.

An absent interface is already the state you want. Recheck the route to the VPN server:

$ ip route get VPN_SERVER.example

If pptp left a host route behind, identify the exact one with ip route and remove only that route, with elevated privileges, once you have confirmed it was created for this connection:

$ sudo ip route del VPN_SERVER_ADDRESS via GATEWAY dev INTERFACE

Replace all three placeholders from your recorded route. Never run a broad route flush on a remote host, and if you cannot identify the stale entry with confidence, leave it alone and recover through the host's console or network administrator instead.

6. Separate the common failures

A name-resolution failure is not a VPN authentication failure, so check the server name and route first, then read the log for the point where the connection actually stops. A rejected account or password belongs in the PPP secrets and server policy, never in pptp's command line.

If the server expects a phone number, pass it as a pptp option before the PPP boundary:

$ pptp VPN_SERVER.example --phone 'NUMBER' --nolaunchpppd

That standalone command earns its keep when another PPP process owns the connection, as in the pty configuration above. Do not run it as a second connection while pon already manages the same peer.

For a server-specific interoperability problem, the installed client recognises --quirks BEZEQ_ISRAEL, worth trying only once the remote administrator identifies an affected BEZEQ or Orckit deployment. --debug and a higher --loglevel add diagnostics, nothing more; they fix neither credentials nor routing. Leave --test-type alone outside a controlled test, since it deliberately mangles packet ordering.