Reproducing an issue I raised on the github repo here.

--- Environment ---
OS: Arch Linux
pppd version 2.4.9
xl2tpd version 1.3.17
IPSec version Linux strongSwan U5.9.4/K5.16.5-arch1-1
---

--- START OF Config files ---
--- START OF xl2tpd.conf ---
[global]
access control = no
auth file = /etc/ppp/chap-secrets
debug avp = yes
debug network = yes
debug packet = yes
debug state = yes
debug tunnel = yes

[lac MY_CONNECTION]
lns = REMOTE_IP_ADDRESS
refuse pap = yes
refuse chap = yes
require authentication = yes
ppp debug = yes
pppoptfile = /etc/ppp/options.l2tpd.client
length bit = yes
hidden bit = yes
name = MY_NAME
--- END OF xl2tpd.conf ---

--- START OF options.l2tpd.client ---
ipcp-accept-local
ipcp-accept-remote
debug
dump
noauth
noccp
refuse-eap
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe
mppe-stateful
nodefaultroute
name MY_NAME
remotename REMOTE_NAME
proxyarp
--- END OF options.l2tpd.client ---
--- END OF Config files ---


I am trying to setup a L2TP/IPSec client on Arch Linux. The

with <t2g132$qns$[email protected]> Bidski wrote:

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*

--- START OF xl2tpd.conf ---
[global]

*SKIP*

auth file = /etc/ppp/chap-secrets

*SKIP*

[lac MY_CONNECTION]

*SKIP*

refuse pap = yes
refuse chap = yes
require authentication = yes

*SKIP*

--- START OF options.l2tpd.client ---

*SKIP*

noauth

*SKIP*

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*

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,..

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.

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,..

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.

--- 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:

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.

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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 9/4/22 06:11, Eric Pozharski wrote:

with <t2g132$qns$[email protected]> 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

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.

--- 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.

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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <t2uiqt$orq$[email protected]> Bidski wrote:

On 9/4/22 06:11, Eric Pozharski wrote:

with <t2g132$qns$[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 13/4/22 20:09, Eric Pozharski wrote:

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?

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

with <t478hb$c9v$[email protected]> Bidski wrote:

On 13/4/22 20:09, Eric Pozharski wrote:

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.

My guess would be that you didn't get rid of 'require-*' and 'refuse-*'
lines of 'options.l2tpd.client'. I speculate (without logs of pppd) you
are back to square one (maybe square one-and-a-quarter).

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.

I'm not xl2tpd user but my understanding is you're not supposed to touch *underlying* ppp-link. I speculate (without xl2tpd logs) you're
breaking it even more.

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?

With breakage that enormous any behaviour is possible. Though the
breakage isnt FUBAR yet.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)