detailed problem description

pppd-mppe_bug_report (text/plain), 6.26 KB, created by Viorel Tabara on 2006-08-23 00:04:13 UTC

--- Problem description ---

In my oppinion, a weird configured PPTP server, but (do) we need to be able to handle this(?).
For privacy issues the local IP is changed to 'lll.lll.lll.lll' and the remote one to 'rrr.rrr.rrr.rrr'.
**Test# 1 - MPPE required**
//
gws-1 ~ # pppd call PPTPS 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/options.pptp)
name myusername             # (from /etc/ppp/peers/PPTPS)
remotename PPTPS           # (from /etc/ppp/peers/PPTPS)
# (from /etc/ppp/options.pptp)
pty pptp vpn.pptpserver.ca --nolaunchpppd               # (from /etc/ppp/peers/PPTPS)
ipparam PPTPS              # (from /etc/ppp/peers/PPTPS)
nobsdcomp               # (from /etc/ppp/options.pptp)
nodeflate               # (from /etc/ppp/options.pptp)
require-mppe            # (from /etc/ppp/peers/PPTPS)
mppe-stateful           # (from /etc/ppp/peers/PPTPS)
using channel 26
Using interface ppp0
Connect: ppp0 <--> /dev/pts/7
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x76e571a9> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x76e571a9> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x76e571a9> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x76e571a9> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xe4 <mru 1500> <asyncmap 0xa0000> <auth chap MS-v2> <magic 0x3da09e8e> <pcomp> <accomp>]
sent [LCP ConfAck id=0xe4 <mru 1500> <asyncmap 0xa0000> <auth chap MS-v2> <magic 0x3da09e8e> <pcomp> <accomp>]
rcvd [CHAP Challenge id=0x2 <82efddd410f42c3be51b793e76562ca1>, name = "rrr.rrr.rrr.rrr"]
sent [CHAP Response id=0x2 <618ab33ca219bac5e142a942202b7c860000002026f4bf0024d806a0a5f1a62a4e1cc8aa4c8543ecc147a49a9878a9f100>, name = "myusername"]
rcvd [CHAP Success id=0x2 "S=AC6FDAB1F0B79A6A46A2AD163C95CA0B62291931"]
CHAP authentication succeeded
sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]
rcvd [IPCP ConfReq id=0x11 <addr rrr.rrr.rrr.rrr> <compress VJ 07 00>]
sent [IPCP TermAck id=0x11]
rcvd [CCP ConfNak id=0x1 <mppe -H -M +S +L -D +C>]
MPPE required but peer negotiation failed
sent [LCP TermReq id=0x2 "MPPE required but peer negotiation failed"]
rcvd [LCP TermAck id=0x2]
Connection terminated.
Waiting for 1 child processes...
script pptp vpn.athabascau.ca --nolaunchpppd, pid 32593
Script pptp vpn.athabascau.ca --nolaunchpppd finished (pid 32593), status = 0x0
//

**Test 2 - force no MPPE on the client**
//
gws-1 ~ # pppd call PPTPS debug dump logfd 2 nodetach nomppe
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/options.pptp)
name myusername             # (from /etc/ppp/peers/PPTPS)
remotename PPTPS           # (from /etc/ppp/peers/PPTPS)
# (from /etc/ppp/options.pptp)
pty pptp vpn.pptps.ca --nolaunchpppd               # (from /etc/ppp/peers/PPTPS)
ipparam PPTPS              # (from /etc/ppp/peers/PPTPS)
nobsdcomp               # (from /etc/ppp/options.pptp)
nodeflate               # (from /etc/ppp/options.pptp)
# (from /etc/ppp/peers/PPTPS)
nomppe          # (from command line)
mppe-stateful           # (from /etc/ppp/peers/PPTPS)
using channel 27
Using interface ppp0
Connect: ppp0 <--> /dev/pts/7
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xbccb08c1> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xbccb08c1> <pcomp> <accomp>]
sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0xbccb08c1> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0xbccb08c1> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0xc1 <mru 1500> <asyncmap 0xa0000> <auth chap MS-v2> <magic 0x3daea803> <pcomp> <accomp>]
sent [LCP ConfAck id=0xc1 <mru 1500> <asyncmap 0xa0000> <auth chap MS-v2> <magic 0x3daea803> <pcomp> <accomp>]
rcvd [CHAP Challenge id=0x2 <6b20c2de2c6f8175e1628d389aaa48a1>, name = "rrr.rrr.rrr.rrr"]
sent [CHAP Response id=0x2 <83b685341218c31f30dfb37bde571587000000105093bf00f0a4c0476e78dc274eeafc7576159f6cc361dfe14aa02cba00>, name = "myusername"]
rcvd [CHAP Success id=0x2 "S=1C838A6CFE542C8DDE05B15888A15AF8412A7D8F"]
CHAP authentication succeeded
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfReq id=0x2d <addr rrr.rrr.rrr.rrr> <compress VJ 07 00>]
sent [IPCP ConfAck id=0x2d <addr rrr.rrr.rrr.rrr> <compress VJ 07 00>]
rcvd [IPCP ConfNak id=0x1 <compress VJ 07 00> <addr lll.lll.lll.lll>]
sent [IPCP ConfReq id=0x2 <compress VJ 07 00> <addr lll.lll.lll.lll>]
rcvd [IPCP ConfAck id=0x2 <compress VJ 07 00> <addr lll.lll.lll.lll>]
local  IP address lll.lll.lll.lll
remote IP address rrr.rrr.rrr.rrr
Script /etc/ppp/ip-up started (pid 1924)
Script /etc/ppp/ip-up finished (pid 1924), status = 0x0
rcvd [CCP ConfReq id=0xa3 <mppe -H -M +S +L -D +C>]
sent [CCP ConfReq id=0x1]
sent [CCP ConfRej id=0xa3 <mppe -H -M +S +L -D +C>]
rcvd [CCP ConfAck id=0x1]
rcvd [CCP ConfReq id=0xa4]
sent [CCP ConfAck id=0xa4]
rcvd [CCP TermReq id=0xa5]
CCP terminated by peer
sent [CCP TermAck id=0xa5]
Compression disabled by peer.
rcvd [LCP TermReq id=0xc2]
LCP terminated by peer
Connect time 0.1 minutes.
Sent 22 bytes, received 22 bytes.
Script /etc/ppp/ip-down started (pid 1925)
sent [LCP TermAck id=0xc2]
Script /etc/ppp/ip-down finished (pid 1925), status = 0x1
Script pptp vpn.pptps.ca --nolaunchpppd finished (pid 1911), status = 0x0
Modem hangup
Connection terminated.
//

So we can see that this particular server does not accept MPPE during authentication and disconnects (test 1). Without MPPE the authentication is going fine, the server assigns the IP address (lll.lll.lll.lll) but will want to encrypt all the subsequent communication - the local ppp cannot handle it since it was started with 'nomppe'.

One solution would be to allow the authentication process to continue if the encryption is not required by the server.

Another solution would be to add an option 'nomppe_auth' which will know how to handle this weird behaviour - first authenticate with nomppe; second when the server asks to start the encryption handle it according to the settings in the configuration files.

This situation is NOT addressed in the Debian patch mention at http://pptpclient.sourceforge.net/howto-diagnosis.phtml#mppe_rbpnf.