Hello all,
I've been using the 64-bit version of Suse Linux Professional on a dual AMD
Opteron system since the first x86_64 release (= Suse 9.1). Ever since that
time, I've been trying to establish a PPTP VPN connection to my company's
VPN gateway. However, all my attempts were unsuccessful. Each time a new
release came out, I upgraded to this release in the hope that the problem
would be fixed. Currently, I'm running Suse Linux Professional 9.3. But
still, the problem has not been resolved.
In the meantime I discovered that I can succesfully establish a PPTP VPN
connection using MS-CHAPv2 in the 32-bit version of Suse (tested under
VMWare). In the 64-bit version of the PPTP-client, the whole system freezes
when the PPTP-connection is being established. I use pptp-command to setup
and establish the VPN connection.
Below are the specs of my system configuration :
Tyan dual Opteron mainboard
Dual AMD Opteron 240
Suse 9.3 Professional (x86_64 version)
Kernel 2.6.11.4-20a-smp
pptp-1.5.0-3
ppp-2.4.3-9
smpppd-1.58-6
/etc/ppp/chap-secrets
myusername PPTP mypasswd
PPTP myusername mypasswd
/etc/ppp/options.pptp
lock
noauth
nobsdcomp
nodeflate
require-mppe
refuse-eap
mtu 1000
mru 1000
lcp-echo-failure 10
lcp-echo-interval 10
/etc/ppp/peers/myvpnconnection
# Server IP: 100.100.100.100
# Route: add -host 100.100.100.100 gw DEF_GW
# Route: add -net 192.168.32.0/24 dev TUNNEL_DEV
# Route: add -net 192.168.1.0/24 dev TUNNEL_DEV
name myusername
remotename PPTP
file /etc/ppp/options.pptp
When I enable debugging, this is what's being logged :
May 28 17:01:51 linux pptp[9330]: anon log[main:pptp.c:243]: The synchronous pptp option is NOT activated
May 28 17:01:51 linux pptp[9333]: anon log[ctrlp_rep:pptp_ctrl.c:243]: Sent control packet type is 1 'Start-Control-Connection-Request'
May 28 17:01:51 linux pptp[9333]: anon log[ctrlp_disp:pptp_ctrl.c:721]: Received Start Control Connection Reply
May 28 17:01:51 linux pptp[9333]: anon log[ctrlp_disp:pptp_ctrl.c:755]: Client connection established.
May 28 17:01:52 linux pptp[9333]: anon log[ctrlp_rep:pptp_ctrl.c:243]: Sent control packet type is 7 'Outgoing-Call-Request'
May 28 17:01:52 linux pptp[9333]: anon log[ctrlp_disp:pptp_ctrl.c:841]: Received Outgoing Call Reply.
May 28 17:01:52 linux pptp[9333]: anon log[ctrlp_disp:pptp_ctrl.c:880]: Outgoing call established (call ID 0, peer's call ID 0).
May 28 17:01:52 linux kernel: CSLIP: code copyright 1989 Regents of the University of California
May 28 17:01:52 linux kernel: PPP generic driver version 2.4.2
May 28 17:01:52 linux pppd[9330]: pppd 2.4.3 started by root, uid 0
May 28 17:01:52 linux pppd[9330]: using channel 1
May 28 17:01:52 linux pppd[9330]: Using interface ppp0
May 28 17:01:52 linux pppd[9330]: Connect: ppp0 <--> /dev/pts/0
May 28 17:01:52 linux pppd[9330]: sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x123e4040> <pcomp> <accomp>]
May 28 17:01:54 linux pppd[9330]: rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x74cb5b96> <pcomp> <accomp>]
May 28 17:01:54 linux pppd[9330]: sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x74cb5b96> <pcomp> <accomp>]
May 28 17:01:54 linux pppd[9330]: rcvd [LCP ConfAck id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x123e4040> <pcomp> <accomp>]
May 28 17:01:54 linux pppd[9330]: sent [LCP EchoReq id=0x0 magic=0x123e4040]
May 28 17:01:54 linux pppd[9330]: rcvd [LCP EchoReq id=0x0 magic=0x74cb5b96]
May 28 17:01:54 linux pppd[9330]: sent [LCP EchoRep id=0x0 magic=0x123e4040]
May 28 17:01:54 linux pppd[9330]: rcvd [CHAP Challenge id=0x1 <cbbcca90310f0eaeacc892c91875ecf8>, name = "pptpsvr"]
After this, the system freezes. Apparently something goes wrong during the MS-CHAPv2 handshake, but I'm not a programmer to figure this out.
Does someone has a similar problem? Can this problem be fixed?
I really want to keep on working with the 64-bit version. The PPTP-problem is the only reason for still having a Windows system in the closet.
So, if someone can come up with a fix, I will be very happy to dump this M$-system.
I really appreciate any of your help!
Kind regards,
Bart.