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.