Dear Maintainer,

When connecting to a MS server 2019 VPN the package provided with current
stable and testing do not work.
Downgrading to the version in oldstable (2.4.9) does resolve the issue.

Command used:
Both, NetworkManager and pon name fail in the same way

This is the output of journalctl:
Mär 18 11:49:41 tux pppd[797505]: pppd 2.5.2 started by nin, uid 0
Mär 18 11:49:41 tux pppd[797505]: Using interface ppp0
Mär 18 11:49:41 tux pppd[797505]: Connect: ppp0 <--> /dev/pts/14
Mär 18 11:49:41 tux pppd[797505]: Modem hangup
Mär 18 11:49:41 tux pppd[797505]: Connection terminated.
Mär 18 11:49:41 tux NetworkManager[769235]: <info>  [1773830981.2463] manager:
(ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/16)
Mär 18 11:49:41 tux pppd[797505]: Exit.

The connection parameters are:
pty "pptp 192.168.22.22 --nolaunchpppd"
name username
remotename PPTP
require-mppe
file /etc/ppp/options.pptp
ipparam name
noauth

credentials for pon provided in /etc/ppp/chap-secrets

an additional datapoint:

-> Tried the same configuration on my fedora 43 machine.
-> in the same network
-> with the same configuration

working well there.

Hi akallabeth,

Thanks for reporting the issue. It's not clear from the included
information what's happening here, but the issue is more likely than not
in the pptp-linux package that provides the PPTP client, so I'm
reassigning the bug there.

If you can obtain more logging or output from pppd and/or pptp then I'm
sure this would be most helpful.

In the mean time I would urge you to consider a different VPN protocol
to PPTP. The protocol is obsolete and insecure and has multiple
well-documented vulnerabilities. I understand you may be forced to use
it for various reasons, but if this something new you're setting up,
please look at setting up something different.

Best regards,
Chris

Debian-maintainer of pptp-linux here.

Chris Boot wrote...

Seems sensible, let's see where this goes.

Indeed. Additionally, in the original bug report you wrote:

| Downgrading to the version in oldstable (...) does resolve the issue.

Can you describe this downgrade, or re-check? Did you downgrade
pptp-linux as well, so from 1.10.0-2 to 1.10.0-1?

Otherwise, as I do not have a MS server 2019 available, testing will be
a bit difficult. Are you capable of building Debian packages locally?
Then disabling the patches introduced in version -2 was the next thing
to try. Of those, only

| cherry-pick/1599550704.1.10.0-7-g194620e.feature-terminate-from.patch

would have the potential to actually harm the connection. So this all is
a bit weird.

Indeed.

    Christoph

Maintainer of pptpd and pptp-linux here.

Additional debug logging using "debug dump" in the connection
parameters would go further to explain the reported problem.

Output from pptp-linux itself should also be useful.  journalctl has
only provided output from pppd.

Capturing PPTP negotiation and GRE packets using tcpdump may also be
useful.

https://pptpclient.sourceforge.net/howto-diagnosis.phtml is quite old,
but has some useful tips.

Check for any packet filtering on the client system.

The "Feature: terminate-from" patch from 2020 is unlikely to have
caused this problem, but I'm watching to see if it does.

Reinforcing what Chris and Christoph have said; it is a really bad
plan to use PPTP with MPPE, as it is insecure.  If you are forced to
use it by some directive from above, then it is likely intended to
oversee your communications.  In that case, it is best to disable MPPE
entirely, to reduce the cost of oversight, as a graceful gesture.
Unlikely to be related to the reported problem though.

Hi,

did a apt source ppp/oldstable and a dpkg-buildpackage (with some
adjustments to fix the incompatible pointer type errors) and force
installed the package.

it did connect after downgrading the package.

Just retried, the change of the pptp-linux to oldstable (or current
stable) did not change anything, but downgrading ppp did resolve it.

as I already wrote to Chris (did hit reply instead of replay all, sorry)
this is just a test setup of virtual machines where the PPTP is more or
less just a connection to a different LAN, the encryption is not relevant.

Regarding debugging, can you help there? The pptp/ppp stuff shows its
age and is a little hard to figure out how to properly debug.

can do it in a VM so I can just check out the git repo and do a bisect
if that helps. (would need a little help with the build options there
though)

regards

Add "debug dump" to your connection parameters, e.g. after noauth.

After connection attempt fails, look at journalctl as you did before.
There may be a bit more detail, but not if the hangup happens quickly.

Also look at syslog.  pptp is so old that's where it logs.

pptp has a debug flag for additional output to syslog.

It's good you've identified changes in ppp that have caused this.
That has happened before.  A bisect of those changes may help.  Or
a scan of the changes from 2.4.9 to 2.5.2, paying attention to
anything to do with the pty option or implementation.  I've counted
the commits, and it's a big job, so a bisect would be easier.

So, added 'debug dump' to the options and ran the connection sequence
with the ppp package from debian/stable (failed.txt) and the self
compiled form debian/oldstable (success.txt)

Ok, I've identified 66a8c74c3f73d7480a09923a225b56b8829ae790 as the
first bad commit.

with 2a7caa2b79ff1edd5d19aa8c41d5614e526f1b93 I can normally connect.

What I do not understand is how Fedora is working with ppp v2.5.1 which
should contain the bad commit

10:50 $ git tag --contains 66a8c74c3f73d7480a09923a225b56b8829ae790
ppp-2.5.0
ppp-2.5.1
v2.5.0
v2.5.1
v2.5.2


regards

Update:

looks like the previous bad commit was not the right one.
66a8c74c3f73d7480a09923a225b56b8829ae790 messed up installation paths
and was using /usr/etc/ppp for configuration files (which I did not have
prepared).
Keeping this in mind I now I can use
76016e1b948b7d9675b4e0750d1f943d96d9523b as the last one working.

Good test results, thanks.

pppd 2.5.2 offers 40-bit MPPE instead of 128-bit MPPE, the peer offers
128-bit MPPE and MPPC, and this causes pppd to stop LCP with "MPPE
required but peer negotiation failed".

During the stop, pppd 2.5.2 rejects 128-bit MPPE but advises MPPC is
okay.  The peer then explicitly counter-proposes 128-bit MPPE.

The options are improperly dumped; /etc/localtime is referenced, and
certain options are not printed.  Perhaps they are not printable, or
not parsed.

The require-mppe option, which is critical, is not dumped.

Please check your options files for unconventional text, such as
carriage-returns or text outside ASCII or UTF-8.  hexdump -C may help.

On the other hand, the debug and dump options were obeyed even though
they were not dumped.

Try the require-mppe-128 option instead of require-mppe.

ba7f7e0 is the commit after the last one that worked for you.  The
changes there are extensive; next step would be to break the commit
into smaller changes until you find which one does it.

References:

https://pptpclient.sourceforge.net/howto-diagnosis.phtml#mppe_bits
https://pptpclient.sourceforge.net/howto-diagnosis.phtml#confreqacknakrej