auth eap

auth eap

[David Corbin]

I'm trying to get a PPTP tunnel running (on a gentoo client).  The tunnel 
tries to start, but then fails.  At the end is my output from attempting to 
diagnose the failure.

From the "No auth is possible", and the "auth eap", I assume there is a 
problem with the way something is built on my system, but I can find very 
little useful information about 'eap'.

Can anyone point me in the right direction?  
Thanks
David


Connect: ppp0 <--> /dev/pts/4
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1400> <auth eap> <magic 0x110e0fd3> <pcomp> 
<accomp> <callback CBCP> <mrru 1614> <endpoint 
[local:ca.14.8c.08.a1.f5.4f.e5.82.f7.00.db.32.c5.73.48.00.00.00.00]> < 17 04 
00 24>]
No auth is possible
sent [LCP ConfRej id=0x0 <auth eap> <callback CBCP> <mrru 1614> < 17 04 00 
24>]
rcvd [LCP ConfAck id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
rcvd [LCP TermReq id=0x1 11 0e 0f d3 00 3c cd 74 00 00 03 97]
sent [LCP TermAck id=0x1]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0xe7f43b5b> <pcomp> 
<accomp>]
Script pptp vpn.enttek.net --nolaunchpppd finished (pid 7810), status = 0x0
Modem hangup
Connection terminated.

Re: auth eap

[James Carlson]

David Corbin writes:
> I'm trying to get a PPTP tunnel running (on a gentoo client).  The tunnel 
> tries to start, but then fails.  At the end is my output from attempting to 
> diagnose the failure.
> 
> >From the "No auth is possible", and the "auth eap", I assume there is a 
> problem with the way something is built on my system, but I can find very 
> little useful information about 'eap'.

