Does a Shared pppd Options File Break Your Other VPN?

You add one line to make a stubborn PPTP profile connect, and a week later the L2TP client that had worked for months stops. The obvious reading is that the two protocols now conflict. More often both clients start pppd, both read the same defaults, and the line you added was never scoped to the profile you were fixing. The shared option file is the coupling, and the protocols are innocent.

What a client inherits when it starts

A PPP-based client rarely builds its command line from nothing. It starts pppd, which reads system defaults, then any user or terminal file, then arguments the client passes, and the client may also point it at a peer file. Each of those layers can carry a plugin, an authentication method or a route directive, and the first layer that sets a protected option can lock it against later changes.

So the useful question is not which VPN is broken but which layer supplied the setting. A client that generates its own arguments looks self-contained and still inherits everything the system file holds.

Attribute the line before you change it

Start by looking at the process that is running while a connection is up. The command line shows which files were passed explicitly, and anything not named there came from a default path.

ps -o pid=,args= -C pppd

If the argument list contains a peer name, read that file. If it does not, the setting you are chasing lives in a shared path. The pppd manual lists the order in which those files are read and which options a normal user cannot override, which is why a later line sometimes does nothing at all. A protected option such as a plugin path cannot be replaced by a later user-level line, so editing the wrong file has no visible effect.

The plugin line that follows every client

A plugin loaded in the system file is the worst offender because it changes what a new PPP process tries to load no matter which button the user pressed. The L2TP plugin is the classic example: correct for one profile, meaningless or harmful for a PPTP profile that starts from the same defaults.

Move it to a peer file the client selects, or to the client's own per-connection settings when it supports them. Deleting it outright repairs the second client and breaks the first, which is how these problems travel between teams.

Verify each client after the move

Test both connections from the same machine, one after the other, and read the negotiated options rather than the success dialog. The dump below prints the option set pppd actually assembled, which is the only list that matters.

sudo pppd call office debug dump

Repeat for the second client and compare the two outputs. The option you moved should appear in exactly one of them. If it appears in both, the client is regenerating it and the fix belongs in that profile rather than the shared file. Record where the setting now lives next to the connection, so the next person does not rediscover the coupling by breaking it again.