Debiam 5.0: PPTPD <--> WinXP PPTP client CHAPv2/MPPE problem

TVT · 08-30-2009, 10:08 AM

Hi!

I have run into the unexpected problem connecting WinXP to Debian 5.0 over PPTP. WinXP client complaining that "Error 741: The local computer does not support required encryption type" when attempting to "register computer on the network".

Here is the pptpd-options contents:

Code:

# Name of the local system for authentication purposes
# (must match the second field in /etc/ppp/chap-secrets entries)
name pptpd

# Optional: domain name to use for authentication
# domain mydomain.net

# Strip the domain prefix from the username before authentication.
# (applies if you use pppd with chapms-strip-domain patch)
#chapms-strip-domain


# Encryption
# Debian: on systems with a kernel built with the package
# kernel-patch-mppe >= 2.4.2 and using ppp >= 2.4.2, ...
# {{{
refuse-pap
refuse-chap
refuse-mschap
# Require the peer to authenticate itself using MS-CHAPv2 [Microsoft
# Challenge Handshake Authentication Protocol, Version 2] authentication.
require-mschap-v2
# Require MPPE 128-bit encryption
# (note that MPPE requires the use of MSCHAP-V2 during authentication)
require-mppe-128
#require-mppe
# }}}


# Network and Routing

# If pppd is acting as a server for Microsoft Windows clients, this
# option allows pppd to supply one or two DNS (Domain Name Server)
# addresses to the clients.  The first instance of this option
# specifies the primary DNS address; the second instance (if given)
# specifies the secondary DNS address.
# Attention! This information may not be taken into account by a Windows
# client. See KB311218 in Microsoft's knowledge base for more information.
#ms-dns 10.0.0.1
#ms-dns 10.0.0.2
ms-dns 192.168.0.128

# If pppd is acting as a server for Microsoft Windows or "Samba"
# clients, this option allows pppd to supply one or two WINS (Windows
# Internet Name Services) server addresses to the clients.  The first
# instance of this option specifies the primary WINS address; the
# second instance (if given) specifies the secondary WINS address.
#ms-wins 10.0.0.3
#ms-wins 10.0.0.4
ms-wins 192.168.0.128

# Add an entry to this system's ARP [Address Resolution Protocol]
# table with the IP address of the peer and the Ethernet address of this
# system.  This will have the effect of making the peer appear to other
# systems to be on the local ethernet.
# (you do not need this if your PPTP server is responsible for routing
# packets to the clients -- James Cameron)
proxyarp

# Debian: do not replace the default route
nodefaultroute


# Logging

# Enable connection debugging facilities.
# (see your syslog configuration for where pppd sends to)
debug

# Print out all the option values which have been set.
# (often requested by mailing list to verify options)
#dump


# Miscellaneous

# Create a UUCP-style lock file for the pseudo-tty to ensure exclusive
# access.
lock

# Disable BSD-Compress compression
nobsdcomp

noauth
nodeflate

Here is syslog excerpt:

Code:

