VPN (pptp) issue

I've been trying to configure a VPN connection to connect to work.
They provide a couple of perl scripts that start and stop the VNP connection, but these are quite old (designed for Scientific Linux 5.5) and assume that the interface will be "ppp0", however this interface does not exist (nor does it appear on running the start script).
An extra line in the output /sbin/route -n does appear showing a destination to the VPN server but with the same interface name as the normal network interface.
Modifying the script to use that does something, but I still can't connect to my desktop at work.

Without the VPN started I get a "connection timed out" error when I try to ssh to it, but with it I get "no route to host".

Unfortunately (a) I'm not networking expert and (b) the IT folks only understand Windows.

Any ideas what to try? Where to look for more useful messages? ...

Without the scripts nor your network config, it'll be very hard to help you... As you're a well-established user, I hate to do this to you but:

:+1: Welcome to Manjaro! :+1:

Please read this:

and post some more information so we can see what's really going on. Now we know the symptom of the disease, but we need some more probing to know where the origin lies...


P.S. If you enter a bit more details in your profile, we can also see which Desktop Environment you're using, which CPU/GPU you have, ...

At that stage what I was looking for as much as anything was where to find error/log messages at the system level. The scripts are rather horrid perl scripts from which I hope I will be able to spare you.

More useful is probably the output of pon as per the arch wiki (id's redacted):

sudo pon ralvpn debug dump logfd 2 nodetach
pppd options in effect:
debug           # (from command line)
nodetach                # (from command line)
logfd 2         # (from command line)
dump            # (from command line)
noauth          # (from /etc/ppp/peers/ralvpn)
name xxxxxxxxxx             # (from /etc/ppp/peers/ralvpn)
remotename ralvpn               # (from /etc/ppp/peers/ralvpn)
                # (from /etc/ppp/peers/ralvpn)
pty /usr/sbin/pptp xxx.xxx.xxx.xxx --nolaunchpppd                # (from /etc/ppp/peers/ralvpn)
crtscts         # (from /etc/ppp/options)
                # (from /etc/ppp/options)
asyncmap 0              # (from /etc/ppp/options)
lcp-echo-failure 4              # (from /etc/ppp/options)
lcp-echo-interval 30            # (from /etc/ppp/options)
hide-password           # (from /etc/ppp/options)
ipparam ralvpn          # (from /etc/ppp/peers/ralvpn)
proxyarp                # (from /etc/ppp/options)
nobsdcomp               # (from /etc/ppp/peers/ralvpn)
nodeflate               # (from /etc/ppp/peers/ralvpn)
require-mppe-128                # (from /etc/ppp/peers/ralvpn)
noipx           # (from /etc/ppp/options)
using channel 8
Using interface ppp0
Connect: ppp0 <--> /dev/pts/14
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xf359d7ab> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1400> <auth eap> <magic 0x3ef2ebd> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint [local:a6.81.c4.db.21.7e.43.55.95.f7.0d.d2.7e.bb.6f.9b.]>]
sent [LCP ConfRej id=0x0 <callback CBCP> <mrru 1614>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xf359d7ab> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x1 <mru 1400> <auth eap> <magic 0x3ef2ebd> <pcomp> <accomp> <endpoint [local:a6.81.c4.db.21.7e.43.55.95.f7.0d.d2.7e.bb.6f.9b.]>]
sent [LCP ConfAck id=0x1 <mru 1400> <auth eap> <magic 0x3ef2ebd> <pcomp> <accomp> <endpoint [local:a6.81.c4.db.21.7e.43.55.95.f7.0d.d2.7e.bb.6f.9b.]>]
sent [LCP EchoReq id=0x0 magic=0xf359d7ab]
rcvd [EAP Request id=0x0 Identity <No message>]
sent [EAP Response id=0x0 Identity <Name "xxxxxxxxxx">]
rcvd [LCP EchoRep id=0x0 magic=0x3ef2ebd]
rcvd [EAP Request id=0x1 type=0x1a...]
EAP: unknown authentication type 26; Naking
sent [EAP Response id=0x1 Nak <Suggested-type 13>]
rcvd [EAP Failure id=0x1]
EAP: peer reports authentication failure
sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
rcvd [LCP TermReq id=0x4 03 ef 2e bd 00 3c cd 74 00 00 03 2c]
sent [LCP TermAck id=0x4]
rcvd [LCP TermAck id=0x2 "Failed to authenticate ourselves to peer"]
Connection terminated.
Waiting for 1 child processes...
  script /usr/sbin/pptp xxx.xxx.xxx.xxx --nolaunchpppd, pid 53567
Script /usr/sbin/pptp xxx.xxx.xxx.xxx --nolaunchpppd finished (pid 53567), status = 0x0

And the output of route after setting up:

/sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    100    0        0 enp2s0
nnn.nnn.nnn.nnn UGH   0      0        0 enp2s0   U     100    0        0 enp2s0

The nnn. ... line is not there when the VPN has not been enabled.

If you're connecting to Micro$oft stuff, remove all authentication protocols except MSCHAP as a first step.

Managed to get a connection via the KDE network manager, which is a lot less hassle.
When I first set it up a few days ago it failed, but today I just told it to connect and it did.

There are now far more new lines in the /sbin/route -n output:

$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         UG    100    0        0 enp2s0   U     100    0        0 enp2s0


$ /sbin/route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface         U     50     0        0 ppp0         UG    100    0        0 enp2s0
nnn.nnn.nnn.6 UGH   0      0        0 enp2s0
nnn.nnn.nnn.6 UGH   100    0        0 enp2s0
nnn.nnn.nnn.10 UH    50     0        0 ppp0   U     100    0        0 enp2s0 UH    100    0        0 enp2s0

1 Like

In case it's useful to anyone else, here are the configuration settings needed (server names etc. redacted).



One extra note:
It seems that the regular network needs to be restarted after shutting down the VPN connection, otherwise a residual reference to the VPN in the routing tables prevents the VPN being restarted.

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

Forum kindly sponsored by