Closed jeyfox closed 4 years ago
See issue https://github.com/nm-l2tp/NetworkManager-l2tp/issues/103
You will need network-manger-l2tp >= 1.2.12 which you can get from one of the following :
Many Thanks, upgraded network-manager-l2tp and network-manager-l2tp-gnome to 1.2.16-1~ubuntu18.04.1~ppa1 (ppa:nm-l2tp/network-manager-l2tp) and VPN is now crashing during connect. What details/logs would you need in order to troubleshoot this
Error: Connection activation failed: The VPN service stopped unexpectedly
See Debugging section in the README.md file:
journalctl --unit=NetworkManager --no-hostname
might be enough to spot the issue
To increase debugging, you could use sudo /usr/lib/NetworkManager/nm-l2tp-service --debug
, see the aforementioned README.md file more details, note that you'll still need to use journalctl , e.g. the following will show all output including the l2tp_ppp kernel module output:
journalctl -b --no-hostname
Thanks. Upgraded network-manager-l2tp to 1.2.16-1~ubuntu18.04.1~ppa1 . Have no idea why this crashing compare to previous version 1.2.8 running ok but could not force client to use higher ike_life value. Uploaded logs from nm-l2tp-service --debug and journalctl
Extract from journalctl.log :
#2: initiating Quick Mode PSK+ENCRYPT+PFS+UP+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:b7563b82 proposal=AES_CBC_256-HMAC_SHA2_256_128 pfsgroup=MODP2048}
#2: STATE_QUICK_I1: 60 second timeout exceeded after 7 retransmits. No acceptable response to our first Quick Mode message: perhaps peer likes no proposal
Looks like the VPN server doesn't likes the Phase 2 (Quick Mode) proposal which includes PFS (Perfect Forward Secrecy).
As of NetworkManager-l2tp 1.2.12, PFS is no longer disabled (which is libreswan's default behavior).
Looks like your VPN server doesn't use PFS, as can be confirmed by looking at journalctl.log when the connections that worked didn't use PFS for Quick Mode.
You will need to click the new "Disable PFS" tick box in the IPsec settings to explicitly disable PFS .
Thanks disabling PFS worked. I'm able to successfully create ipsec tunnel with the ike_life settings I want. However another issue come up with random disconnects, no pattern for it. I then upgraded client to 1.8 version and getting 1h disconnect despite ike_life has correct value (checked via ipsec status) Logs attached nm-l2tp-service.log journalctl.log
Regarding the following :
** Message: 14:07:40.505: Check port 1701
** Message: 14:07:40.505: Can't bind to port 1701
nm-l2tp[3933] <warn> L2TP port 1701 is busy, using ephemeral.
As NetworkManager-l2tp starts its own xl2tpd instance, you could stop and disable the system xl2tpd (so that port 1701 is free) :
sudo systemctl stop xl2tpd
sudo systemctl disable xl2tpd
I doubt that has anything to do with the issue, but no harm stopping and disabling the system xl2tpd.
When you use /usr/lib/NetworkManager/nm-l2tp-service --debug
, the /run/nm-l2tp-fa4fffae-3ed6-422f-ac56-c8752b5545ed/ipsec.conf
file will remain behind so you can look at the contents. I believe that generated ipsec.conf
file will be identical for both NetworkManager-l2tp 1.2.16 and 1.8.0, if they are not, there is a bug. If those files are identical as they should be, I can't explain why you are getting a 1hr disconnect with 1.8.0, but not 1.2.16.
That generated ipsec.conf
file can be used for a Libreswan command-line start, e.g. :
sudo ipsec restart
sleep 2
sudo ipsec auto --config /run/nm-l2tp-fa4fffae-3ed6-422f-ac56-c8752b5545ed/ipsec.conf --verbose --add fa4fffae-3ed6-422f-ac56-c8752b5545ed
sudo ipsec auto --up fa4fffae-3ed6-422f-ac56-c8752b5545ed
sudo ipsec status
Actually, I just noticed the following:
NetworkManager[939]: <info> [1580827407.7901] connectivity: (wlp4s0) timed out
wlp4s0
is the WiFi network and it has timed out.
I found a page that has the same WiFi network has timed out error as what you were getting, it has a link to the following "WiFi randomly disconnected on Ubuntu 18.04 LTS" page which has suggested workarounds :
Regarding the following :
** Message: 14:07:40.505: Check port 1701 ** Message: 14:07:40.505: Can't bind to port 1701 nm-l2tp[3933] <warn> L2TP port 1701 is busy, using ephemeral.
As NetworkManager-l2tp starts its own xl2tpd instance, you could stop and disable the system xl2tpd (so that port 1701 is free) :
sudo systemctl stop xl2tpd sudo systemctl disable xl2tpd
I doubt that has anything to do with the issue, but no harm stopping and disabling the system xl2tpd.
Tried this, no joy. When I stop/disable xl2tpd I'm unable to connect at all. Only with daemon running allow me to successfully connect
When you use
/usr/lib/NetworkManager/nm-l2tp-service --debug
, the/run/nm-l2tp-fa4fffae-3ed6-422f-ac56-c8752b5545ed/ipsec.conf
file will remain behind so you can look at the contents. I believe that generatedipsec.conf
file will be identical for both NetworkManager-l2tp 1.2.16 and 1.8.0, if they are not, there is a bug. If those files are identical as they should be, I can't explain why you are getting a 1hr disconnect with 1.8.0, but not 1.2.16.
Just to be clear I was getting same 1h disconnect with 1.2.16 so as 1.8.0
That generated
ipsec.conf
file can be used for a Libreswan command-line start, e.g. :sudo ipsec restart sleep 2 sudo ipsec auto --config /run/nm-l2tp-fa4fffae-3ed6-422f-ac56-c8752b5545ed/ipsec.conf --verbose --add fa4fffae-3ed6-422f-ac56-c8752b5545ed sudo ipsec auto --up fa4fffae-3ed6-422f-ac56-c8752b5545ed sudo ipsec status
Actually, I just noticed the following:
NetworkManager[939]: <info> [1580827407.7901] connectivity: (wlp4s0) timed out
wlp4s0
is the WiFi network and it has timed out.
tried disable powersave for wifi afdapter, no effect. I get disconnect exactly within 1h
[connection]
wifi.powersave = 2
Feb 5 09:53:44 LP00001 pppd[4368]: Terminating on signal 15
Feb 5 09:53:44 LP00001 pppd[4368]: nm-l2tp[3681] <info> [helper-4368] phasechange: status 10 / phase 'terminate'
Feb 5 09:53:44 LP00001 pppd[4368]: nm-l2tp[3681] <info> [helper-4368] phasechange: status 8 / phase 'network'
Feb 5 09:53:44 LP00001 pppd[4368]: Connect time 60.6 minutes.
Feb 5 09:53:44 LP00001 pppd[4368]: Sent 123666 bytes, received 169032 bytes.
Feb 5 09:53:44 LP00001 pppd[4368]: Script /etc/ppp/ip-down started (pid 5251)
Feb 5 09:53:44 LP00001 pppd[4368]: nm-l2tp[3681] <info> [helper-4368] phasechange: status 5 / phase 'establish'
Feb 5 09:53:44 LP00001 pppd[4368]: Overriding mtu 1500 to 1400
Feb 5 09:53:44 LP00001 pppd[4368]: PPPoL2TP options: debugmask 0
Feb 5 09:53:44 LP00001 pppd[4368]: Overriding mru 1500 to mtu value 1400
Feb 5 09:53:44 LP00001 pppd[4368]: sent [LCP TermReq id=0x3 "User request"]
Feb 5 09:53:44 LP00001 pppd[4368]: Script /etc/ppp/ip-down finished (pid 5251), status = 0x0
Feb 5 09:53:47 LP00001 pppd[4368]: sent [LCP TermReq id=0x4 "User request"]
Feb 5 09:53:50 LP00001 pppd[4368]: nm-l2tp[3681] <info> [helper-4368] phasechange: status 11 / phase 'disconnect'
Feb 5 09:53:50 LP00001 pppd[4368]: Connection terminated.
above is a syslog dump for the disconnect event I've been wondering if below has anything to do with this, meaning status 10 and 8 or perhaps it's just a result of disconnect ?
Feb 5 09:53:44 LP00001 pppd[4368]: nm-l2tp[3681] <info> [helper-4368] phasechange: status 10 / phase 'terminate'
Feb 5 09:53:44 LP00001 pppd[4368]: nm-l2tp[3681] <info> [helper-4368] phasechange: status 8 / phase 'network'
attaching ipsec status dump to validate all params are ok since nm-manager-l2tp upgrade I'm able to control and see ike_life set to 8h correctly, just can't get effect of it ipsec.log
000 "fa4fffae-3ed6-422f-ac56-c8752b5545ed": ike_life: 28800s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0;
The following is because of increased ppp debugging:
pppd[4368]: phasechange: status 10 / phase 'terminate'
pppd[4368]: phasechange: status 8 / phase 'network'
The various pppd phases are listed here:
I'm not sure if it is significant, it might be, but it has given me a thought. In the PPP Settings dialog box, you could try clicking "Send PPP echo packets". The corresponding tooltip says "Send LCP echo-requests to find out if the peer is alive", looking at the code, it sets the following ppp options:
see the ppp(8) manpage for info on what those options do:
The echo packets might keep the VPN connection alive, but I have no idea if it will solve your issue. I haven't really touched the PPP code in NetworkManager-l2tp much at all since I started maintaining it 3 years ago.
Sorry I'm not familiar enough with libreswan to say if all params are ok. Perhaps libreswan issues might be able to help.
Closing this issue due to lack of activity.
As a workaround, you could use a script that makes use of the NetworkManager command-line interface (i.e. the nmcli
command) to reconnect the VPN connection when it goes down. For your reference, common nmcli
commands are:
nmcli con
nmcli con up id VPN-Connection-Name
nmcli con down id VPN-Connection-Name
The following script can do auto-reconnecting:
Should only need to change VPN_UID
, LOG
and CHECK_HOST
in that script.
I'm having an issue with l2tp vpn tunnel triggered by NetworkManager. With libreswan it only lasts 1h (3600s default) and then gracefully disconnects straight after. strongwan gives 2h
connection settings could be definedg in configs (ipsec.conf/swanctl.conf respectively) however when vpn connection is triggered by NetworkManager it creates dynamic connection with default settings. I don't see a way to overwrite "ikelifetime" -> https://libreswan.org/man/ipsec.conf.5.html I tired overwrite setting using ipsec pluto but no success in this
OS : Ubuntu 18.04.3 LTS kernel : 4.15.0-66-generic network-manager-l2tp-1.2.8-2build1