pptpsetup exists for one situation: a remote site whose firewall still speaks PPTP and nothing newer. This walks through checking the installed version, creating the peer without connecting, verifying what got written, then tearing it all down again cleanly. The examples target the pptp-linux package version 1.10.0-1build4, whose installed pptpsetup script is version 0.03.
pppd and PPTP client install, a server hostname or address, and credentials supplied by the server side.Confirm the command and package match the local documentation before you touch anything. These are ordinary checks and need no elevated privileges:
$ command -v pptpsetup
/usr/sbin/pptpsetup
$ dpkg-query -W -f='${Package} ${Version}\n' pptp-linux
pptp-linux 1.10.0-1build4
$ pptpsetup --help
pptpsetup --create <TUNNEL> --server <SERVER> [--domain <DOMAIN>]
--username <USERNAME> [--password <PASSWORD>]
[--encrypt] [--start]pptpsetup has two actions: --create writes a peer and credentials, --delete removes them. The tunnel name is your own local label, not necessarily anything the remote server recognises, and this installed script insists it be word characters only, so keep it simple, e.g. office.
Checkpoint: Do not continue until the package is installed and the server administrator has confirmed the exact server, username, domain if required, and whether MPPE encryption is expected.
Creating a tunnel changes two root-owned files: /etc/ppp/peers/TUNNEL and /etc/ppp/chap-secrets. The second one holds a password, so treat it as sensitive: take a private backup first, and never paste its contents into a ticket or terminal transcript.
$ sudo cp -p /etc/ppp/chap-secrets /etc/ppp/chap-secrets.before-pptpsetup
$ sudo ls -l /etc/ppp/chap-secrets /etc/ppp/chap-secrets.before-pptpsetup
-rw------- 1 root root ... /etc/ppp/chap-secrets
-rw------- 1 root root ... /etc/ppp/chap-secrets.before-pptpsetupSizes and timestamps will vary. If the backup command itself fails, stop and fix that before going further. The backup is there for recovery, but it also duplicates the secret, so keep it root-readable and remove it securely once you no longer need it.
Run the create action with sudo, but leave out --start for this first pass so it writes configuration without bringing up a connection. Leave out --password too, so the script prompts for it instead of putting the secret on the command line. Swap every uppercase placeholder for a real value:
$ sudo pptpsetup --create office \
--server vpn.example.invalid \
--domain EXAMPLE \
--username alice \
--encrypt
Password:
Nothing echoes while you type the password. The command appends a marked entry to chap-secrets and writes /etc/ppp/peers/office. Do not use --password 'secret' in routine use: arguments on the command line can leak through process inspection, shell history or logging. The prompt is the safer path the script actually supports.
--domain EXAMPLE makes the generated PPP name EXAMPLE\alice. If the service does not use an authentication domain, leave the option out rather than inventing one.
Read the peer file as root. It should contain the server command, PPP identity and tunnel name:
$ sudo sed -n '1,20p' /etc/ppp/peers/office
# written by pptpsetup
pty "/usr/sbin/pptp vpn.example.invalid --nolaunchpppd"
lock
noauth
nobsdcomp
nodeflate
name EXAMPLE\alice
remotename office
ipparam office
require-mppe-128With no domain set, the name line holds just the username. --encrypt is what produces require-mppe-128; it does not turn PPTP into a modern, generally safe VPN, so do not read it that way. Check the server address, identity and tunnel name before you attempt a connection.
Verify the matching secret without ever printing the password. This shows only the line number and the non-secret fields:
$ sudo awk '$2 == "office" { print NR ": " $1 " " $2 " <password-hidden> " $4 }' /etc/ppp/chap-secrets
3: EXAMPLE\alice office <password-hidden> *Your line number will differ. A missing line means the create step did not produce the credentials entry you expected: do not guess at a replacement, compare the server's actual requirements against the command you ran.
Warning: starting the tunnel can change routes and connectivity, so do it in a suitable maintenance window; treat it as an elevated, service-disrupting action. Use the peer name with pppd:
$ sudo pppd call office updetach
A successful updetach normally returns you to the shell once the PPP link is up. On failure it may print negotiation diagnostics; exact output depends on your local PPP build and the remote server. pptpsetup --start can do creation and connection in one go, but keeping them separate makes a bad configuration much easier to find.
Check the resulting interface and routes with ordinary read-only commands:
$ ip link show ppp0
$ ip route show dev ppp0
$ pgrep -a pppd
The interface may not be ppp0 if another PPP link already exists. A peer file being present only proves configuration was written, nothing about authentication, routing or reachability. If the connection fails, check the peer file, the credentials, the remote server's logs and the PPP system log before you start changing encryption settings.
Never delete a peer while it is in use. Identify the PPP process and stop it with whatever service manager or process procedure your host normally uses. A simple manually started link can usually be stopped with:
$ sudo pkill -TERM -x pppd
That kills every matching pppd process, so check pgrep -a pppd first and reach for your host's narrower service command if several links are active. Stopping PPP can drop traffic immediately, so confirm the interface is gone before removing its configuration.
Warning: --delete is destructive. It unlinks /etc/ppp/peers/office, removes every line containing office as a word from chap-secrets, and saves the old credentials file as /etc/ppp/chap-secrets.bkp. If you might need the configuration again, copy both files aside first, as in step 2.
$ sudo pptpsetup --delete office
$ sudo test ! -e /etc/ppp/peers/office && echo 'peer removed'
peer removed
$ sudo grep -n -w office /etc/ppp/chap-secrets || echo 'no office entries remain'
no office entries remain
$ sudo ls -l /etc/ppp/chap-secrets.bkp
The script refuses to continue if the peer file cannot be deleted: treat that as a useful stop, not something to push past. Never assume the credentials were removed just because the command ran. Check paths and permissions, then decide whether to restore from a verified backup. If deletion removes the wrong entry, stop using those credentials and restore only after checking the backup and its access permissions.