Pptp VPN problem, LCP: timeout sending Config-Requests

Check the ifconfig for the device name concerning the vpn. Your log may be using the servers device name. Shouldn't, but it's better to confirm.

And try the autoneg on.

Setting the vpn device manually will probably be overwritten by the configuration file. Better to set it either in the options or main config file to ensure its use.

Try the synchronous line, maybe adding a duplex line as well to have it writable, but that may be set by the server. Without knowing more about the connection config it is hard to narrow it further.

I put off because the error specifically stated that "autonegotiation is unset or enabled."

So I thought the off option would mean that the network interface will stop trying to automatically negotiate the link speed and duplex settings called by the speed and duplex options.

Anyway, I definitely don't want to hijack the thread - so that I could better view the preview, I accidentally out-of-hand, closed the prompt which mentioned I could message you with the above explanation and further check on my understanding. Didn't even know I could message someone to be honest, never tried.

1 Like

You can DM anyone. Right click their name and click message (maybe a left click). I normally help out here from my phone, which is just a long press.

If the server is expecting autoneg, having this off will cause errors as well. I was going by the first option, unset, though it wouldn't hurt to try off. If one is configured for it and the other isn't, it will fail.

This one I tried, whitout success. I'm pretty sure I must change something manually in a config file.

I will check the other advises below this one, many answers during the night !

You're spot on. It's a configuration file that is misaligned with the endpoint:

  • run the following on the configuration files.. I hope you are using dpkg so this will work after the next kernel update:
    sudo dpkg-query -S [PATH-TO-CONFIG]
    would be worthwhile to back that configuration file up somewhere with a .BAK extension and then restore it from package:
    sudo dpkg --force-confmiss -i [PACKAGE-NAME]

from there you could use a diff to compare the two files in order to hopefully verify they are in line with your endpoint configuration.

I've done # sudo dpkg-query -S /etc/ppp/
I see that my ppp.options as changed a lot, BUT when I try to connect to the VPN, it act like it doesn't use this options file !

I will try to search where the "other" config is. Strange !

If I were using command line to connect to VPN, I think it would work like it was, knowing which file config it uses.
Sometimes graphical interface aren't the best option, you loose control.

If I show you a log from when it was working OK, can it help you ?

And in /etc/pptpd.conf it specify : option /etc/ppp/pptpd-options

I don't understand why it does not seem to use it. Maybe I need to reboot or restart a service.

I tried to create a command line connexion to the VPN, creating a file in /etc/ppp/peers following the instructions on this web page : How to setup PPTP VPN Connection on Ubuntu 20.x

When I try to connect via command line, I get this in syslog:

Mar 31 11:34:19 Linux-iMac NetworkManager[897]: [1680276859.9252] manager: (ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/3830)
Mar 31 11:34:19 Linux-iMac systemd-udevd[43525]: ppp0: Failed to get link config: No such device
Mar 31 11:34:19 Linux-iMac pppd[43523]: using channel 3896
Mar 31 11:34:19 Linux-iMac pppd[43523]: Using interface ppp0
Mar 31 11:34:19 Linux-iMac pppd[43523]: Connect: ppp0 <--> /dev/pts/3
Mar 31 11:34:19 Linux-iMac pppd[43523]: Script xxx.xxx.xxx.xxx --nolaunchpppd --debug finished (pid 78265), status = 0x7f
Mar 31 11:34:19 Linux-iMac pppd[43523]: Modem hangup
Mar 31 11:34:19 Linux-iMac pppd[43523]: Connection terminated.

I don't understand why it refers to /org/freedesktop/NetworkManager/Devices/3830

Interesting :

I did a test with: telnet IP_VPN_SERVER 1723

It connect, obviously it's not usable, but still shows something.

Log of this in syslog :

Mar 31 14:02:49 Linux-iMac whoopsie[1989]: [14:02:49] offline
Mar 31 14:02:49 Linux-iMac dbus-daemon[891]: [system] Activating via systemd: service name='org.freedesktop.nm_dispatcher' unit='dbus-org.freedesktop.nm-dispatcher.service' requested by ':1.9' (uid=0 pid=892 comm="/usr/sbin/NetworkManager --no-daemon ")
Mar 31 14:02:49 Linux-iMac systemd[1]: Starting Network Manager Script Dispatcher Service...
Mar 31 14:02:49 Linux-iMac dbus-daemon[891]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
Mar 31 14:02:49 Linux-iMac systemd[1]: Started Network Manager Script Dispatcher Service.
Mar 31 14:02:51 Linux-iMac NetworkManager[892]: [1680285771.7660] manager: NetworkManager state is now CONNECTED_GLOBAL
Mar 31 14:02:51 Linux-iMac whoopsie[1989]: [14:02:51] The default IPv4 route is: /org/freedesktop/NetworkManager/ActiveConnection/1
Mar 31 14:02:51 Linux-iMac whoopsie[1989]: [14:02:51] Not a paid data plan: /org/freedesktop/NetworkManager/ActiveConnection/1
Mar 31 14:02:51 Linux-iMac whoopsie[1989]: [14:02:51] Found usable connection: /org/freedesktop/NetworkManager/ActiveConnection/1
Mar 31 14:02:52 Linux-iMac whoopsie[1989]: [14:02:52] online
Mar 31 14:03:01 Linux-iMac systemd[1]: NetworkManager-dispatcher.service: Succeeded.

Hi @doalex,

Please understand that I have no prior experience with this process but I wanted to attempt to connect the dots and learn a few things about this as I go; please forgive me if any of this has already been asked/answered. At the very least I hope this prompts some :bulb: for the more experienced Linux users so that they might be able to help you further.

