Connecting to MS-CHAP V2 VPN - Mandriva

This is a discussion on Connecting to MS-CHAP V2 VPN - Mandriva ; I'm trying to connect to my works VPN. The only allow MS-CHAP V2. It works on doze, but I've been attempting to use kvpnc with no luck. I get the following error: Remote modem has hung up. Connection was terminated. ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Connecting to MS-CHAP V2 VPN

  1. Connecting to MS-CHAP V2 VPN

    I'm trying to connect to my works VPN. The only allow MS-CHAP V2. It works
    on doze, but I've been attempting to use kvpnc with no luck. I get the
    following error:

    Remote modem has hung up. Connection was terminated.

    Any help appreciated.

    --
    Regards

    Lionel.

  2. Re: Connecting to MS-CHAP V2 VPN

    On Mon, 11 Feb 2008 04:35:18 -0500, Lionel van den Berg wrote:

    > I'm trying to connect to my works VPN. The only allow MS-CHAP V2. It works


    I haven't used it. Looks like it should be supported. Before running pppd,
    try running "modprobe -v ppp_mppe".

    In /etc/ppp/options add
    nodeflate
    nobsdcomp
    to rule out problems with packet compression, and add
    debug
    so you can see (in /var/log/syslog), exactly where it is failing.

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  3. Re: Connecting to MS-CHAP V2 VPN

    David W. Hodgins wrote:

    > On Mon, 11 Feb 2008 04:35:18 -0500, Lionel van den Berg
    > wrote:
    >
    >> I'm trying to connect to my works VPN. The only allow MS-CHAP V2. It
    >> works

    >
    > I haven't used it. Looks like it should be supported. Before running pppd,
    > try running "modprobe -v ppp_mppe".


    Should I have got some response after doing this? It didn't give me
    anything.

    >
    > In /etc/ppp/options add
    > nodeflate
    > nobsdcomp
    > to rule out problems with packet compression, and add
    > debug
    > so you can see (in /var/log/syslog), exactly where it is failing.


    This is what I got from the relevant part of the log:

    Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'
    Feb 12 19:42:06 localhost pppd[7264]: unrecognized
    option 'replacedefaultroute'
    Feb 12 19:42:06 localhost pppd[7271]: pppd 2.4.4 started by root, uid 0
    Feb 12 19:42:06 localhost pppd[7271]: using channel 3
    Feb 12 19:42:06 localhost pppd[7271]: Using interface ppp0
    Feb 12 19:42:06 localhost pppd[7271]: Connect: ppp0 <--> /dev/pts/4
    Feb 12 19:42:07 localhost pppd[7271]: sent [LCP ConfReq id=0x1
    ]
    Feb 12 19:42:34 localhost last message repeated 9 times
    Feb 12 19:42:37 localhost pppd[7271]: LCP: timeout sending Config-Requests
    Feb 12 19:42:37 localhost pppd[7271]: Connection terminated.
    Feb 12 19:42:37 localhost pppd[7271]: Modem hangup
    Feb 12 19:42:37 localhost pppd[7271]: Waiting for 1 child processes...
    Feb 12 19:42:37 localhost pppd[7271]: script pptp --loglevel 1
    brisbane.ansaldo-sts.com.au --nolaunchpppd, pid 7272
    Feb 12 19:42:42 localhost pppd[7271]: sending SIGTERM to process 7272
    Feb 12 19:42:42 localhost pppd[7271]: Exit.


    --
    Regards

    Lionel.

  4. Re: Connecting to MS-CHAP V2 VPN

    On Tue, 12 Feb 2008 04:47:59 -0500, Lionel van den Berg wrote:

    >> David W. Hodgins wrote:
    >> try running "modprobe -v ppp_mppe".

    > Should I have got some response after doing this? It didn't give me
    > anything.


    If it inserted the module, it would have printed a message. If it failed
    to find the module, it would have printed a message. No output indicates
    the module was already loaded, so it didn't do anything, which is ok.

    > This is what I got from the relevant part of the log:
    > Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'
    > Feb 12 19:42:06 localhost pppd[7264]: unrecognized
    > option 'replacedefaultroute'


    From man pppd, the above options should be
    mppe require
    defaultrout
    but mppe is for encryption. I'd remove that option, until you get the
    connection working without it. Make sure /etc/ppp/chap-secrets has
    the correct loginid and password.

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  5. Re: Connecting to MS-CHAP V2 VPN

    On Tue, 12 Feb 2008 12:34:55 -0500, David W. Hodgins wrote:

    > From man pppd, the above options should be
    > mppe require
    > defaultrout


    Great time for a typo . The above line should be
    defaultroute

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  6. Re: Connecting to MS-CHAP V2 VPN

    David W. Hodgins wrote:

    > On Tue, 12 Feb 2008 04:47:59 -0500, Lionel van den Berg
    > wrote:
    >
    >>> David W. Hodgins wrote:
    >>> try running "modprobe -v ppp_mppe".

    >> Should I have got some response after doing this? It didn't give me
    >> anything.

    >
    > If it inserted the module, it would have printed a message. If it failed
    > to find the module, it would have printed a message. No output indicates
    > the module was already loaded, so it didn't do anything, which is ok.
    >
    >> This is what I got from the relevant part of the log:
    >> Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'
    >> Feb 12 19:42:06 localhost pppd[7264]: unrecognized
    >> option 'replacedefaultroute'

    >
    > From man pppd, the above options should be
    > mppe require
    > defaultrout
    > but mppe is for encryption. I'd remove that option, until you get the
    > connection working without it.


    OK, well I've tried *some* combinations, but I'm a little confused because
    there are config files everywhere:

    [root@localhost ppp]# pwd
    /etc/ppp
    [root@localhost ppp]# ls
    chap-secrets ip-down.ipv6to4* ipv6-down* options.pptpd
    connect-errors@ ip-up* ipv6-up* pap-secrets
    ip-down* ip-up.d/ options peers/
    ip-down.d/ ip-up.ipv6to4* options.pptp resolv.conf@
    [root@localhost ppp]#

    And one for each profile:

    [root@localhost ppp]# ls /etc/ppp/peers/
    kvpnc.Ansaldo kvpnc.Ansaldo1 kvpnc.Ansaldo2 wvdial wvdial-pipe

    > Make sure /etc/ppp/chap-secrets has
    > the correct loginid and password.


    These are correct. The entries are of the form:

    # --- generated by kvpnc. Do not edit it.
    # +++ generated by kvpnc. Do not edit it.
    # profile: Ansaldo1
    username profilename password *

    --
    Regards

    Lionel.

  7. Re: Connecting to MS-CHAP V2 VPN

    On Thu, 14 Feb 2008 03:38:43 -0500, Lionel van den Berg wrote:

    > OK, well I've tried *some* combinations, but I'm a little confused because
    > there are config files everywhere:


    Take it one step at a time. pppd will die, if it finds an invalid option.

    What do you get from syslog, for pppd with the options fixed?

    Regards, Dave Hodgins

    --
    Change nomail.afraid.org to ody.ca to reply by email.
    (nomail.afraid.org has been set up specifically for
    use in usenet. Feel free to use it yourself.)

  8. Re: Connecting to MS-CHAP V2 VPN

    On Tue, 12 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    , David W. Hodgins wrote:

    >Lionel van den Berg wrote:


    >> This is what I got from the relevant part of the log:
    >> Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'


    lsmod is the module in there?

    The O/P log shows ppp-2.4.4 and doesn't show a kernel version (never mind
    such minor things as distribution and release).

    >> Feb 12 19:42:06 localhost pppd[7264]: unrecognized
    >> option 'replacedefaultroute'


    That was a SuSE specific security hole included because they didn't
    understand IP routing. It was added in an attempt to hide a problem, rather
    than actually doing anything useful like fixing the root cause of the problem.
    The option was made known to the ANU ppp maintainers, who laughed at the
    incredible stupidity and ignored it.

    >From man pppd, the above options should be
    >mppe require


    "require-mppe" has been a valid option since ppp-2.4.2 and is one of
    several of that family

    require-mppe
    Require the use of MPPE (Microsoft Point to Point Encryp-
    tion). This option disables all other compression types.
    This option enables both 40-bit and 128-bit encryption.
    In order for MPPE to successfully come up, you must have
    authenticated with either MS-CHAP or MS-CHAPv2. This
    option is presently only supported under Linux, and only
    if your kernel has been configured to include MPPE sup-
    port.

    require-mppe-40
    Require the use of MPPE, with 40-bit encryption.

    require-mppe-128
    Require the use of MPPE, with 128-bit encryption.


    >defaultrout


    You caught your error. Actually, the so-called "replacedefaultroute"
    needs a few other "regular" options regarding authentication and MANUAL
    routing changes.

    * Fri Feb 25 2000 - bk@suse.de
    - wrote patch which replaces the old defaut route on successfully
    completed IPCP negotiation unless the included noreplacedefaultroute
    option is given. Documented in the man page and /etc/ppp/options.
    On connection shutdown, the old default route is restored automatically.
    Nice feature for many people with laptops which have a default
    route set trough their ethernet and want go online with their
    modem if not connected to the ethernet. Should reduce support
    load in this area dramatically.

    Security? Who cares about that???

    >but mppe is for encryption. I'd remove that option, until you get the
    >connection working without it. Make sure /etc/ppp/chap-secrets has
    >the correct loginid and password.


    See the "require-mppe" snippet above. The peer may simply hang up the
    phone on you leet h4x0rs trying to crack into their notwork.

    Old guy

  9. Re: Connecting to MS-CHAP V2 VPN

    Moe Trin wrote:

    > On Tue, 12 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in
    > article , David W. Hodgins wrote:
    >
    >>Lionel van den Berg wrote:

    >
    >>> This is what I got from the relevant part of the log:
    >>> Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'

    >
    > lsmod is the module in there?


    [root@localhost lionel]# lsmod | grep mppe
    ppp_mppe 6820 0
    ppp_generic 23348 4 ppp_deflate,ppp_mppe,ppp_synctty,ppp_async
    [root@localhost lionel]# lsmod | grep pppd
    [root@localhost lionel]#


    > The O/P log shows ppp-2.4.4 and doesn't show a kernel version (never mind
    > such minor things as distribution and release).


    [root@localhost lionel]# uname -r
    2.6.22.18-desktop-1mdv
    [root@localhost lionel]#


    >>From man pppd, the above options should be
    >>mppe require

    >
    > "require-mppe" has been a valid option since ppp-2.4.2 and is one of
    > several of that family
    >
    > require-mppe
    > Require the use of MPPE (Microsoft Point to Point Encryp-
    > tion). This option disables all other compression types.
    > This option enables both 40-bit and 128-bit encryption.
    > In order for MPPE to successfully come up, you must have
    > authenticated with either MS-CHAP or MS-CHAPv2. This
    > option is presently only supported under Linux, and only
    > if your kernel has been configured to include MPPE sup-
    > port.
    >
    > require-mppe-40
    > Require the use of MPPE, with 40-bit encryption.
    >
    > require-mppe-128
    > Require the use of MPPE, with 128-bit encryption.


    So what is your suggestion about what I should be using?


    >>but mppe is for encryption. I'd remove that option, until you get the
    >>connection working without it. Make sure /etc/ppp/chap-secrets has
    >>the correct loginid and password.

    >
    > See the "require-mppe" snippet above. The peer may simply hang up the
    > phone on you leet h4x0rs trying to crack into their notwork.



    --
    Regards

    Lionel.

  10. Re: Connecting to MS-CHAP V2 VPN

    On Fri, 15 Feb 2008, in the Usenet newsgroup alt.os.linux.mandriva, in article
    <47b549d3@dnews.tpgi.com.au>, Lionel van den Berg wrote:

    >Moe Trin wrote:


    >> lsmod is the module in there?

    >
    >[root@localhost lionel]# lsmod | grep mppe
    >ppp_mppe 6820 0
    >ppp_generic 23348 4 ppp_deflate,ppp_mppe,ppp_synctty,ppp_async


    It's there, and unused. OK

    >> The O/P log shows ppp-2.4.4 and doesn't show a kernel version (never mind
    >> such minor things as distribution and release).

    >
    >[root@localhost lionel]# uname -r
    >2.6.22.18-desktop-1mdv
    >[root@localhost lionel]#


    OK - I'm not using that kernel, but the fact that lsmod shows the module
    there indicates that the hooks are there and usable.

    >> "require-mppe" has been a valid option since ppp-2.4.2 and is one of
    >> several of that family


    >So what is your suggestion about what I should be using?


    If we look back at a previous post, you showed:

    ]Feb 12 19:42:06 localhost pppd[7263]: unrecognized option 'require-mppe'
    ]Feb 12 19:42:06 localhost pppd[7264]: unrecognized
    ]option 'replacedefaultroute'
    ]Feb 12 19:42:06 localhost pppd[7271]: pppd 2.4.4 started by root, uid 0

    Minor confusion. Process 7263 (on what is presumably ppp-2.4.4) didn't
    recognize the require-mppe option. I don't know why. Process 7264 and the
    invalid 'replacedefaultroute' option is fine - that's a setup error. The
    pppd not wanting to _replace_ an existing default, and requiring the peer
    to authenticate TO YOU if one exists are security issues - sneaking
    around a company firewall would be a good description, and that's a very
    big no-no at most places who can spell the word security.

    ]Feb 12 19:42:07 localhost pppd[7271]: sent [LCP ConfReq id=0x1
    ] ]

    You sent a "generic" hello - those are pretty stock options.

    ]Feb 12 19:42:34 localhost last message repeated 9 times
    ]Feb 12 19:42:37 localhost pppd[7271]: LCP: timeout sending Config-Requests

    But the other side didn't so much as mumble at you. No response what so
    ever. So what my next step would be is to go to the server at the other
    end of the telephone, and look at it's logs. What did it get all huffy
    about. Did the ppp process even hear you? You indicate that the server
    is a company box (company admin problems) running windoze (the logs of a
    windoze box are intentionally designed to look complicated, with lots of
    techno-babble - the whole idea is to scare you away from those nasty
    technical thingies), but if the peer won't even talk to you, you have to
    go to the peer to find out why. Sorry I can't advise further, but
    microsoft has never been know to go out of their way to follow standards,
    even their own. That makes it difficult to troubleshoot from "outside".

    The only thing I can say from here is that the modems appear to have
    connected, and there is some "non-text" service (really meaning not a
    classic terminal server) listening, but not hearing the right things.

    Most of us don't have to deal with the microsoft abortion and the
    intentional non-standard additions that are needed. Example - with
    just about every accessible ppp dialin server, the mode today is to
    dial the phone, when the modems report CONNECT, start slinging LCP
    frames at each other (that "sent [LCP ConfReq" stuff above). 15 years
    ago, it was more common to be presented with a UNIX style "Login:"
    prompt and you logged into a remote shell process. That died when
    microsoft invented the telephone, because win95 users couldn't see
    where to click their mouse button on this text crap. Later, with NT,
    microsoft developed a new idea, that when the modems connected, they
    would send a bit of text identifying what they were: "CLIENT" or
    "CLIENT/SERVER" or some such B/S. As far as I've been able to tell, it
    served no purpose, but if you were trying to connect to a server whose
    admin hadn't disabled the microsoft "features", that server was not going
    to talk to you until you said that magic word. No one else used this
    function, and I think even microsoft has ignored that it existed, but you
    never can tell.

    Old guy

+ Reply to Thread