PPTP und MSCHAP-V2

Wed Jan 29 13:18:02 CET 2003

On Wed, Jan 29, 2003 at 10:47:26AM +0100, Markus Wigge wrote:
> Ok, dann habe ich zumindest schonmal richtig vermutet ... hier noch der
> Log-Auszug der gescheiterten Verbindung (/var/log/debug):

Schoen umgebrochen *grummel*

> pppd[16880]: sent [LCP ConfReq id=0x1 <asyncmap 0x0>  <auth chap 81> <magic 0x4adc43d0> <pcomp> <accomp>]
> pppd[16880]: rcvd [LCP ConfReq id=0x0 <magic 0x3f223d19> <pcomp> <accomp> <callback CBCP> <mrru 1614> <endpoint [local:8e.c6.4b.cd.d1.5c.4f.dd.96.ff.4f.dc.76.77.80.51.00.00.00.03]>]
> pppd[16880]: sent [LCP ConfRej id=0x0 <mrru 1614>]
> pppd[16880]: rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap 81> <magic 0x4adc43d0> <pcomp> <accomp>]
> pppd[16880]: rcvd [LCP ConfReq id=0x1 <magic 0x3f223d19> <pcomp> <accomp> <callback CBCP> <endpoint [local:8e.c6.4b.cd.d1.5c.4f.dd.96.ff.4f.dc.76.77.80.51.00.00.00.03]>]
> pppd[16880]: sent [LCP ConfAck id=0x1 <magic 0x3f223d19> <pcomp> <accomp> <callback CBCP> <endpoint [local:8e.c6.4b.cd.d1.5c.4f.dd.96.ff.4f.dc.76.77.80.51.00.00.00.03]>]
> pppd[16880]: sent [LCP EchoReq id=0x0 magic=0x4adc43d0]

Normales LCP wobei der client CBCP (Call Back Control Protocol)
requested was der server nicht unterstuetzt und daher Rejected.

> pppd[16880]: sent [CHAP Challenge id=0x1 <8311f9edd9fb2d5d7048f8fb91bcc26f>, name = "vpn-gw1"]
> pppd[16880]: rcvd [LCP code=0xc id=0x2 3f 22 3d 19 4d 53 52 41 53 56 35 2e 30 30]
> pppd[16880]: sent [LCP CodeRej id=0x2 0c 02 00 12 3f 22 3d 19 4d 53 52 41 53 56 35 2e 30 30]
> pppd[16880]: rcvd [LCP code=0xc id=0x3 3f 22 3d 19 4d 53 52 41 53 2d 31 2d 5a 48 41 44 55 4d]
> pppd[16880]: sent [LCP CodeRej id=0x3 0c 03 00 16 3f 22 3d 19 4d 53 52 41 53 2d 31 2d 5a 48 41 44 55 4d]
> pppd[16880]: rcvd [LCP EchoRep id=0x0 magic=0x3f223d19]
> pppd[16880]: rcvd [CHAP Response id=0x1 <8d3ad2407b075cfad65f0c50941d14ad0000000000000000fa9bffafc5632f856f34faf69f468b57ddc2f2eeddbc105f00>, name = "test"]
> pppd[16880]: sent [CHAP Success id=0x1 "S=0471ED92372BC04BA8A82070B1C8F04558C34551"]

Authentisierung - erfolgreich ...

> pppd[16880]: cbcp_open
> pppd[16880]: cbcp_req CONF_NO
> pppd[16880]: sent [CBCP Request id=0x1 < NoCallback>]
> pppd[16880]: rcvd [CBCP Response id=0x1 < NoCallback>]
> pppd[16880]: CBCP_RESP received
> pppd[16880]: length: 2
> pppd[16880]: Callback: none
> pppd[16880]: cbcp_ack cb_type=2
> pppd[16880]: cbcp_ack CONF_NO
> pppd[16880]: sent [CBCP Ack id=0x1 < NoCallback>]

Kein callback

