Connect to a PPTP VPN Safely with pptp on Linux

You will finish with a working shape for starting a PPTP client connection through pppd, a way to verify the installed client, and a short failure checklist. PPTP is an old VPN protocol. Use it only when the service you must reach requires it, and prefer a modern protocol when you control both ends.

Allow about 20 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 VPN provider's authentication and encryption requirements. The examples below do not contain real credentials or contact a server until you replace the placeholders.

1. Check the installed client

First confirm the binary and package version. These are ordinary read-only commands and do not need elevated privileges:

$ 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 describe pptp 1.10.0. Option details can vary between releases, so keep this version in mind when comparing 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 makes the PPTP call and, by default, starts pppd to carry the network traffic. Non-option arguments are passed to pppd. The useful boundary is --: put pptp options before it and PPP options after it.

Create a root-owned PPP peer configuration if your distribution's PPP setup uses /etc/ppp/peers/. This changes persistent system configuration, so make a backup before editing and restrict the file if it contains 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

The pty form is the connection-manager mode documented by pptp. --nolaunchpppd tells pptp to use standard input and output as the network connection because pppd owns the PPP session. The options after the quoted command are PPP options, not pptp options.

Do not put a password in this peer file or in a shell command. Put the matching account in the PPP secrets file used by your host, commonly /etc/ppp/chap-secrets, following that file's existing format and permissions. A typical entry has the account name, server name, password and an optional address field. Ask the administrator which name must be used for the server column. Check the file owner and mode before connecting:

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

The exact output is host-specific. If the file is 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 changes where traffic goes. pptp normally looks up the route to the server and adds a host route so the control and GRE traffic keep using the original path. The manpage warns that this route is not currently removed when pptp exits.

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 use --nohostroute casually. It disables pptp's protection against an encapsulation loop when the tunnel supplies a route covering the server. It is intended for a deliberate routing design, such as one using --rtmark and a separate policy-routing table. --rtmark requires root privileges or CAP_NET_ADMIN and marks both the TCP control and GRE packets.

4. Start the connection

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

$ sudo pon work-vpn

On systems without pon, use the installed PPP launcher or invoke pppd call work-vpn according to that distribution's PPP configuration. Do not paste a password into either command.

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, but interface names and logs are host-specific. A route table alone does not prove that authentication and application traffic work. Test a destination that should be 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. This is a service-disrupting action and needs elevated privileges:

$ sudo poff work-vpn

Confirm that the PPP interface has gone:

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

If the command reports that the interface is absent, that is already the desired state. Recheck the route to the VPN server:

$ ip route get VPN_SERVER.example

If pptp left a host route behind, identify the exact route with ip route and remove only that route with elevated privileges, after confirming 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. Do not run a broad route flush on a remote host. If you cannot identify the stale entry confidently, leave it in place and recover through the host's console or network administrator.

6. Separate the common failures

A name-resolution failure is different from a VPN authentication failure. Check the server name and route first, then inspect the log for the point at which the connection stops. A rejected account or password belongs in the PPP secrets and server policy, not 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 is mainly useful when another PPP process owns the connection, as in the pty configuration above. Do not use it as a second connection while pon is already managing the same peer.

For a server-specific interoperability problem, the installed client recognises --quirks BEZEQ_ISRAEL. Use that only when the remote administrator identifies the affected BEZEQ or Orckit deployment. Options such as --debug and a higher --loglevel increase diagnostics; they do not fix credentials or routing. Avoid --test-type except in a controlled test, because it deliberately damages packet ordering.