Page MenuHomePhabricator

L2TP breaks after upgrading to VyOS 1.2-rolling-201910180117 [issue report and proposed solution]
In progress, Requires assessmentPublicBUG


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

Event Timeline

Dmitry added a subscriber: Dmitry.Sat, Oct 19, 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.Sat, Oct 19, 10:14 AM
pasik added a subscriber: pasik.Sun, Oct 20, 1:21 PM
Dmitry changed the task status from Open to In progress.Wed, Nov 6, 11:16 PM