Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.protocols.ppp > #127

Re: "CHAP authentication succeeded" followed by "Authentication failed"

Show all headers | View raw

with <t2uiqt$orq$1@bidski.eternal-september.org> Bidski wrote:
> On 9/4/22 06:11, Eric Pozharski wrote:
>> with <t2g132$qns$1@bidski.eternal-september.org> Bidski wrote:

>>> Reproducing an issue I raised on the github repo here.
> Github issue can be found here
> https://github.com/ppp-project/ppp/issues/335
>> Disclaimer:  I have no idea what 'xl2tpd' is, supposedely some VPN
>> establishing thing.  Now,
> xl2tpd is https://github.com/xelerance/xl2tpd, the Xelerance
> implementation of the Layer 2 Tunneling Protocol

Oh boy, don't get me started on this.  OTOH, it should be crystal clear
now -- you're on your own.

>> something doesn't feel right about this.  I'm not sure that xl2tpd
>> and pppd are supposed to share passwords and/or secrets.  I'm not
>> sure 'noauth' and 'require-whatever' are supposed to work.  I'm not
>> sure it's clear what 'noauth' does.
> My understanding of 'noauth' is that it is meant to prevent 'pppd'
> from requiring the peer to authenticate itself. To my understanding
> this is what I want to happen. I need to authenticate myself to the
> peer (which is why there is "<auth chap MS-v2>" stuff in the log
> files), but the peer doesn't need to authenticate itself to me. My
> understanding from what was said in the github issue is that the "CHAP
> Response" stuff is the result of me trying to make the peer
> authenticate itself to me.

It's probably too late to be upfront but let me declare it now.  Neither
me nor c.p.p. in general do support (where is everyone anyway).  All I
can do is point out misconceptions.  Let's reiterate.

Now, it's all too easy to drift to client-server model, while PPP isn't.
Both peers are equal while asymetrically configured.  IOW, no amount of
configuration will force remote to accept authentication *from* you,
unless the remote is configured to ask for it (from your logs: remote
peer isn't asking you to autheticate).  No amount of configuration will
avoid you authenticating *to* remote, if the remote is configured to ask
for it (from your logs: remote peer clearly doesn't care).

It should be clear by now -- you're fighting software in lack of
documentation.  (Case in point.  Per your 'xl2tpd.conf'.  "LAC" section
of 'xl2tpd.conf' doesn't use any documented options (except 'lns').
OTOH, none option in use in this section (except 'lns') is documented.)
I speculate, that 'xl2tpd.conf' in use is based on something that was
found over there on The Interwebs.  Was it working?  Yes, it was working
with some other peer that was configured differently.

Meanwhile, I suggest dropping all 'require-*' and 'refuse-*' lines from
'options.l2tpd.client', keeping 'ipcp-accept-*';  moving 'chap-secrets'
to '/etc/xl2tpd/l2tp-secrets' (I insist, where it belongs);  adjusting
'auth file' line of 'xl2tpd.conf' accordingly;  and try xl2tpd again.
Look, it's not working now, it might not work differently.

>>> --- START OF LOG OUTPUT 2 --- pppd[263275]: local  IP address
>>> 192.168.187.113
>> Retorical question, where this comes from?  Your 'options.*' (for
>> pppd) clearly states:
> This IP address would have been the address that was assigned to me (I
> assume by the VPN peer?) when the connection to the VPN was
> established and authenticated. My LAN is on a 10.0.X.X subnet.

This answers other question.  I'm not asking *what* it is (for the
purpose of PPP it's irrelevant).  I'm asking *where* it comes from
(neither 'options.*', nor command line of pppd, nor 'xl2tpd.conf', nor
inter-peer communications mention this one).  This was rhetorical
question.

>> I hope, you already set up your tunnel then you can ignore this.
> Unfortunately, I am still no closer to getting this connection working
> yet. At this point I am very lost in the sea of options and log
> outputs.

Pity.  It's quite untimely.

-- 
Torvalds' goal for Linux is very simple: World Domination
Stallman's goal for GNU is even simpler: Freedom

Back to comp.protocols.ppp | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

"CHAP authentication succeeded" followed by "Authentication failed" Bidski <bidskii@gmail.com> - 2022-04-05 10:04 +1000
  Re: "CHAP authentication succeeded" followed by "Authentication failed" Eric Pozharski <whynot@pozharski.name> - 2022-04-08 20:11 +0000
    Re: "CHAP authentication succeeded" followed by "Authentication failed" Bidski <bidskii@gmail.com> - 2022-04-10 22:33 +1000
      Re: "CHAP authentication succeeded" followed by "Authentication failed" Eric Pozharski <whynot@pozharski.name> - 2022-04-13 10:09 +0000
        Re: "CHAP authentication succeeded" followed by "Authentication failed" Bidski <bidskii@gmail.com> - 2022-04-26 08:49 +1000
          Re: "CHAP authentication succeeded" followed by "Authentication failed" Eric Pozharski <whynot@pozharski.name> - 2022-04-27 11:56 +0000

csiph-web