network-manager-pptp unter Ubuntu 8.10

Nach dem Update auf Ubuntu 8.10 letzten Monat gingen meine VPN-Verbindungen über den Jordan. Ich also eben gerade meine Verbindung zum Firmennetzwerk neu eingerichtet und siehe da: Es funktioniert nicht.

In /var/log/syslog war Folgendes zu lesen:

Nov 24 17:12:32 laptop kernel: [ 1034.472477] PPP generic driver version 2.4.2
Nov 24 17:12:32 laptop modprobe: WARNING: Not loading blacklisted module ipv6
Nov 24 17:12:32 laptop pppd[7594]: pppd 2.4.4 started by root, uid 0
Nov 24 17:12:32 laptop pppd[7594]: Using interface ppp0
Nov 24 17:12:32 laptop pppd[7594]: Connect: ppp0 <--> /dev/pts/1
Nov 24 17:12:32 laptop pptp[7603]: nm-pptp-service-7589 log[main:pptp.c:314]: The synchronous pptp option is NOT activated
Nov 24 17:12:32 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 1 'Start-Control-Connection-Request'
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:739]: Received Start Control Connection Reply
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:773]: Client connection established.
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_rep:pptp_ctrl.c:251]: Sent control packet type is 7 'Outgoing-Call-Request'
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:858]: Received Outgoing Call Reply.
Nov 24 17:12:33 laptop pptp[7619]: nm-pptp-service-7589 log[ctrlp_disp:pptp_ctrl.c:897]: Outgoing call established (call ID 0, peer's call ID 5120).
Nov 24 17:12:34 laptop pppd[7594]: MS-CHAP authentication failed:
Nov 24 17:12:34 laptop pppd[7594]: CHAP authentication failed
Nov 24 17:12:34 laptop pppd[7594]: Connection terminated.
Nov 24 17:12:34 laptop NetworkManager: <info>  VPN plugin failed: 1

Sehr ungewöhnlich – Meine Zugangsdaten (Benutzername, Passwort und Domäne) waren im NetworkManager definitiv korrekt eingetragen.
Ich aktivierte in /etc/ppp/options die Definition “debug” und sah im syslog

Nov 24 17:34:26 laptop pppd[9661]: sent [LCP EchoReq id=0x0 magic=0x6fbd7073]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [LCP EchoReq id=0x0 magic=0xf9418ec]
Nov 24 17:34:26 laptop pppd[9661]: sent [LCP EchoRep id=0x0 magic=0x6fbd7073]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [CHAP Challenge id=0x9a <d25f15a6a126b77cba1ea38f32f093c6>, name = "pptp"]
Nov 24 17:34:26 laptop pppd[9661]: sent [CHAP Response id=0x9a <729e199b9717cc49aeacbf4f5f0fe79800000000000000002d555861ec2b61ebb1442f3519018527ad5879336be6323f00>, name = "$DOMAIN\\$BENUTZERNAME"]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [LCP EchoRep id=0x0 magic=0xf9418ec]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [CHAP Failure id=0x9a ""]
Nov 24 17:34:26 laptop pppd[9661]: MS-CHAP authentication failed:
Nov 24 17:34:26 laptop pppd[9661]: CHAP authentication failed
Nov 24 17:34:26 laptop pppd[9661]: sent [LCP TermReq id=0x2 "Failed to authenticate ourselves to peer"]
Nov 24 17:34:26 laptop pppd[9661]: rcvd [LCP TermReq id=0x3 "Authentication failed"]
Nov 24 17:34:26 laptop pppd[9661]: sent [LCP TermAck id=0x3]

Wichtig ist die CHAP-Response: Aus welchen Gründen auch immer werden die Backslashes doppelt escapt – was zur Folge hatte, dass unsere Firewall die Authentifizierung am IAS mit $DOMAIN\$BENUTZERNAME durchführte. Völliger Mumpitz.

Deshalb änderte ich NetworkManager die Einträge so, dass ich die Domäne leer ließ und als Benutzernamen $BENUTZERNAME@$DOMAIN festlegte. Somit funktionierte es dann auch.