"CHAP authentication succeeded" followed by "Authentication failed"

[Bidski]

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 IPSec
connection appears to work fine, but when setting up the L2TP connection
on top of the IPSec connection I see the following output and I have no
idea what to make of it. I'm not sure if this is a bug or just bad
settings on my part, but after hours of googling and trying variations
of the settings I am getting nowhere.

The basic details of the VPN are L2TP/IPSec with a PSK, I also have a
username/password that I need to connect with. These are the details
that the IT guys give everyone to connect to the VPN. I believe the
server is a Windows server (possibly with Cisco equipment). These are
also all of the details needed for a Windows machine to connect to the VPN.

I have tried many different variations of options and settings. I have
tried setting require authentication = no and refuse authentication =
yes in the xl2tpd.conf file, but this didnt seem to have any impact.

After some more playing around I discovered that adding 'allow-ip
REMOTE_IP_ADDRESS' to /etc/ppp/options.l2tpd.client and removing
'REMOTE_NAME NY_NAME "secret" *' from /etc/ppp/chap-secrets allows
xl2tpd/pppd to proceed to the point where I get a ppp0 device showing up
in 'ip a' and 'ip route' showed 'REMOTE_IP_ADDRESS dev ppp0 proto kernel
scope link src 192.168.187.113'.

Unfortunately, I was unable to setup a route so that all VPN traffic
would be routed through ppp0. The second set of system logs shows the
output I am getting after setting 'allow-ip'

---
ip route add 192.168.0.0/16 via REMOTE_IP_ADDRESS dev ppp0
Error: Nexthop has invalid gateway.
---

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