Aug 30 17:29:17 server pptpd[6021]: MGR: Launching /usr/sbin/pptpctrl to handle client
Aug 30 17:29:17 server pptpd[6021]: CTRL: local address = 172.16.0.1
Aug 30 17:29:17 server pptpd[6021]: CTRL: remote address = 172.16.0.2
Aug 30 17:29:17 server pptpd[6021]: CTRL: pppd options file = /etc/ppp/pptpd-options
Aug 30 17:29:17 server pptpd[6021]: CTRL: Client 212.92.249.160 control connection started
Aug 30 17:29:17 server pptpd[6021]: CTRL: Received PPTP Control Message (type: 1)
Aug 30 17:29:17 server pptpd[6021]: CTRL: Made a START CTRL CONN RPLY packet
Aug 30 17:29:17 server pptpd[6021]: CTRL: I wrote 156 bytes to the client.
Aug 30 17:29:17 server pptpd[6021]: CTRL: Sent packet to client
Aug 30 17:29:19 server pptpd[6021]: CTRL: Received PPTP Control Message (type: 7)
Aug 30 17:29:19 server pptpd[6021]: CTRL: Set parameters to 100000000 maxbps, 64 window size
Aug 30 17:29:19 server pptpd[6021]: CTRL: Made a OUT CALL RPLY packet
Aug 30 17:29:19 server pptpd[6021]: CTRL: Starting call (launching pppd, opening GRE)
Aug 30 17:29:19 server pptpd[6021]: CTRL: pty_fd = 6
Aug 30 17:29:19 server pptpd[6021]: CTRL: tty_fd = 7
Aug 30 17:29:19 server pptpd[6021]: CTRL: I wrote 32 bytes to the client.
Aug 30 17:29:19 server pptpd[6022]: CTRL (PPPD Launcher): program binary = /usr/sbin/pppd
Aug 30 17:29:19 server pptpd[6022]: CTRL (PPPD Launcher): local address = 172.16.0.1
Aug 30 17:29:19 server pptpd[6022]: CTRL (PPPD Launcher): remote address = 172.16.0.2
Aug 30 17:29:19 server pptpd[6021]: CTRL: Sent packet to client
Aug 30 17:29:19 server pppd[6022]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Aug 30 17:29:19 server pppd[6022]: pptpd-logwtmp: $Version$
Aug 30 17:29:19 server pptpd[6021]: CTRL: Received PPTP Control Message (type: 15)
Aug 30 17:29:19 server pptpd[6021]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Aug 30 17:29:19 server pppd[6022]: pppd 2.4.4 started by root, uid 0
Aug 30 17:29:19 server pppd[6022]: using channel 11
Aug 30 17:29:19 server pptpd[6021]: GRE: accepting packet #0
Aug 30 17:29:19 server pppd[6022]: Using interface ppp1
Aug 30 17:29:19 server pppd[6022]: Connect: ppp1 <--> /dev/pts/3
Aug 30 17:29:19 server pppd[6022]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x58fd3a50> <pcomp> <accomp>]
Aug 30 17:29:19 server pppd[6022]: rcvd [LCP ConfReq id=0x0 <mru 1400> <magic 0x57ea4e64> <pcomp> <accomp> <callback CBCP>]
Aug 30 17:29:19 server pptpd[6021]: GRE: Bad checksum from pppd.
Aug 30 17:29:19 server pppd[6022]: sent [LCP ConfRej id=0x0 <callback CBCP>]
Aug 30 17:29:19 server pptpd[6021]: GRE: accepting packet #1
Aug 30 17:29:19 server pppd[6022]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x58fd3a50> <pcomp> <accomp>]
Aug 30 17:29:19 server pptpd[6021]: GRE: accepting packet #2
Aug 30 17:29:19 server pppd[6022]: rcvd [LCP ConfReq id=0x1 <mru 1400> <magic 0x57ea4e64> <pcomp> <accomp>]
Aug 30 17:29:19 server pppd[6022]: sent [LCP ConfAck id=0x1 <mru 1400> <magic 0x57ea4e64> <pcomp> <accomp>]
Aug 30 17:29:19 server pppd[6022]: sent [LCP EchoReq id=0x0 magic=0x58fd3a50]
Aug 30 17:29:19 server pppd[6022]: MPPE required, but MS-CHAP[v2] auth not performed.
Aug 30 17:29:19 server pppd[6022]: sent [LCP TermReq id=0x2 "MPPE required but not available"]
Aug 30 17:29:19 server pptpd[6021]: GRE: accepting packet #3
Aug 30 17:29:19 server pptpd[6021]: GRE: accepting packet #4
Aug 30 17:29:19 server pptpd[6021]: GRE: accepting packet #5
Aug 30 17:29:19 server pppd[6022]: rcvd [LCP Ident id=0x2 magic=0x57ea4e64 "MSRASV5.10"]
Aug 30 17:29:19 server pptpd[6021]: GRE: accepting packet #6
Aug 30 17:29:19 server pppd[6022]: rcvd [LCP Ident id=0x3 magic=0x57ea4e64 "MSRAS-0-QWERTY"]
Aug 30 17:29:19 server pppd[6022]: rcvd [CCP ConfReq id=0x4 <mppe +H -M -S -L -D +C>]
Aug 30 17:29:19 server pppd[6022]: Discarded non-LCP packet when LCP not open
Aug 30 17:29:19 server pppd[6022]: rcvd [IPCP ConfReq id=0x5 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-wins 0.0.0.0> <ms-dns3 0.0.0.0> <ms-wins 0.0.0.0>]
Aug 30 17:29:19 server pppd[6022]: Discarded non-LCP packet when LCP not open
Aug 30 17:29:19 server pptpd[6021]: GRE: accepting packet #7
Aug 30 17:29:19 server pptpd[6021]: GRE: accepting packet #8
Aug 30 17:29:19 server pppd[6022]: rcvd [LCP EchoRep id=0x0 magic=0x57ea4e64]
Aug 30 17:29:19 server pppd[6022]: rcvd [LCP TermAck id=0x2 "MPPE required but not available"]
Aug 30 17:29:19 server pppd[6022]: Connection terminated.
Aug 30 17:29:19 server pppd[6022]: Exit.
Aug 30 17:29:19 server pptpd[6021]: GRE: read(fd=6,buffer=8058640,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Aug 30 17:29:19 server pptpd[6021]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Aug 30 17:29:19 server pptpd[6021]: CTRL: Reaping child PPP[6022]
Aug 30 17:29:19 server pptpd[6021]: CTRL: Client aaa.bbb.ccc.ddd control connection finished
Aug 30 17:29:19 server pptpd[6021]: CTRL: Exiting now
Aug 30 17:29:19 server pptpd[4029]: MGR: Reaped child 6021

The message "MPPE required but not available" looks quite strange because lsmod gives:

Code:

root@server:~# lsmod |fgrep ppp
ppp_deflate             4224  0
zlib_deflate           17656  1 ppp_deflate
zlib_inflate           14144  1 ppp_deflate
ppp_async               7488  0
crc_ccitt               2080  1 ppp_async
ppp_mppe                5700  0
pppoe                   8672  2
pppox                   3116  1 pppoe
ppp_generic            20028  9 ppp_deflate,ppp_async,ppp_mppe,pppoe,pppox
slhc                    5376  1 ppp_generic

Here's additional info:

Code:

root@server:~# uname -a
Linux server.yyy.zz 2.6.26-2-686 #1 SMP Fri Aug 14 01:27:18 UTC 2009 i686 GNU/Linux

Does anybody have any idea of the what's wrong with the kernel/PPTPD configuration?

neonsignal · 08-31-2009, 01:32 AM

Is the windows client doing 40 bit or 128 bit MPPE? I ask this,because your configuration is (appropriately) mandating 128 bit.

TVT · 08-31-2009, 10:22 AM

Quote:

Originally Posted by neonsignal

Is the windows client doing 40 bit or 128 bit MPPE? I ask this,because your configuration is (appropriately) mandating 128 bit.

WinXP as a client can support any of that encryptions but I personally prefer MPPE-128.

TVT · 08-31-2009, 10:53 AM

Oh, no!!! Why is this happening right to me right now???

I've made a small research and got the following results.

I've found a system with Debian 5.0 installed and setup a PPTPD it. I've figured out that WinXP makes PPTP connects successfully to it. Here is its kernel info:

Code:

root@gate:/etc/ppp# uname -a
Linux gate.yy.zz 2.6.26-2-686 #1 SMP Sun Jul 26 21:25:33 UTC 2009 i686 GNU/Linux

Than I've upgraded system to the latest state and ... the system stopped to correctly accept PPTP-connections (see above). Here is the new kernel info:

Code:

root@gate:/etc/ppp# uname -a
Linux gate.yy.zz 2.6.26-2-686 #1 SMP Fri Aug 14 01:27:18 UTC 2009 i686 GNU/Linux

So, guys, can anybody make any conclusion?