Page MenuHomeVyOS Platform

L2TP breaks after upgrading to VyOS 1.2-rolling-201910180117 [issue report and proposed solution]
Closed, ResolvedPublicBUG


I have upgraded from a VyOS 1.2 rolling build from April, when VyOS was using xl2tpd. I am now using VyOS 1.2-rolling-201910180117.

Unfortunately the L2TP (over IPsec) VPN connections do not seem to work anymore.

The clients do establish the IPSec, and I can see the IPsec associations with show vpn ipsec sa. I also see the ppp* devices with ip link show. Even running show vpn remote-access I briefly see those connections, but with an empty ip column.

Looking into the logs with journalctl I see (retaining only ppp related stuff, and anonymizing it):

ppp2:client-z: connect: ppp2 <--> l2tp(<IP>:<PORT> session <...>, <...>)
ppp2:client-z: ppp connected
ppp2:client-z: send [MSCHAP-v2 Success id=1 "S=<...> M=Authentication succeeded"]
ppp2:client-z: auth_layer_started
ppp2:client-z: ccp_layer_start
ppp2:client-z: send [CCP ConfReq id=c7 <mppe +H -M +S -L -D -C>]
ppp2:client-z: ipcp_layer_start
ppp2:client-z: ipv6cp_layer_start
ppp2:client-z: client-z: authentication succeeded
ppp2:client-z: recv [IPCP ConfReq id=4f <addr>]
ppp2:client-z: ppp: no free IPv4 address
ppp2:client-z: send [LCP ProtoRej id=179 <8021>]
ppp2:client-z: recv [LCP ProtoRej id=e0 <80fd>]
ppp2:client-z: ccp_layer_finished
ppp2:client-z: recv [LCP EchoReq id=0 <magic 0ad2be63>]
ppp2:client-z: send [LCP EchoRep id=0 <magic 230139d4>]
ppp2:client-z: terminate
ppp2:client-z: lcp_layer_finish

The problematic line seems to be ppp2:client-z: ppp: no free IPv4 address.

My vpn l2tp remote-access configuration is pretty standard:

authentication {
 local-users {
     username client-z {
         password <...>
         static-ip x1.x2.x3.2
 mode local
 require mschap-v2
client-ip-pool {
 start x1.x2.x3.67
 stop x1.x2.x3.93
dns-servers {
idle 86400
ipsec-settings {
 authentication {
     mode pre-shared-secret
     pre-shared-secret <...>
 ike-lifetime 86400
 lifetime 86400
mtu 1400
ppp-options {
 lcp-echo-failure 30
 lcp-echo-interval 12

However I did seem to track the problem in the /etc/accel-ppp/l2tp/l2tp.config file, where by manually adding the following line to both the [ip-pool] and [chap-secrets] section, everything worked again as expected (replace that with a proper IP from the same pool):



Difficulty level
Easy (less than an hour)
Why the issue appeared?
Will be filled on close
Is it a breaking change?
Behavior change

Related Objects

Event Timeline

Dmitry added a subscriber: Dmitry.Oct 19 2019, 9:30 AM

You can set outside-nexthop which fixed this. Also I think we can calculate first ip for gw-ip-address if outside-nexthop is not defined by cli.

@Dmitry Thanks for pointing that out, I've looked on the wiki ( and searched for a description for outside-nexthop, and failed to find it, and the in-line help while configuring doesn't help much.

Thus based on your input I've looked in /usr/libexec/vyos/conf_mode/, and indeed it seems to do as you've described, but it does so only for the [ip-pool] section, not also for the [chap-secrets] section:

{% if (client_ip_pool) or (client_ip_subnets) %}
{% if client_ip_pool %}
{% endif -%}
{% if client_ip_subnets %}
{% for sn in client_ip_subnets %}
{% endfor -%}
{% endif %}
{% endif %}
{% if outside_nexthop %}
{% endif %}

{% if authentication['mode'] == 'local' %}
{% endif %}

I've patched my version to include:

{% if authentication['mode'] == 'local' %}
{% if outside_nexthop %}
{% endif %}
{% endif %}

And I've configured outside-nexthop accordingly, and now it seems it works correctly.

I would suggest making outside-nexthop mandatory (as it doesn't work without it), and also adding it to the [chap-secrets] section.


I think better calculate gw-ip-address automatically. outside-nexthop excluded from required for migration reasons.
Not necessary define gw-ip-address in [chap-secrets] section, it works without any issue if defined it in [ip-pool] only.

Unfortunately it doesn't work without gw-ip-address also in [chap-secrets]. In my early trials I've tried that, and the clients received IP's from the pool instead the static values.

Also I think it is a good idea to leave the outside-nexthop, because for example one can configure a pool which doesn't include statically configured values. (For example I've configured my router 1, the static clients 5 through 60, and left a pool from 67 to 93 for unassigned ones.)

(I know this is a point-to-point, and it will work, but for simplicity I think it's better to keep the "impression" of a normal LAN to the clients.)

Agree with you, thank you. We need fixed these moments.

c-po assigned this task to Dmitry.Oct 19 2019, 10:14 AM
pasik added a subscriber: pasik.Oct 20 2019, 1:21 PM
Dmitry changed the task status from Open to In progress.Nov 6 2019, 11:16 PM
syncer changed the task status from In progress to Backport candidate.Nov 16 2019, 11:08 PM
syncer reassigned this task from Dmitry to jestabro.
syncer triaged this task as Normal priority.
syncer moved this task from Need Triage to Finished on the VyOS 1.3 Equuleus board.
syncer moved this task from Needs Triage to Backlog on the VyOS 1.2 Crux (VyOS 1.2.4) board.

This is not a backport candidate until 'T834: accel-ppp: l2tp implementation' has been backported.

jestabro closed this task as Resolved.Jan 29 2020, 8:55 PM