> pppd[16880]: sent [IPCP ConfReq id=0x1 <addr 10.0.1.1> <compress VJ 0f 01>]
> pppd[16880]: sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <mppe 1 0 0 60> <bsd v1 15>]
> pppd[16880]: rcvd [CCP ConfReq id=0x4 <mppe 1 0 0 e1>]
> pppd[16880]: sent [CCP ConfNak id=0x4 <mppe 1 0 0 60>]
> pppd[16880]: 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>]
> pppd[16880]: sent [IPCP ConfRej id=0x5 <ms-wins 0.0.0.0> <ms-wins 0.0.0..0>]
> pppd[16880]: rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
> pppd[16880]: sent [IPCP ConfReq id=0x2 <addr 10.0.1.1>]
> pppd[16880]: rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
> pppd[16880]: sent [CCP ConfReq id=0x2 <mppe 1 0 0 60>]
> pppd[16880]: rcvd [CCP ConfReq id=0x6 <mppe 1 0 0 40>]
> pppd[16880]: sent [CCP ConfRej id=0x6 <mppe 1 0 0 40>]
> pppd[16880]: rcvd [IPCP ConfReq id=0x7 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
> pppd[16880]: sent [IPCP ConfNak id=0x7 <addr 10.0.1.2> <ms-dns1 80.66.11.20> <ms-dns3 80.66.11.20>]
> pppd[16880]: rcvd [IPCP ConfAck id=0x2 <addr 10.0.1.1>]
> pppd[16880]: rcvd [CCP ConfNak id=0x2 <mppe 1 0 0 40>]
> pppd[16880]: sent [CCP ConfReq id=0x3]
> pppd[16880]: rcvd [LCP TermReq id=0x8 "?\"=\031\000<\37777777715t\000\000\002\37777777746"]
> pppd[16880]: cbcp_lowerdown
> pppd[16880]: sent [LCP TermAck id=0x8]
> kernel: compress rejected: opt_len=32,o[0]=12,o[1]=6

IPCP (Internet Protocol Control Protocol) verhandelt die IP Addresse
und DNS und Wins server und ist erfolgreich (Beiseitiges ConfAck)

Parallel dazu wird CCP (Call Compression Protocol) verhandelt mit
MPPE (Microsoft Point to Point Encryption).

Beim CCP verweigert die Client seite die verfuegbaren protokolle
(BSD, deflate etc) will aber MPPE mit anderen Parametern als der
Server was dazu fuehrt das die sich nicht einig werden und
schlussendlich mit ConfNAK das mppe verweigern. Darauf bietet
der Server eine verbindung ohne compression und verschluesselung
an "sent [CCP ConfReq id=0x3]" was dazu fuehrt das der client die
Verbindung trennt.

Massgebliche RFCs
RFC1661 -     PPP - http://www.ietf.org/rfc/rfc1661.txt
RFC1962 -     CCP - http://www.ietf.org/rfc/rfc1962.txt
RFC1332 -    IPCP - http://www.ietf.org/rfc/rfc1332.txt
RFC3078 -    MPPE - http://www.ietf.org/rfc/rfc3078.txt
RFC1334 -    AUTH - http://www.ietf.org/rfc/rfc1333.txt
RFC1994 -    CHAP - http://www.ietf.org/rfc/rfc1994.txt
RFC2433 -  MSCHAP - http://www.ietf.org/rfc/rfc2433.txt
RFC2759 - MSCHAP2 - http://www.ietf.org/rfc/rfc2759.txt
RFC2509	-  VJCOMP - http://www.ietf.org/rfc/rfc2509.txt
RFC1877 -  PPPDNS - http://www.ietf.org/rfc/rfc1877.txt
RFC1570 - LCPEXT  - http://www.ietf.org/rfc/rfc1570.txt

Lesen, verstehen, problem beheben.

Flo
-- 
Florian Lohoff                  flo at rfc822.org             +49-5201-669912
                        Heisenberg may have been here.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lug-owl.de/pipermail/linux/attachments/20030129/5783cdc8/attachment.sig>