"CHAP authentication succeeded" followed by "Authentication failed"

Post by Bidski
Reproducing an issue I raised on the github repo here.

Unless the problem has been raised privately (I know nothing about
github's inner workings) URL would be helpful. If the problem has been
resolved then please ignore.

Disclaimer: I have no idea what 'xl2tpd' is, supposedely some VPN
establishing thing. Now,

*SKIP*

Post by Bidski
--- START OF xl2tpd.conf ---
[global]

*SKIP*

Post by Bidski
auth file = /etc/ppp/chap-secrets

*SKIP*

Post by Bidski
[lac MY_CONNECTION]

*SKIP*

Post by Bidski
refuse pap = yes
refuse chap = yes
require authentication = yes

*SKIP*

Post by Bidski
--- START OF options.l2tpd.client ---

*SKIP*

Post by Bidski
noauth

*SKIP*

Post by Bidski
refuse-mschap
require-mschap-v2

*SKIP*

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.

*SKIP*

Post by Bidski
Unfortunately, I have no idea what is going on here. Can anyone help me
get this sorted out?

Disclaimer, I don't have to deal with authentication like at all.
Without this I can't get my hands dirty (aka -- reading RFCs). But,..

First, you're preseneting two logfiles, keeping timestamps would be
helpful. Now, out of order,..

Post by Bidski
pppd[74443]: sent [LCP ConfReq id=0x2 <auth chap MS-v2> <magic MAGIC_NUM_1>]
pppd[74443]: rcvd [LCP ConfAck id=0x2 <auth chap MS-v2> <magic MAGIC_NUM_1>]
pppd[74443]: sent [LCP EchoReq id=0x0 magic=MAGIC_NUM_1]
pppd[74443]: rcvd [LCP EchoRep id=0x0 magic=0x6a67adb7]

Rest assured, magic numbers are for detecting loops. They don't have
anything to do with security or privacy. OTOH, you're obscuring them
inconsistently.

Post by Bidski
pppd[74443]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2>
<magic MAGIC_NUM_1>]

Here, yours 'require-mschap-v2' has beaten yours 'noauth'. Still,..

Post by Bidski
pppd[74443]: rcvd [CHAP Success id=0x1 "S=CHAP_SUCCESS"]
pppd[74443]: CHAP authentication succeeded
pppd[74443]: sent [CHAP Challenge id=0x52 <CHAP_CHALLENGE_SEND>, name =
"MY_NAME"]
pppd[74443]: rcvd [CHAP Response id=0x52 <>, name = ""]
pppd[74443]: rcvd [CHAP Response id=0x52 <>, name = ""]
pppd[74443]: sent [LCP TermReq id=0x3 "Authentication failed"]

Speculation, it's possible that windops and/or event-driven programming
is involved. Your peer authenticates you oportunisticaly while hoping
to figure out your secret any time soon. It doesn't happen. Then *you*
dis-authenticate your peer. I'm not sure this is how it is supposed to
work.

Post by Bidski
--- START OF LOG OUTPUT 2 ---
pppd[263275]: local IP address 192.168.187.113

Retorical question, where this comes from? Your 'options.*' (for pppd)

Post by Bidski
ipcp-accept-local
ipcp-accept-remote

Still, I don't see in your debug-log "sent [IPCP ConfReq <addr
0.0.0.0>]" (some fields are skipped for brevity). Neither I see "rcvd
[IPCP ConfReq <addr 10.10.10.10>]" (brevity again, actual IP address may
be whatever). This is not how 'ipcp-accept-local' is supposed to work.

Post by Bidski
xl2tpd[263263]: xl2tpd[263263]: "/usr/sbin/pppd"
xl2tpd[263263]: xl2tpd[263263]: "plugin"
xl2tpd[263263]: xl2tpd[263263]: "pppol2tp.so"
xl2tpd[263263]: xl2tpd[263263]: "pppol2tp"
xl2tpd[263263]: xl2tpd[263263]: "7"
xl2tpd[263263]: xl2tpd[263263]: "passive"
xl2tpd[263263]: xl2tpd[263263]: "nodetach"
xl2tpd[263263]: xl2tpd[263263]: ":"
xl2tpd[263263]: xl2tpd[263263]: "refuse-pap"
xl2tpd[263263]: xl2tpd[263263]: "refuse-chap"
xl2tpd[263263]: xl2tpd[263263]: "name"
xl2tpd[263263]: xl2tpd[263263]: "MY_NAME"
xl2tpd[263263]: xl2tpd[263263]: "file"
xl2tpd[263263]: xl2tpd[263263]: "/etc/ppp/options.l2tpd.client"

Without grepping through code of pppd I can't say who will win
command-line options or options sourced from whatever 'file' points to.
I suppose in order of sourcing.

Post by Bidski
pppd[263275]: Sent 242566 bytes, received 0 bytes.

I believe 'xl2tpd' is talking to /dev/null. This would explain why your
tunnel fails.

I hope, you already set up your tunnel then you can ignore this.

*CUT*

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

Bidski

2022-04-10 12:33:35 UTC

Post by Bidski
Reproducing an issue I raised on the github repo here.

Github issue can be found here https://github.com/ppp-project/ppp/issues/335

Post by Eric Pozharski
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

Post by Eric Pozharski
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.

Post by Bidski
--- START OF LOG OUTPUT 2 ---
pppd[263275]: local IP address 192.168.187.113

Retorical question, where this comes from? Your 'options.*' (for pppd)

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.

Post by Eric Pozharski
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.

Eric Pozharski

2022-04-13 10:09:43 UTC

Post by Bidski
Reproducing an issue I raised on the github repo here.

Github issue can be found here
https://github.com/ppp-project/ppp/issues/335

Post by Eric Pozharski
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.

Post by Eric Pozharski
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.

Post by Bidski
--- START OF LOG OUTPUT 2 --- pppd[263275]: local IP address
192.168.187.113

Retorical question, where this comes from? Your 'options.*' (for

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.

Post by Eric Pozharski
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

Bidski

2022-04-25 22:49:10 UTC

Post by Eric Pozharski
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.

I tried moving the contents of 'chap-secrets' into 'l2tp-secrets',
however, ppp then complains that "No auth is possible", if I also remove
the line "name MY_NAME" from the ppp options file then no connection is
established at all (literally nothing happens with no output from pppd
or xl2tpd). With "name MY_NAME" and the corresponding secret in
'chap-secrets' ppp will establish and authenticate me to the peer and
with the same secret in 'l2tp-secrets' xl2tpd also authenticates me to
the peer and I have an active connection.

Adding a route to direct all VPN traffic through the ppp0 interface
allows me to ping IP addresses that I know are on the server side of the
connection, and there is a webserver that I can access through my
browser, so that all seems good.

Unfortunately, I am unable to ssh into machines that I know I should be
able to ssh into. I don't currently have the logs available to me at the
moment, but I think ssh is waiting for a response from the remote server
and is not getting it. Do you know if there is anything specific I need
to do to allow ssh to work over the VPN connection?

Eric Pozharski

2022-04-27 11:56:14 UTC