Authentication with PAP & CHAP - PPP

This is a discussion on Authentication with PAP & CHAP - PPP ; I'm running a SuSE 8.2 box as a dialin and VPN machine, using pppd (2.4.1) and pptpd (1.1.2). Everything works fine, except for one little snag... In options.ttyS1 (the dialin modem) I tell pppd to require-pap and to refuse-chap. In ...

+ Reply to Thread
Results 1 to 15 of 15

Thread: Authentication with PAP & CHAP

  1. Authentication with PAP & CHAP

    I'm running a SuSE 8.2 box as a dialin and VPN machine, using pppd
    (2.4.1) and pptpd (1.1.2). Everything works fine, except for one little
    snag...

    In options.ttyS1 (the dialin modem) I tell pppd to require-pap and to
    refuse-chap. In options.pptpd I have refuse-pap and require-chapms-v2.
    No authentication is specified in the default options or the
    command-line.

    Yes, this is the way I want it, but when the user connects through the
    modem pppd tries to authenticate with CHAP.

    Has anyone else seen this behaviour, or am I missing something?


  2. Re: Authentication with PAP & CHAP

    "risadler" writes:
    > I'm running a SuSE 8.2 box as a dialin and VPN machine, using pppd
    > (2.4.1) and pptpd (1.1.2). Everything works fine, except for one little
    > snag...
    >
    > In options.ttyS1 (the dialin modem) I tell pppd to require-pap and to
    > refuse-chap.


    Those don't quite do what you may be expecting.

    "require-pap" means that when you're acting as an authenticator
    ("server"), you'll insist on using PAP. "refuse-chap", though, means
    that when you're acting as an authenticatee (a "client"), you'll
    refuse CHAP if the peer asks for it, even if you have credentials you
    can use.

    If you're not behaving as an authenticatee (a "client"), then
    "refuse-chap" probably (almost certainly) isn't what you want.

    > In options.pptpd I have refuse-pap and require-chapms-v2.
    > No authentication is specified in the default options or the
    > command-line.
    >
    > Yes, this is the way I want it, but when the user connects through the
    > modem pppd tries to authenticate with CHAP.
    >
    > Has anyone else seen this behaviour, or am I missing something?


    Debug logs and the actual contents of your configuration files would
    probably help.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  3. Re: Authentication with PAP & CHAP

    (Will post the configuration files and logs shortly...)

    OK, I want to have the client always authenticate with CHAP when
    connecting through the VPN, but some of the dialups will only do PAP.
    (Please don't ask me why. I found it simpler to just go with the flow
    regarding those people.) What would be the correct way to define such a
    setup?

    Probably stupid, but I was under the impression that one could define
    different settings for each ppp interface through the use of the
    "options.*" files. Not so?


  4. Re: Authentication with PAP & CHAP

    "risadler" writes:
    > (Will post the configuration files and logs shortly...)
    >
    > OK, I want to have the client always authenticate with CHAP when
    > connecting through the VPN, but some of the dialups will only do PAP.
    > (Please don't ask me why. I found it simpler to just go with the flow
    > regarding those people.) What would be the correct way to define such a
    > setup?


    I don't think there is any one correct way to do this. One useful way
    is as you suggest.

    Another is to just leave out all of this forced-configuration, and let
    PPP negotiation do its job. To do that, put credentials for the CHAP
    users into /etc/ppp/chap-secrets and the credentials for the PAP users
    into /etc/ppp/pap-secrets. When the user dials in, pppd will propose
    CHAP by default (with just the "auth" option). If the user is
    actually using PAP, his PPP implementation will automatically refuse
    CHAP and request PAP. Your side will automatically note that it has
    usable PAP credentials and will suggest PAP instead. The two will
    agree, and authentication will complete.

    Still another is to put the configuration options on the respective
    command lines. Yet another is to use the "file" option to load the
    options desired.

    There are lots of ways to skin this cat ...

    > Probably stupid, but I was under the impression that one could define
    > different settings for each ppp interface through the use of the
    > "options.*" files. Not so?


    Quite so. But without knowing exactly what went awry here, it's hard
    to tell why you didn't get the intended effect. There are multiple
    possible explanations (configuration file you think you're getting
    isn't the one you're actually getting, multiple files are in use and a
    later one is overriding an earlier one, possible bugs in the pptp or
    other software you're using, et cetera).

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.234W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.497N Fax +1 781 442 1677

  5. Re: Authentication with PAP & CHAP

    "risadler" writes:

    >I'm running a SuSE 8.2 box as a dialin and VPN machine, using pppd
    >(2.4.1) and pptpd (1.1.2). Everything works fine, except for one little
    >snag...


    >In options.ttyS1 (the dialin modem) I tell pppd to require-pap and to
    >refuse-chap. In options.pptpd I have refuse-pap and require-chapms-v2.
    >No authentication is specified in the default options or the
    >command-line.


    How does the user connect through the modem? I assume you use mgetty. What
    is the line in /etc/mgetty*/login.conf that the remote side connects
    through? What is the output of your log file
    (debug in /etc/ppp/options,
    local2.*;daemon.* /var/log/ppplog
    in /etc/syslog.conf and then do killall -1 syslogd
    Then dial in and show the output in /var/log/ppplog

    What is the output in /var/log/mgetty.ttyS1?
    Ie, there is no way we can diagnose a problem without information.


    >Yes, this is the way I want it, but when the user connects through the
    >modem pppd tries to authenticate with CHAP.


    >Has anyone else seen this behaviour, or am I missing something?



  6. Re: Authentication with PAP & CHAP

    /etc/ppp/options :
    [blank]

    /etc/ppp/options.ttyS1 :
    172.16.0.9:172.16.0.14
    asyncmap 0
    crtscts
    nodetach
    deflate 15
    debug
    lock
    modem
    netmask 255.255.254.0
    ms-dns 172.16.0.2
    proxyarp
    require-pap
    refuse-chap

    /etc/ppp/options.pptp :
    # debug
    name *
    lock
    # mtu 1450
    # mru 1450
    proxyarp
    auth
    ipcp-accept-local
    ipcp-accept-remote
    lcp-echo-failure 5
    lcp-echo-interval 15
    passive
    nodeflate
    nobsdcomp
    netmask 255.255.254.0
    ms-dns 172.16.0.2

    # Handshake Authenticate Method
    refuse-pap
    require-chapms-v2

    # Data Encryption Methods
    mppe-40
    mppe-128
    mppe-stateless

    /etc/mgetty+sendfax/mgetty.config :
    debug 4
    speed 38400
    modem-type data
    modem-check-time 1800
    term vt100
    init-chat "" AT&F1M0
    port ttyS1

    /etc/mgetty+sendfax/login.config :
    /AutoPPP/ - a_ppp /usr/sbin/pppd auth debug

    /etc/mgetty+sendfax/dialin.config :
    [blank]

    /etc/pptp.conf :
    option /etc/ppp/options.pptpd
    localip 172.16.0.9
    remoteip 172.16.0.15-20

    /var/log/messages :
    ---snip---
    Jul 12 14:06:51 CBS009 pppd[3380]: pppd 2.4.1 started by a_ppp, uid 0
    Jul 12 14:06:51 CBS009 pppd[3380]: Perms of /dev/ttyS1 are ok, no 'mesg
    n' neccesary.
    Jul 12 14:06:51 CBS009 pppd[3380]: using channel 15
    Jul 12 14:06:51 CBS009 pppd[3380]: Using interface ppp0
    Jul 12 14:06:51 CBS009 pppd[3380]: Connect: ppp0 <--> /dev/ttyS1
    Jul 12 14:06:51 CBS009 pppd[3380]: sent [LCP ConfReq id=0x1 0x0> ]
    Jul 12 14:06:51 CBS009 pppd[3380]: rcvd [LCP ConfAck id=0x1 0x0> ]
    Jul 12 14:06:54 CBS009 pppd[3380]: rcvd [LCP ConfReq id=0x2 0x0> ]
    Jul 12 14:06:54 CBS009 pppd[3380]: sent [LCP ConfAck id=0x2 0x0> ]
    Jul 12 14:06:54 CBS009 pppd[3380]: cbcp_lowerup
    Jul 12 14:06:54 CBS009 pppd[3380]: want: 2
    Jul 12 14:06:54 CBS009 pppd[3380]: sent [CHAP Challenge id=0x1
    <8cae439bf6937c7178e7cda098a7d620f1976c>, name = "CBS009"]
    Jul 12 14:06:54 CBS009 pppd[3380]: rcvd [LCP code=0xc id=0x3 09 19 7b
    26 4d 53 52 41 53 56 35 2e 31 30]
    Jul 12 14:06:54 CBS009 pppd[3380]: sent [LCP CodeRej id=0x2 0c 03 00 12
    09 19 7b 26 4d 53 52 41 53 56 35 2e 31 30]
    Jul 12 14:06:54 CBS009 pppd[3380]: rcvd [LCP code=0xc id=0x4 09 19 7b
    26 4d 53 52 41 53 2d 31 2d 42 45]
    Jul 12 14:06:54 CBS009 pppd[3380]: sent [LCP CodeRej id=0x3 0c 04 00 12
    09 19 7b 26 4d 53 52 41 53 2d 31 2d 42 45]
    Jul 12 14:06:54 CBS009 pppd[3380]: rcvd [CHAP Response id=0x1
    , name = "collab"]
    Jul 12 14:06:54 CBS009 pppd[3380]: No CHAP secret found for
    authenticating collab
    Jul 12 14:06:54 CBS009 pppd[3380]: sent [CHAP Failure id=0x1 "I don't
    like you. Go 'way."]
    Jul 12 14:06:54 CBS009 pppd[3380]: CHAP peer authentication failed for
    remote host collab
    Jul 12 14:06:54 CBS009 pppd[3380]: cbcp_lowerdown
    Jul 12 14:06:54 CBS009 pppd[3380]: sent [LCP TermReq id=0x4
    "Authentication failed"]
    Jul 12 14:06:55 CBS009 pppd[3380]: rcvd [LCP TermReq id=0x5 09 19 7b 26
    00 3c cd 74 00 00 02 b3]
    Jul 12 14:06:55 CBS009 pppd[3380]: sent [LCP TermAck id=0x5]
    Jul 12 14:06:55 CBS009 pppd[3380]: rcvd [LCP TermAck id=0x4
    "Authentication failed"]
    Jul 12 14:06:55 CBS009 pppd[3380]: Connection terminated.
    Jul 12 14:06:55 CBS009 pppd[3380]: Exit.
    ---snip---


  7. Re: Authentication with PAP & CHAP

    "risadler" writes:
    > /etc/ppp/options.pptp :

    [...]
    > /etc/mgetty+sendfax/login.config :
    > /AutoPPP/ - a_ppp /usr/sbin/pppd auth debug


    You might not want "auth" there, but it shouldn't matter.

    Have you tried using "require-pap" here?

    > /etc/pptp.conf :
    > option /etc/ppp/options.pptpd

    ^^^^^

    Doesn't match the file name above.

    > Jul 12 14:06:51 CBS009 pppd[3380]: Perms of /dev/ttyS1 are ok, no 'mesg
    > n' neccesary.


    That's worrisome. The standard ppp-2.4.* distribution doesn't have
    that message in it.

    Who modified the pppd that you're using?

    > Jul 12 14:06:54 CBS009 pppd[3380]: cbcp_lowerup
    > Jul 12 14:06:54 CBS009 pppd[3380]: want: 2


    Also worrisome, for the same reason.

    It sure looks like the problem you're reporting is a bug, but it's not
    one I've seen before.

    --
    James Carlson, KISS Network
    Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
    MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

  8. Re: Authentication with PAP & CHAP

    Sorry, typo regarding the "options.pptpd" name (which is
    "options.pptpd").

    pptpd, mgetty and pppd are as-is from the SuSE 8.2 distro, so it was
    modified by them. I suppose I should install (compile) the latest
    versions, but what is the point of running a distro if you have to do
    that? Then I can rather use LFS instead...

    OK, so theoretically... If I want the VPN clients to only authenticate
    with CHAP and want to allow the dialup clients to use either PAP or
    CHAP, is the above settings correct? If so, I can try and install the
    latest versions of each package and see what happens...

    Is it also possible to symlink "chap-secrets" to "pap-secrets", so that
    I have only one user+password file?


  9. Re: Authentication with PAP & CHAP

    "risadler" writes:

    >/etc/ppp/options :


    Put debug in here.


    > [blank]


    >/etc/ppp/options.ttyS1 :
    >172.16.0.9:172.16.0.14
    >asyncmap 0
    >crtscts
    >nodetach
    >deflate 15

    ^^^^^^^^
    Remove for now.
    >debug
    >lock
    >modem
    >netmask 255.255.254.0

    netmask makes no sense. Remove.

    >ms-dns 172.16.0.2
    >proxyarp
    >require-pap
    >refuse-chap

    ^^^^^
    remove.


    >/etc/ppp/options.pptp :
    ># debug
    >name *


    ???? What is this supposed to mean?
    t remove it.
    >lock
    ># mtu 1450
    ># mru 1450
    >proxyarp
    >auth
    >ipcp-accept-local
    >ipcp-accept-remote
    >lcp-echo-failure 5
    >lcp-echo-interval 15
    >passive
    >nodeflate
    >nobsdcomp
    >netmask 255.255.254.0


    Remove

    >ms-dns 172.16.0.2


    ># Handshake Authenticate Method
    >refuse-pap

    ^^^ remove
    >require-chapms-v2


    Why do you have this anyway? Why have different authentication mechanisms
    and why in the world use chapms?


    ># Data Encryption Methods
    >mppe-40
    >mppe-128
    >mppe-stateless


    >/etc/mgetty+sendfax/mgetty.config :
    >debug 4
    >speed 38400
    >modem-type data
    >modem-check-time 1800
    >term vt100
    >init-chat "" AT&F1M0
    >port ttyS1


    >/etc/mgetty+sendfax/login.config :
    >/AutoPPP/ - a_ppp /usr/sbin/pppd auth debug


    >/etc/mgetty+sendfax/dialin.config :
    > [blank]


    >/etc/pptp.conf :
    >option /etc/ppp/options.pptpd
    >localip 172.16.0.9
    >remoteip 172.16.0.15-20


    >/var/log/messages :
    >---snip---
    >Jul 12 14:06:51 CBS009 pppd[3380]: pppd 2.4.1 started by a_ppp, uid 0
    >Jul 12 14:06:51 CBS009 pppd[3380]: Perms of /dev/ttyS1 are ok, no 'mesg
    >n' neccesary.


    Where did this come from? It does not look a standard pppd. What system are
    you on? Is this a standard stock pppd or is it someothing you or a
    distributor mangled?


    >Jul 12 14:06:51 CBS009 pppd[3380]: using channel 15
    >Jul 12 14:06:51 CBS009 pppd[3380]: Using interface ppp0
    >Jul 12 14:06:51 CBS009 pppd[3380]: Connect: ppp0 <--> /dev/ttyS1
    >Jul 12 14:06:51 CBS009 pppd[3380]: sent [LCP ConfReq id=0x1 >0x0> ]


    You ask for chap MD5 authentication. This is not pap. Not sure why.
    It really does not look as thought the system is reading your
    options.ttyS1. (Not just this but the other options it is not requesting)




    >Jul 12 14:06:51 CBS009 pppd[3380]: rcvd [LCP ConfAck id=0x1 >0x0> ]


    They accept. Not sure why chap is a problem.

    >Jul 12 14:06:54 CBS009 pppd[3380]: rcvd [LCP ConfReq id=0x2 >0x0> ]


    They ask for callback. Why?


    >Jul 12 14:06:54 CBS009 pppd[3380]: sent [LCP ConfAck id=0x2 >0x0> ]


    And you agree.

    >Jul 12 14:06:54 CBS009 pppd[3380]: cbcp_lowerup
    >Jul 12 14:06:54 CBS009 pppd[3380]: want: 2
    >Jul 12 14:06:54 CBS009 pppd[3380]: sent [CHAP Challenge id=0x1
    ><8cae439bf6937c7178e7cda098a7d620f1976c>, name = "CBS009"]
    >Jul 12 14:06:54 CBS009 pppd[3380]: rcvd [LCP code=0xc id=0x3 09 19 7b
    >26 4d 53 52 41 53 56 35 2e 31 30]
    >Jul 12 14:06:54 CBS009 pppd[3380]: sent [LCP CodeRej id=0x2 0c 03 00 12
    >09 19 7b 26 4d 53 52 41 53 56 35 2e 31 30]
    >Jul 12 14:06:54 CBS009 pppd[3380]: rcvd [LCP code=0xc id=0x4 09 19 7b
    >26 4d 53 52 41 53 2d 31 2d 42 45]
    >Jul 12 14:06:54 CBS009 pppd[3380]: sent [LCP CodeRej id=0x3 0c 04 00 12
    >09 19 7b 26 4d 53 52 41 53 2d 31 2d 42 45]
    >Jul 12 14:06:54 CBS009 pppd[3380]: rcvd [CHAP Response id=0x1
    >, name = "collab"]
    >Jul 12 14:06:54 CBS009 pppd[3380]: No CHAP secret found for
    >authenticating collab


    And chap fails.

    So, if you want it to work, why not just put the line you had in
    pap-secrets into chap-secrets.



    >Jul 12 14:06:54 CBS009 pppd[3380]: sent [CHAP Failure id=0x1 "I don't
    >like you. Go 'way."]
    >Jul 12 14:06:54 CBS009 pppd[3380]: CHAP peer authentication failed for
    >remote host collab
    >Jul 12 14:06:54 CBS009 pppd[3380]: cbcp_lowerdown
    >Jul 12 14:06:54 CBS009 pppd[3380]: sent [LCP TermReq id=0x4
    >"Authentication failed"]
    >Jul 12 14:06:55 CBS009 pppd[3380]: rcvd [LCP TermReq id=0x5 09 19 7b 26
    >00 3c cd 74 00 00 02 b3]
    >Jul 12 14:06:55 CBS009 pppd[3380]: sent [LCP TermAck id=0x5]
    >Jul 12 14:06:55 CBS009 pppd[3380]: rcvd [LCP TermAck id=0x4
    >"Authentication failed"]
    >Jul 12 14:06:55 CBS009 pppd[3380]: Connection terminated.
    >Jul 12 14:06:55 CBS009 pppd[3380]: Exit.
    >---snip---



  10. Re: Authentication with PAP & CHAP

    "risadler" writes:

    >Sorry, typo regarding the "options.pptpd" name (which is
    >"options.pptpd").


    >pptpd, mgetty and pppd are as-is from the SuSE 8.2 distro, so it was
    >modified by them. I suppose I should install (compile) the latest
    >versions, but what is the point of running a distro if you have to do
    >that? Then I can rather use LFS instead...


    Well, SUSE has a habit of deciding that they know better. They have a long
    history of butchering pppd, and causeing problems. I would not run SUSE,
    but you may find other features that make you like that distribution.
    Get a stock pppd from ftp.samba.org, compile and install it and see if your
    problem disappears.


    >OK, so theoretically... If I want the VPN clients to only authenticate
    >with CHAP and want to allow the dialup clients to use either PAP or
    >CHAP, is the above settings correct? If so, I can try and install the
    >latest versions of each package and see what happens...


    SO NOT install a SUSE version. Get the stock version.
    If you do not care, just remove all of the chap/pap options in the options
    files.



    >Is it also possible to symlink "chap-secrets" to "pap-secrets", so that
    >I have only one user+password file?


    Not sure. It might work. Try it.
    Certainly a hard link would work.


  11. Re: Authentication with PAP & CHAP

    risadler wrote:
    > /etc/ppp/options :
    > [blank]


    > /etc/ppp/options.ttyS1 :
    > 172.16.0.9:172.16.0.14
    > asyncmap 0
    > crtscts
    > nodetach
    > deflate 15
    > debug
    > lock
    > modem
    > netmask 255.255.254.0
    > ms-dns 172.16.0.2
    > proxyarp
    > require-pap
    > refuse-chap




    > /var/log/messages :
    > ---snip---
    > Jul 12 14:06:51 CBS009 pppd[3380]: pppd 2.4.1 started by a_ppp, uid 0
    > Jul 12 14:06:51 CBS009 pppd[3380]: Perms of /dev/ttyS1 are ok, no 'mesg
    > n' neccesary.
    > Jul 12 14:06:51 CBS009 pppd[3380]: using channel 15
    > Jul 12 14:06:51 CBS009 pppd[3380]: Using interface ppp0
    > Jul 12 14:06:51 CBS009 pppd[3380]: Connect: ppp0 <--> /dev/ttyS1
    > Jul 12 14:06:51 CBS009 pppd[3380]: sent [LCP ConfReq id=0x1 > 0x0> ]


    The CHAP request suggests to me that one of the following is true:
    the modified pppd is broken, the options.ttyS1 file is not read, or
    the "auth" on the pppd command line for AutoPPP overrides require-pap
    and refuse-chap in options.ttyS1 allowing either authentication.

    Out of curiosity, since require-pap is specified why specify
    refuse-chap too?

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* 97.3% of all statistics are made up. */

  12. Re: Authentication with PAP & CHAP

    I built the configuration files from HOWTOs and the pppd manpage, so
    I'll admit that not everything is necessary. SuSE is not my favourite
    distro, but it is the one that the company has standardised on and all
    contractors are forced to use it.

    It does seem that the "options.ttyS1" is read, because the client is
    assigned 172.16.0.14 and everything else when I put them in the
    "chap-secrets" file. What's funny is that if I disable pptpd and remove
    the "options.pptpd" and "chap-secrets" files, the dialin users can only
    authenticate with PAP (as defined in "options.ttyS1").

    I only want CHAP on the VPN for security reasons and all the VPN
    clients are Windows XP machines, so I also want to force the strongest
    authentication possible. Since the dialin is a direct line, security
    isn't such a big problem.

    Why must I remove "netmask 255.255.254.0"? What does it do?


  13. Re: Authentication with PAP & CHAP

    risadler wrote:
    In article <1121582979.276386.285970@g47g2000cwa.googlegroups. com> you wrote:
    > It does seem that the "options.ttyS1" is read, because the client is
    > assigned 172.16.0.14 and everything else when I put them in the
    > "chap-secrets" file.


    That would appear to support the thesis that the "auth" in the AutoPPP
    line overrides the require, refuse options in options.ttyS1. In that
    case, by default, CHAP is the first authentication protocol to be
    requested.

    What's funny is that if I disable pptpd and remove
    > the "options.pptpd" and "chap-secrets" files, the dialin users can only
    > authenticate with PAP (as defined in "options.ttyS1").


    If "auth" overrides the authentication options in options.ttyS1 and
    there's no chap-secrets file then PAP becomes the default.

    Have you tried removing "auth" from the AutoPPP line?

    > I only want CHAP on the VPN for security reasons and all the VPN
    > clients are Windows XP machines, so I also want to force the strongest
    > authentication possible. Since the dialin is a direct line, security
    > isn't such a big problem.


    > Why must I remove "netmask 255.255.254.0"? What does it do?


    You can read about the netmask option in the pppd 2.4.1 man pages
    but I never fully understood what they said about it. The option was
    removed from the pppd 2.4.2 man pages, although it appears to still be
    implemented in pppd. I am fairly sure you don't need to remove it -
    everything should work okay whether it's there or not.

    -- Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"
    PPP-Q&A links, downloads: http://ckite.no-ip.net/
    /* The wealth of a nation is created by the productive labor of its
    * citizens. */

  14. Re: Authentication with PAP & CHAP

    Clifford Kite wrote:
    >> Jul 12 14:06:51 CBS009 pppd[3380]: sent [LCP ConfReq id=0x1 >> 0x0> ]


    > The CHAP request suggests to me that one of the following is true:
    > the modified pppd is broken, the options.ttyS1 file is not read, or
    > the "auth" on the pppd command line for AutoPPP overrides require-pap
    > and refuse-chap in options.ttyS1 allowing either authentication.


    > Out of curiosity, since require-pap is specified why specify
    > refuse-chap too?


    Sorry, the question doesn't make sense and the "auth" in AutoPPP won't
    override refuse-chap. I failed to review the meaning of require-xxx
    and refuse-xxx (require-xxx is used by the authenticator and refuse-xxx
    by the authenticatee).

    --
    Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"

  15. Re: Authentication with PAP & CHAP

    "risadler" writes:

    >I built the configuration files from HOWTOs and the pppd manpage, so
    >I'll admit that not everything is necessary. SuSE is not my favourite
    >distro, but it is the one that the company has standardised on and all
    >contractors are forced to use it.


    If you have any control at all, you might download the pppd source code
    from ftp.samba.org and compile and install it. That way you will have
    something which SUSE has not broken for you.


    >It does seem that the "options.ttyS1" is read, because the client is
    >assigned 172.16.0.14 and everything else when I put them in the
    >"chap-secrets" file. What's funny is that if I disable pptpd and remove
    >the "options.pptpd" and "chap-secrets" files, the dialin users can only
    >authenticate with PAP (as defined in "options.ttyS1").


    Hmm sounds like it is reading both, and applying the last one read.


    >I only want CHAP on the VPN for security reasons and all the VPN


    What security reasons?
    Chap's advantage is in slightly greater resistance to eavesdropping.
    Note that Windows chap-ms2 has no advantage over ordinary chap. It was
    instituted by MS because their first version was a joke. However it might
    be needed for MPPE.


    >clients are Windows XP machines, so I also want to force the strongest
    >authentication possible. Since the dialin is a direct line, security
    >isn't such a big problem.


    >Why must I remove "netmask 255.255.254.0"? What does it do?


    It does nothing. That is why you should remove it. ppp is point to point.
    Ie, it is from one specific IP address to another specific IP address. thus
    the netmask is always 255.255.255.255 any other routing is done by your
    system's routing tables. They can of course use the ppp link as a gateway,
    but ppp itself does nothing to the routing (well, except for installing a
    default route if none exists and if you ask it to).




+ Reply to Thread