--- START OF LOG OUTPUT ---
pppd[74443]: sent [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2>
<magic MAGIC_NUM_1>]
xl2tpd[74437]: xl2tpd[74437]: network_thread: recv packet from
REMOTE_IP_ADDRESS, size = 12, tunnel = 16877, call = 36693 ref=0 refhim=0
xl2tpd[74437]: xl2tpd[74437]: network_thread: recv packet from
REMOTE_IP_ADDRESS, size = 36, tunnel = 16877, call = 36693 ref=0 refhim=0
xl2tpd[74437]: xl2tpd[74437]: message_type_avp: message type 16
(Set-Link-Info)
xl2tpd[74437]: xl2tpd[74437]: ignore_avp : Ignoring AVP
xl2tpd[74437]: xl2tpd[74437]: control_finish: message type is
Set-Link-Info(16). Tunnel is 754, call is 754.
pppd[74443]: rcvd [LCP ConfReq id=0x1 <auth chap MS-v2> <magic MAGIC_NUM_2>]
pppd[74443]: sent [LCP ConfAck id=0x1 <auth chap MS-v2> <magic MAGIC_NUM_2>]
pppd[74443]: rcvd [LCP ConfRej id=0x1 <asyncmap 0x0>]
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]: PPPoL2TP options: debugmask 0
pppd[74443]: sent [LCP EchoReq id=0x0 magic=MAGIC_NUM_1]
pppd[74443]: sent [CHAP Challenge id=0x52 <CHAP_CHALLENGE_SEND>, name =
"MY_NAME"]
pppd[74443]: rcvd [CHAP Challenge id=0x1 <CHAP_CHALLENGE_RECV>, name = ""]
pppd[74443]: added response cache entry 0
pppd[74443]: sent [CHAP Response id=0x1 <CHAP_RESPONSE>, name = "MY_NAME"]
pppd[74443]: rcvd [LCP EchoRep id=0x0 magic=0x6a67adb7]
pppd[74443]: rcvd [CHAP Response id=0x52 <>, name = ""]
pppd[74443]: rcvd [CHAP Success id=0x1 "S=CHAP_SUCCESS"]
pppd[74443]: response found in cache (entry 0)
pppd[74443]: CHAP authentication succeeded
xl2tpd[74437]: xl2tpd[74437]: network_thread: select timeout with max
retries: 5 for tunnel: 16877
xl2tpd[74437]: xl2tpd[74437]: network_thread: select timeout with max
retries: 5 for tunnel: 16877
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 = ""]
xl2tpd[74437]: xl2tpd[74437]: network_thread: select timeout with max
retries: 5 for tunnel: 16877
pppd[74443]: sent [CHAP Challenge id=0x52 <CHAP_CHALLENGE_SEND>, name =
"MY_NAME"]
pppd[74443]: rcvd [CHAP Response id=0x52 <>, name = ""]
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 [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 [CHAP Challenge id=0x52 <CHAP_CHALLENGE_SEND>, name =
"MY_NAME"]
pppd[74443]: rcvd [CHAP Response id=0x52 <>, name = ""]
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 [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 [CHAP Challenge id=0x52 <CHAP_CHALLENGE_SEND>, name =
"MY_NAME"]
pppd[74443]: rcvd [CHAP Response id=0x52 <>, name = ""]
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 EchoReq id=0x1 magic=MAGIC_NUM_1]
pppd[74443]: rcvd [LCP EchoRep id=0x1 magic=MAGIC_NUM_2]
pppd[74443]: PPPoL2TP options: debugmask 0
pppd[74443]: sent [LCP TermReq id=0x3 "Authentication failed"]
pppd[74443]: rcvd [CHAP Response id=0x52 <>, name = ""]
pppd[74443]: Discarded non-LCP packet when LCP not open
pppd[74443]: rcvd [LCP TermAck id=0x3]
pppd[74443]: Connection terminated.
pppd[74443]: Exit.

--- END OF LOG OUTPUT ---

--- START OF LOG OUTPUT 2 ---
xl2tpd[263263]: xl2tpd[263263]: Not looking for kernel SAref support.
xl2tpd[263263]: xl2tpd[263263]: Using l2tp kernel support.
xl2tpd[263263]: xl2tpd[263263]: xl2tpd version xl2tpd-1.3.17 started on
bidski-beast PID:263263
xl2tpd[263263]: xl2tpd[263263]: Written by Mark Spencer, Copyright (C)
1998, Adtran, Inc.
xl2tpd[263263]: xl2tpd[263263]: Forked by Scott Balmos and David Stipp,
(C) 2001
xl2tpd[263263]: xl2tpd[263263]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[263263]: xl2tpd[263263]: Forked again by Xelerance
(www.xelerance.com) (C) 2006-2016
xl2tpd[263263]: xl2tpd[263263]: Listening on IP address 0.0.0.0, port 1701
xl2tpd[263263]: xl2tpd[263263]: Connecting to host REMOTE_IP_ADDRESS,
port 1701
xl2tpd[263263]: xl2tpd[263263]: Connection established to
REMOTE_IP_ADDRESS, 1701. Local: 32106, Remote: 1448 (ref=0/0).
xl2tpd[263263]: xl2tpd[263263]: Calling on tunnel 32106
xl2tpd[263263]: xl2tpd[263263]: Call established with REMOTE_IP_ADDRESS,
Local: 41268, Remote: 1448, Serial: 1 (ref=0/0)
xl2tpd[263263]: xl2tpd[263263]: start_pppd: I'm running:
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"
pppd[263275]: Plugin pppol2tp.so loaded.
pppd[263275]: pppd 2.4.9 started by root, uid 0
pppd[263275]: Using interface ppp0
pppd[263275]: Connect: ppp0 <-->
pppd[263275]: CHAP authentication succeeded
pppd[263275]: Cannot determine ethernet address for proxy ARP
pppd[263275]: local IP address 192.168.187.113
pppd[263275]: remote IP address REMOTE_IP_ADDRESS
xl2tpd[263263]: xl2tpd[263263]: Can not find tunnel 1448 (refhim=0)
xl2tpd[263263]: xl2tpd[263263]: network_thread: unable to find call or
tunnel to handle packet. call = 1448, tunnel = 1448 Dumping.
xl2tpd[263263]: xl2tpd[263263]: Can not find tunnel 1448 (refhim=0)
xl2tpd[263263]: xl2tpd[263263]: network_thread: unable to find call or
tunnel to handle packet. call = 1448, tunnel = 1448 Dumping.

...... SNIP ......

xl2tpd[263263]: xl2tpd[263263]: udp_xmit failed to
REMOTE_IP_ADDRESS:1701 with err=-1:Permission denied
xl2tpd[263263]: xl2tpd[263263]: udp_xmit failed to
REMOTE_IP_ADDRESS:1701 with err=-1:Permission denied
xl2tpd[263263]: xl2tpd[263263]: udp_xmit failed to
REMOTE_IP_ADDRESS:1701 with err=-1:Permission denied
xl2tpd[263263]: xl2tpd[263263]: udp_xmit failed to
REMOTE_IP_ADDRESS:1701 with err=-1:Permission denied
xl2tpd[263263]: xl2tpd[263263]: Can not find tunnel 1448 (refhim=0)
xl2tpd[263263]: xl2tpd[263263]: network_thread: unable to find call or
tunnel to handle packet. call = 1448, tunnel = 1448 Dumping.
xl2tpd[263263]: xl2tpd[263263]: Can not find tunnel 1448 (refhim=0)
xl2tpd[263263]: xl2tpd[263263]: network_thread: unable to find call or
tunnel to handle packet. call = 1448, tunnel = 1448 Dumping.

...... SNIP ......

xl2tpd[263263]: xl2tpd[263263]: Maximum retries exceeded for tunnel
32106. Closing.
xl2tpd[263263]: xl2tpd[263263]: udp_xmit failed to
REMOTE_IP_ADDRESS:1701 with err=-1:Permission denied
xl2tpd[263263]: xl2tpd[263263]: Terminating pppd: sending TERM signal to
pid 263275
xl2tpd[263263]: xl2tpd[263263]: Connection 1448 closed to
REMOTE_IP_ADDRESS, port 1701 (Timeout)
pppd[263275]: Terminating on signal 15
pppd[263275]: Connect time 1.6 minutes.
pppd[263275]: Sent 242566 bytes, received 0 bytes.
pppd[263275]: Connection terminated.
pppd[263275]: Exit.
xl2tpd[263263]: xl2tpd[263263]: Unable to deliver closing message for
tunnel 32106. Destroying anyway.
--- END OF LOG OUTPUT 2 ---

[Eric Pozharski]

with <t2g132$qns$1...@bidski.eternal-september.org> 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

[Bidski]

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

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

[Eric Pozharski]

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.

[Bidski]

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?

[Eric Pozharski]

with <t478hb$c9v$1...@bidski.eternal-september.org> 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.