To that end, I decided to try and throw something together based on your input and on the Ubuntu pptp manpage, as well as the Linux pppd manpage.

Are you trying to force your /etc/pptpd.conf file to use a specific options file? If so, maybe try to change the line in the .conf from

To: option /etc/ppp/options.pptp
This might tell the PPTP server to use the options.pptp file located in /etc/ppp/ as the configuration file for all PPTP connections.
Then: sudo service pptpd restart to restart service for changes to take effect.


From man pppd:

OPTIONS FILES
       Options  can  be  taken  from  files as well as the command line.  Pppd
       reads  options  from   the   files   /etc/ppp/options,   ~/.ppprc   and
       /etc/ppp/options.ttyname  (in that order) before processing the options
       on the command line.  (In fact, the command-line options are scanned to
       find  the  terminal  name before the options.ttyname file is read.)  In
       forming the name of the options.ttyname file, the initial /dev/ is  re‐
       moved  from  the  terminal name, and any remaining / characters are re‐
       placed with dots.

       An options file is parsed into a series of words, delimited  by  white‐
       space.   Whitespace  can be included in a word by enclosing the word in
       double-quotes (").  A backslash (\) quotes the following character.   A
       hash  (#)  starts a comment, which continues until the end of the line.
       There is no restriction on using the file or call options within an op‐
       tions file.

I think this is implied, but specific options files can be specified for individual connections in the /etc/ppp/peers location. These files are named after the connection they apply to, and contain options specific to that connection.

To force the PPTP client to always use /etc/ppp/options.pptp configuration/options file for your specific connection in the .../peers location, you can try to also add the line...

  • pty "pptp your_pptp_server_name --nolaunchpppd --debug --logstring PPTP"
    • --logstring PPTP at the end is just the name that will be given to the log that will be created for debugging purposes.
      • The log file will be created in the same directory as the configuration file and will be named PPTP.log

...to your plain text peers file which I think you would find or create at /etc/ppp/peers/your_pptp_server_name

After adding the line noted above to the peers file, you might be able to start the VPN connection with: sudo pon your_vpn_server_name.

Your client might then use your server name you chose and prevent launching a local pppd process which would use the default configuration file in/etc/ppp/options; In theory, it would instead use the options file you created at /etc/ppp/options.pptp

When you use the command line, I read that it may also be possible to specify an options file explicitly using the -o command line option when starting the pppd process. But I can't verify that and I couldn't find mention of that when running man pppd in terminal.


call name
              Read additional options from the file /etc/ppp/peers/name.
              This file may contain privileged options, such as noauth,
              even if pppd is not being run by root.  The name string
              may not begin with / or include .. as a pathname
              component.  The format of the options file is described
              below.

Using an example format for a peers file, and with the above excerpt from Linux pppd manpage in mind:

# Name of the remote PPTP server
remote your_pptp_server_name

# Options to be used with the PPP connection
pty "pptp your_pptp_server_name --nolaunchpppd --debug --logstring PPTP"

# User authentication information
name my_username
password my_password

# Other options
noauth
nobsdcomp
nodeflate
  • You can have the pppd process start a PPTP connection using a specified options.pptp file and the settings in the your_pptp_server_name plain text file you created in the /etc/ppp/peers/... location:

    • sudo pppd call your_pptp_server_name options /etc/ppp/options.pptp should work if you configured the /etc/ppp/options.pptp file with the necessary PPTP client options and replaced your_pptp_server_name with the correct name you specified in the options file.`

Hi @ajo001 !

I just tried your two suggestion, but I get the same error message as before.

Mar 31 23:55:37 Linux-iMac portmaster-start[910]: #033[33m230331 23:55:37.145 on/nfq/nfq:190 :arrow_forward: WARN 381#033[0m nfqueue: failed to parse payload: Unable to decode PPPType 49185

Thanks though for this very well elaborated answer !

Darn. I tried.

Out of curiosity, what was the PPTP.log file showing afterward? Anything you weren't expecting or already seeing?

There was no log file after... I just retried again to be 100 % sure.

I always open a second Terminal with tail -f /var/log/syslog to look live at what happens.

Oh ok. Sorry I've had a few tonight.

Maybe the PPTP.log file is only populated with data after a connection is successfully established and what's logged are data having to do with details of the traffic?

Lol I've given it my all, so hopefully a lightbulb :bulb: appears over another experienced reader's head.

Sorry you still can't get it to work. :duck::duck:🪿

2 Likes

No problem @ajo001 ! Your help is greatly appreciated !
Passionate people about Linux are the best !

I don't know why there is no log produce, but syslog seems to be really the best place to look at. I didn't found a more complete log so far.

Since I still have Zerotier working to connect to my work, this isn't too tragic for me. If it wasn't I think I would reinstall Zorin Linux from scratch.
I really don't like to do this, loosing all my setup. I will look for a cloud solution to preserve my user home directory if I do that !

Thanks again !

1 Like

You could always use Aravisian's Easily Reinstall tutorial if it comes to that.

Thank you for this link, @337harvey ! I will probably use it in a near future. Also thank you to @Aravisian for this tutorial.
I'm really happy of my choice to get back to Linux and particularly Zorin distro. Nice community here !

1 Like

Update :

I found the problem, and it is stupid...
I installed Portmaster on my Linux system, after viewing a vlogger talking about it. This was the problem.
I did shut down this service, and bingo ! Connect to the VPN without any problem !

Eventually, I will check closer to permit VPN inside Portmaster (or just desinstall it!).

Thanks to everyone here again !

3 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.