The "no auth is possible" message means that there are no valid
credentials for the protocol requested by the peer (nothing usable in
the various /etc/ppp/*_secrets files), so there's no point even trying
to authenticate.

EAP (Extensible Authentication Protocol) is somewhat like a transport
protocol.  It can carry any of a wide range of "authentication
methods" -- what you might call protocols.

In the current ppp-2.4 sources, there's support for the RFC-required
MD5-Challenge (using /etc/ppp/chap-secrets) and draft SRP-SHA1 (using
/etc/ppp/srp-secrets) methods.

Thus "no auth is possible" message means that the pppd didn't find any
usable keys in either location, meaning that no known EAP methods are
usable, and the peer's request for EAP itself can't be satisfied.

Since you're using Microsoft's proprietary PPTP, adding keys to those
files probably won't help.  Your peer is likely planning to insist on
one of the many proprietary EAP methods that pppd doesn't currently
support, and will also require MPPE key exchange for use with tunnel
encryption.

To find out which EAP method is needed, you could either ask the
person who owns that peer system, or set up some temporary credentials
in /etc/ppp/chap-secrets and find out what EAP method the peer
requests.  When it's not one that's implemented by pppd (almost a
certainty), you'll need to go off and find code (a patch) that does
this for you, or implement it yourself.

It might be easier, though, to find patches that support MPPE and
MS-CHAPv2, and ask the owner of that peer system to enable MS-CHAPv2
support.  Though you're still likely to have some trouble getting your
system to support this, I'd expect that'd be more likely to succeed.

For what it's worth (and it might not be much), PPTP is quirky and of
probably questionable value.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: auth eap

[David Corbin]

On Tuesday 19 July 2005 07:36 am, James Carlson wrote:
> David Corbin writes:
> > I'm trying to get a PPTP tunnel running (on a gentoo client).  The tunnel
> > tries to start, but then fails.  At the end is my output from attempting
> > to diagnose the failure.
> >
> > >From the "No auth is possible", and the "auth eap", I assume there is a
> >
> > problem with the way something is built on my system, but I can find very
> > little useful information about 'eap'.
>
> The "no auth is possible" message means that there are no valid
> credentials for the protocol requested by the peer (nothing usable in
> the various /etc/ppp/*_secrets files), so there's no point even trying
> to authenticate.
>
> EAP (Extensible Authentication Protocol) is somewhat like a transport
> protocol.  It can carry any of a wide range of "authentication
> methods" -- what you might call protocols.
>
> In the current ppp-2.4 sources, there's support for the RFC-required
> MD5-Challenge (using /etc/ppp/chap-secrets) and draft SRP-SHA1 (using
> /etc/ppp/srp-secrets) methods.
>
> Thus "no auth is possible" message means that the pppd didn't find any
> usable keys in either location, meaning that no known EAP methods are
> usable, and the peer's request for EAP itself can't be satisfied.

>
> Since you're using Microsoft's proprietary PPTP, adding keys to those
> files probably won't help.  Your peer is likely planning to insist on
> one of the many proprietary EAP methods that pppd doesn't currently
> support, and will also require MPPE key exchange for use with tunnel
> encryption.
>
> To find out which EAP method is needed, you could either ask the
> person who owns that peer system, or set up some temporary credentials
> in /etc/ppp/chap-secrets and find out what EAP method the peer
> requests.  When it's not one that's implemented by pppd (almost a
> certainty), you'll need to go off and find code (a patch) that does
> this for you, or implement it yourself.


But I have /etc/ppp/chap-secrets, with a line like this (appropriate 
substituions apply).

$DOMAIN\\$USERNAME PPTP $PASSWORD *

So, I'm not sure what you by "temporary credentials"

>
> It might be easier, though, to find patches that support MPPE and
> MS-CHAPv2, and ask the owner of that peer system to enable MS-CHAPv2
> support.  Though you're still likely to have some trouble getting your
> system to support this, I'd expect that'd be more likely to succeed.

I'll see if he'll do that.

>
> For what it's worth (and it might not be much), PPTP is quirky and of
> probably questionable value.

yeah.  Well, I *tried* to get them to use a linux-based system, but some 
people are to MS-bound in the head.

Re: auth eap

[James Carlson]

David Corbin writes:
> > To find out which EAP method is needed, you could either ask the
> > person who owns that peer system, or set up some temporary credentials
> > in /etc/ppp/chap-secrets and find out what EAP method the peer
> > requests.  When it's not one that's implemented by pppd (almost a
> > certainty), you'll need to go off and find code (a patch) that does
> > this for you, or implement it yourself.
> 
> 
> But I have /etc/ppp/chap-secrets, with a line like this (appropriate 
> substituions apply).
> 
> $DOMAIN\\$USERNAME PPTP $PASSWORD *
> 
> So, I'm not sure what you by "temporary credentials"

Then I'd have to say that there's either a misconfiguration or bug
somewhere.  Either you're missing the corresponding "user
$DOMAIN\\$USERNAME" option (such that LCP can't 'see' that this entry
would be usable), or it's garbled, or there's a bug in the basic
auth.c code that does the lookup for LCP, or LCP itself has become
mangled.

(The latter two are at least remotely possible ... there've been a few
changes in this area over the years.)

> > For what it's worth (and it might not be much), PPTP is quirky and of
> > probably questionable value.
> 
> yeah.  Well, I *tried* to get them to use a linux-based system, but some 
> people are to MS-bound in the head.

It wouldn't have to be Linux-based to be better.  Just standards-based
would be nice.  Even MS supports some decent standards, but it seems
that you have to push hard to get anyone to configure and use them.
The proprietary goop is the path of least resistance.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: auth eap

[David Corbin]

On Tuesday 19 July 2005 08:11 am, James Carlson wrote:
> David Corbin writes:
> > So, I'm not sure what you by "temporary credentials"
>
> Then I'd have to say that there's either a misconfiguration or bug
> somewhere.  Either you're missing the corresponding "user
> $DOMAIN\\$USERNAME" option (such that LCP can't 'see' that this entry
> would be usable)

You are suggesting the word "user" should appear in a file somewhere, are you?  
Because I don't have that.

> , or it's garbled, or there's a bug in the basic 
> auth.c code that does the lookup for LCP, or LCP itself has become
> mangled.
>

Well, I suppose I can build it and debug it with gdb (or printf).  Any 
particular tips in that area?

Re: auth eap

[James Carlson]

David Corbin writes:
> On Tuesday 19 July 2005 08:11 am, James Carlson wrote:
> > David Corbin writes:
> > > So, I'm not sure what you by "temporary credentials"
> >
> > Then I'd have to say that there's either a misconfiguration or bug
> > somewhere.  Either you're missing the corresponding "user
> > $DOMAIN\\$USERNAME" option (such that LCP can't 'see' that this entry
> > would be usable)
> 
> You are suggesting the word "user" should appear in a file somewhere, are you?  
> Because I don't have that.

It should be part of the pppd configuration, either in one of the
"options" files, or on the pppd command line.  If you don't specify
it, then pppd assumes the system hostname as the default.  Unless your
system hostname happens to be $DOMAIN\\$USERNAME, that's probably not
going to work.  See the pppd man page for details.

> > , or it's garbled, or there's a bug in the basic 
> > auth.c code that does the lookup for LCP, or LCP itself has become
> > mangled.
> >
> 
> Well, I suppose I can build it and debug it with gdb (or printf).  Any 
> particular tips in that area?

The function that's used to determine if there's a viable
MD5-Challenge secret present in the /etc/ppp/chap-secrets file is
have_chap_secret() in pppd/auth.c.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: auth eap

[David Corbin]

On Tuesday 19 July 2005 09:43 am, James Carlson wrote:
> David Corbin writes:
> > On Tuesday 19 July 2005 08:11 am, James Carlson wrote:
> > > David Corbin writes:
> > > > So, I'm not sure what you by "temporary credentials"
> > >
> > > Then I'd have to say that there's either a misconfiguration or bug
> > > somewhere.  Either you're missing the corresponding "user
> > > $DOMAIN\\$USERNAME" option (such that LCP can't 'see' that this entry
> > > would be usable)
> >
> > You are suggesting the word "user" should appear in a file somewhere, are
> > you? Because I don't have that.
>
> It should be part of the pppd configuration, either in one of the
> "options" files, or on the pppd command line.  If you don't specify
> it, then pppd assumes the system hostname as the default.  Unless your
> system hostname happens to be $DOMAIN\\$USERNAME, that's probably not
> going to work.  See the pppd man page for details.

Ah.  It was missing, but I've added it with no effect.  Here's the full debug 
output
 pon enttek-vpn debug dump logfd 2 nodetach
pppd options in effect:
debug           # (from command line)
nodetach                # (from command line)
logfd 2         # (from command line)
dump            # (from command line)
noauth          # (from /etc/ppp/options.pptp)
name enttek\\dev                # (from /etc/ppp/peers/enttek-vpn)
user enttek\\dev                # (from /etc/ppp/peers/enttek-vpn)
remotename PPTP         # (from /etc/ppp/peers/enttek-vpn)
                # (from /etc/ppp/options.pptp)
pty pptp vpn.enttek.net --nolaunchpppd          # 
(from /etc/ppp/peers/enttek-vpn)
mru 1000                # (from /etc/ppp/options.pptp)
mtu 1000                # (from /etc/ppp/options.pptp)
lcp-echo-failure 10             # (from /etc/ppp/options.pptp)
lcp-echo-interval 10            # (from /etc/ppp/options.pptp)
ipparam enttek-vpn              # (from /etc/ppp/peers/enttek-vpn)
nobsdcomp               # (from /etc/ppp/options.pptp)
nodeflate               # (from /etc/ppp/options.pptp)
require-mppe            # (from /etc/ppp/options.pptp)
require-mppe-128                # (from /etc/ppp/peers/enttek-vpn)
using channel 5
Using interface ppp0
Connect: ppp0 <--> /dev/pts/4
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x2d2dd597> <pcomp> 
<accomp>]
rcvd [LCP ConfReq id=0x0 <mru 1400> <auth eap> <magic 0x5b4f7d3f> <pcomp> 
<accomp> <callback CBCP> <mrru 1614> <endpoint 
[local:ca.14.8c.08.a1.f5.4f.e5.82.f7.00.db.32.c5.73.48.00.00.00.00]> < 17 04 
00 26>]
No auth is possible
sent [LCP ConfRej id=0x0 <auth eap> <callback CBCP> <mrru 1614> < 17 04 00 
26>]
rcvd [LCP ConfAck id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x2d2dd597> <pcomp> 
<accomp>]
rcvd [LCP TermReq id=0x1 "[O}?\000<\37777777715t\000\000\003\37777777627"]
sent [LCP TermAck id=0x1]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x2d2dd597> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x2d2dd597> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x2d2dd597> <pcomp> 
<accomp>]
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x2d2dd597> <pcomp> 
<accomp>]
Terminating on signal 2.
Script pptp vpn.enttek.net --nolaunchpppd finished (pid 8752), status = 0x0
Modem hangup
Connection terminated.


>
> > > , or it's garbled, or there's a bug in the basic
> > > auth.c code that does the lookup for LCP, or LCP itself has become
> > > mangled.
> >
> > Well, I suppose I can build it and debug it with gdb (or printf).  Any
> > particular tips in that area?
>
> The function that's used to determine if there's a viable
> MD5-Challenge secret present in the /etc/ppp/chap-secrets file is
> have_chap_secret() in pppd/auth.c.

Thanks.