PPPD authentication problem? - PPP

This is a discussion on PPPD authentication problem? - PPP ; Hi, If anyone could shed any light on this problem it would be appreciated. I am attempting to connect a Linux client to a Watchguard Firebox 2 VPN gateway. I have installed kernel level support for MPPE (and more recently ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: PPPD authentication problem?

  1. PPPD authentication problem?

    Hi,
    If anyone could shed any light on this problem it would be appreciated.
    I am attempting to connect a Linux client to a Watchguard Firebox 2
    VPN gateway. I have installed kernel level support for MPPE (and more
    recently the 2.6.17 kernel which has built in support for MPPE) and
    complied from source the latest PPP 2.4.4 (from CVS) with all of the
    options in the README.mschap80 and 81 specified. I am also running the
    latest PPTPclient from pptpclient.sourceforge.net.

    Anyway my problem is the the watchgaurd sends a Chap Success packet but
    my pppd then ignores it and terminates LCP. I have read everything I
    could find about PPPD and PPTP and just cant work out what is going
    wrong. I did find an old post to the PPTPclient developers mailing
    list, in which someone had the exact same problem and the list
    suggested that it was a PPP issue not a PPTPlinux issue which is why I
    am posting here. The connection logs are attached, any assistance
    would be greatly appreciated.

    ABMELB:/usr/src/ppp/pppd# uname -a
    Linux ABMELB 2.6.17 #1 PREEMPT Wed Nov 8 08:45:17 NZDT 2006 i686
    GNU/Linux

    ABMELB:/var/log# pppd --version
    pppd version 2.4.4

    ABMELB:/var/log# pptp --version
    pptp-linux version 1.5.0

    Nov 9 16:05:47 localhost pppd[13665]: pppd options in effect:
    Nov 9 16:05:47 localhost pppd[13665]: debug debug^I^I# (from command
    line)
    Nov 9 16:05:47 localhost pppd[13665]: kdebug 7^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: nodetach^I^I# (from command
    line)
    Nov 9 16:05:47 localhost pppd[13665]: logfd 2^I^I# (from command line)
    Nov 9 16:05:47 localhost pppd[13665]: ktune^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: dump^I^I# (from command line)
    Nov 9 16:05:47 localhost pppd[13665]: noauth^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: name a*******^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: pty pptp [IP ADD} --nolaunchpppd
    --loglevel 2^I^I# (from /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: crtscts^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: mru 1434^I^I# (from
    /etc/ppp/options)
    Nov 9 16:05:47 localhost pppd[13665]: -pc^I^I# (from /etc/ppp/options)
    Nov 9 16:05:47 localhost pppd[13665]: lcp-echo-failure 4^I^I# (from
    /etc/ppp/options)
    Nov 9 16:05:47 localhost pppd[13665]: lcp-echo-interval 15^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: mpshortseq^I^I# (from
    /etc/ppp/options.pptp)
    Nov 9 16:05:47 localhost pppd[13665]: hide-password^I^I# (from
    /etc/ppp/options)
    Nov 9 16:05:47 localhost pppd[13665]: chap-restart 6^I^I# (from
    /etc/ppp/options)
    Nov 9 16:05:47 localhost pppd[13665]: novj^I^I# (from
    /etc/ppp/options.pptp)
    Nov 9 16:05:47 localhost pppd[13665]: -vj^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: -vjccomp^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: ipcp-accept-local^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: ipcp-accept-remote^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: ipparam abnet1^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: defaultroute^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: proxyarp^I^I# (from
    /etc/ppp/options)
    Nov 9 16:05:47 localhost pppd[13665]: -bsdcomp^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: nodeflate^I^I# (from
    /etc/ppp/options.pptp)
    Nov 9 16:05:47 localhost pppd[13665]: noipx^I^I# (from
    /etc/ppp/peers/abnet1)
    Nov 9 16:05:47 localhost pppd[13665]: pppd 2.4.3 started by root, uid
    0
    Nov 9 16:05:47 localhost pptp[13666]: anon log[mainptp.c:243]: The
    synchronous pptp option is NOT activated
    Nov 9 16:05:47 localhost pppd[13665]: using channel 50
    Nov 9 16:05:47 localhost pppd[13665]: Using interface ppp0
    Nov 9 16:05:47 localhost pppd[13665]: Connect: ppp0 <--> /dev/pts/2
    Nov 9 16:05:47 localhost pptp[13671]: anon
    log[ctrlp_repptp_ctrl.c:243]: Sent control packet type is 1
    'Start-Control-Connection-Request'
    Nov 9 16:05:47 localhost pptp[13671]: anon
    log[ctrlp_dispptp_ctrl.c:721]: Received Start Control Connection
    Reply
    Nov 9 16:05:47 localhost pptp[13671]: anon
    log[ctrlp_dispptp_ctrl.c:755]: Client connection established.
    Nov 9 16:05:48 localhost pppd[13665]: sent [LCP ConfReq id=0x1 1434> ]
    Nov 9 16:05:48 localhost pptp[13671]: anon
    log[ctrlp_repptp_ctrl.c:243]: Sent control packet type is 7
    'Outgoing-Call-Request'
    Nov 9 16:05:48 localhost pptp[13671]: anon
    log[ctrlp_dispptp_ctrl.c:841]: Received Outgoing Call Reply.
    Nov 9 16:05:48 localhost pptp[13671]: anon
    log[ctrlp_dispptp_ctrl.c:880]: Outgoing call established (call ID 0,
    peer's call ID 3).
    Nov 9 16:05:51 localhost pppd[13665]: sent [LCP ConfReq id=0x1 1434> ]
    Nov 9 16:05:51 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 1
    Nov 9 16:05:51 localhost pppd[13665]: rcvd [LCP ConfReq id=0x1 338> ]
    Nov 9 16:05:51 localhost pppd[13665]: sent [LCP ConfRej id=0x1
    ]
    Nov 9 16:05:51 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 2
    Nov 9 16:05:51 localhost pppd[13665]: rcvd [LCP ConfRej id=0x1
    ]
    Nov 9 16:05:51 localhost pppd[13665]: sent [LCP ConfReq id=0x2 1434> ]
    Nov 9 16:05:51 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 3
    Nov 9 16:05:51 localhost pppd[13665]: rcvd [LCP ConfReq id=0x2 338> ]
    Nov 9 16:05:51 localhost pppd[13665]: sent [LCP ConfAck id=0x2 338> ]
    Nov 9 16:05:51 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 4
    Nov 9 16:05:51 localhost pppd[13665]: rcvd [LCP ConfAck id=0x2 1434> ]
    Nov 9 16:05:51 localhost pppd[13665]: sent [LCP EchoReq id=0x0
    magic=0xe8bd31e9]
    Nov 9 16:05:51 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 5
    Nov 9 16:05:51 localhost pppd[13665]: rcvd [CHAP Challenge id=0x1
    , name = "..."]
    Nov 9 16:05:51 localhost pppd[13665]: sent [CHAP Response id=0x1
    <6bc123a79124e1fb925c436746b95e3b.....14b3a5419447e e91bdd4e7cce6120a42daa7837e1
    c97fa500>, name = "******"]
    Nov 9 16:05:51 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 6
    Nov 9 16:05:51 localhost pppd[13665]: rcvd [LCP EchoRep id=0x0
    magic=0x84be4c25]
    Nov 9 16:05:51 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 7
    Nov 9 16:05:51 localhost pppd[13665]: rcvd [CHAP Success id=0x1
    "S=5a29969******7a3d3c7e76"]
    Nov 9 16:05:51 localhost pppd[13665]: MS-CHAPv2 mutual authentication
    failed.
    Nov 9 16:05:51 localhost pppd[13665]: sent [LCP TermReq id=0x3 "Failed
    to authenticate ourselves to peer"]
    Nov 9 16:05:51 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 8
    Nov 9 16:05:51 localhost pppd[13665]: rcvd [IPCP ConfReq id=0x1 192.168.2.7>]
    Nov 9 16:05:51 localhost pppd[13665]: Discarded non-LCP packet when
    LCP not open
    Nov 9 16:05:52 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 9
    Nov 9 16:05:52 localhost pppd[13665]: rcvd [CCP ConfReq id=0x1 +H -M +S -L -D -C>]
    Nov 9 16:05:52 localhost pppd[13665]: Discarded non-LCP packet when
    LCP not open
    Nov 9 16:05:52 localhost pptp[13666]: anon
    log[decaps_greptp_gre.c:385]: accepting packet 10
    Nov 9 16:05:52 localhost pppd[13665]: rcvd [LCP TermAck id=0x3]
    Nov 9 16:05:52 localhost pppd[13665]: Connection terminated.
    Nov 9 16:05:52 localhost pppd[13665]: Waiting for 1 child processes...
    Nov 9 16:05:52 localhost pppd[13665]: script pptp 210.54.1.6
    --nolaunchpppd --loglevel 2, pid 13666
    Nov 9 16:05:57 localhost pppd[13665]: sending SIGTERM to process 13666
    Nov 9 16:05:57 localhost pppd[13665]: Exit.
    Nov 9 16:05:57 localhost pptp[13671]: anon
    log[callmgr_mainptp_callmgr.c:228]: Closing connection
    Nov 9 16:05:57 localhost pptp[13671]: anon
    log[ctrlp_repptp_ctrl.c:243]: Sent control packet type is 12
    'Call-Clear-Request'
    Nov 9 16:05:59 localhost pptp[13671]: anon
    log[ctrlp_repptp_ctrl.c:243]: Sent control packet type is 12
    'Call-Clear-Request'
    Nov 9 16:05:59 localhost pptp[13671]: anon
    log[pptp_conn_closeptp_ctrl.c:425]: Closing PPTP connection
    Nov 9 16:05:59 localhost pptp[13671]: anon
    log[ctrlp_repptp_ctrl.c:243]: Sent control packet type is 3
    'Stop-Control-Connection-Request'
    Nov 9 16:06:03 localhost pptp[13671]: anon
    log[call_callbackptp_callmgr.c:77]: Closing connection
    Nov 9 16:09:42 localhost kernel: device eth0 left promiscuous mode

    Again any assistance would be muchly appreciated,
    Regards,
    Michael


  2. Re: PPPD authentication problem?

    mscarlett@gmail.com wrote:
    > Hi,
    > If anyone could shed any light on this problem it would be appreciated.
    > I am attempting to connect a Linux client to a Watchguard Firebox 2
    > VPN gateway. I have installed kernel level support for MPPE (and more
    > recently the 2.6.17 kernel which has built in support for MPPE) and
    > complied from source the latest PPP 2.4.4 (from CVS) with all of the
    > options in the README.mschap80 and 81 specified. I am also running the
    > latest PPTPclient from pptpclient.sourceforge.net.


    > Anyway my problem is the the watchgaurd sends a Chap Success packet but
    > my pppd then ignores it and terminates LCP. I have read everything I
    > could find about PPPD and PPTP and just cant work out what is going
    > wrong. I did find an old post to the PPTPclient developers mailing
    > list, in which someone had the exact same problem and the list
    > suggested that it was a PPP issue not a PPTPlinux issue which is why I
    > am posting here. The connection logs are attached, any assistance
    > would be greatly appreciated.


    ....

    > Nov 9 16:05:51 localhost pppd[13665]: rcvd [CHAP Challenge id=0x1
    > , name = "..."]
    > Nov 9 16:05:51 localhost pppd[13665]: sent [CHAP Response id=0x1
    > <6bc123a79124e1fb925c436746b95e3b.....14b3a5419447e e91bdd4e7cce6120a42daa7837e1
    > c97fa500>, name = "******"]
    > Nov 9 16:05:51 localhost pptp[13666]: anon
    > log[decaps_greptp_gre.c:385]: accepting packet 6
    > Nov 9 16:05:51 localhost pppd[13665]: rcvd [LCP EchoRep id=0x0
    > magic=0x84be4c25]
    > Nov 9 16:05:51 localhost pptp[13666]: anon
    > log[decaps_greptp_gre.c:385]: accepting packet 7
    > Nov 9 16:05:51 localhost pppd[13665]: rcvd [CHAP Success id=0x1
    > "S=5a29969******7a3d3c7e76"]
    > Nov 9 16:05:51 localhost pppd[13665]: MS-CHAPv2 mutual authentication
    > failed.


    Well, "mutual authentication" is new to me but I was curious. In chap_ms.c
    of the 2.4.4 code there is this:

    /* Generate the expected response and our mutual auth. */
    ChapMS2(challenge, &response[MS_CHAP2_PEER_CHALLENGE], name,
    (char *)secret, secret_len, md,
    (unsigned char *)saresponse, MS_CHAP2_AUTHENTICATOR);

    /* compare MDs and send the appropriate status */
    /*
    * Per RFC 2759, success message must be formatted as
    * "S= M="
    * where
    * is the Authenticator Response (mutual auth)
    * is a text message
    *
    * However, some versions of Windows (win98 tested) do not know
    * about the M= part (required per RFC 2759) and flag
    * it as an error (reported incorrectly as an encryption error
    * to the user). Since the RFC requires it, and it can be
    * useful information, we supply it if the peer is a conforming
    * system. Luckily (?), win98 sets the Flags field to 0x04
    * (contrary to RFC requirements) so we can use that to
    * distinguish between conforming and non-conforming systems.


    > Nov 9 16:05:51 localhost pppd[13665]: sent [LCP TermReq id=0x3 "Failed
    > to authenticate ourselves to peer"]


    The "Chap Success" from the peer lacks the "M=" part.

    If no better reply is forthcoming then you can try regressing to pppd
    2.4.1 which doesn't have this (quote "yuck," unquote) in it.

    --
    Clifford Kite
    /* My confide NOT RATED answer (X), on a scale of 0 to 10:
    |----|----|----|----|----|----|----|----|----|----|
    0----1----2----3----4----5----6----7----8----9----10 */


+ Reply to Thread