Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot connect to L2TP VPN via IPsec tunnel on on Ubuntu 16.10 without stopping the system xl2tpd service first #38

Closed
mgedmin opened this issue Mar 21, 2017 · 21 comments

Comments

Projects
None yet
4 participants
@mgedmin
Copy link

commented Mar 21, 2017

I installed the plugin from the PPA

add-apt-repository ppa:nm-l2tp/network-manager-l2tp                    
apt update && apt install network-manager-l2tp-gnome

configured it with the gateway/username/password for my VPN, enabled the IPsec tunnel to L2TP host and entered the pre-shared key. Attempts to connect fail with the following error visible in journalctl -b:

Kov 21 16:40:55 platonas NetworkManager[2326]: xl2tpd[17104]: Connecting to host 195.67.6.50, port 1701
Kov 21 16:41:00 platonas NetworkManager[2326]: xl2tpd[17104]: Maximum retries exceeded for tunnel 64640.  Closing.

I've tried to build my own xl2tpd as suggested on the wiki, except I couldn't remove the system xl2tpd package so I had to use dpkg-divert to replace its binaries with my own built versions:

apt install libpcap0.8-dev
apt remove xl2tpd
  # wants to uninstall network-manager-l2tp network-manager-l2tp-gnome, so canceled
wget https://github.com/xelerance/xl2tpd/archive/v1.3.6/xl2tpd-1.3.6.tar.gz
tar xvzf xl2tpd-1.3.6.tar.gz
cd xl2tpd-1.3.6 && make && make -n install
   # wants to install three files into /usr/local, if I ignore all the directories and documentation

service xl2tpd stop
dpkg-divert --divert /usr/sbin/xl2tpd.ubuntu --rename --add /usr/sbin/xl2tpd
dpkg-divert --divert /usr/sbin/xl2tpd-control.ubuntu --rename --add /usr/sbin/xl2tpd-control
dpkg-divert --divert /usr/bin/pfc.ubuntu --rename --add /usr/bin/pfc
install -m 0755 xl2tpd /usr/sbin/xl2tpd
install -m 0755 xl2tpd-control /usr/sbin/xl2tpd-control
install -m 0755 pfc /usr/bin/pfc
service xl2tpd start

but I still get the same "Maximum retries exceeded" error.

Other random flailing like disabling my ufw firewall or rebooting did not change anything about the failure.

I've tried Wireshark over my wifi interface, and I noticed a strange thing: there are ISAKMP messages for establishing the IPsec tunnel, but then the L2TP SCCRQ messages appear to be going to the VPN gateway over UDP directly, not over the IPsec tunnel. I'm not a networking expert, but I don't think I would be seeing those if they were tunneled.

Looking more closely over journalctl I see nothing suspicious, except maybe

Kov 21 16:40:51 platonas nm-l2tp-service[16985]: Check port 1701
Kov 21 16:40:51 platonas nm-l2tp-service[16985]: Can't bind to port 1701
Kov 21 16:40:51 platonas NetworkManager[2326]: nm-l2tp[16985] <warn>  Port 1701 is busy, use ephemeral.

(netstat -tunlvp|grep 1701 tells me it's my local xl2tpd listening on port 1701.)

Aside: a coworker did successfully connect to the VPN server using network-manager-l2tp with Ubuntu 16.04, after following the instructions at http://blog.z-proj.com/enabling-l2tp-over-ipsec-on-ubuntu-16-04/, and he tells me that I've the right settings specified in the Network Manager GUI.

Preemptive update: I've strongswan 5.3.5-1ubuntu4.1 from yakkety-updates.

@dkosovic dkosovic self-assigned this Mar 22, 2017

@dkosovic

This comment has been minimized.

Copy link
Member

commented Mar 22, 2017

With the xl2tpd can't bind to port 1701 issue, I normally don't have xl2tpd running so don't see that message, Also my VPN server's firewall prevents L2TP connections without IPsec, so I'm not able to replicate all possible scenarios where it might try to connecting without encapsulating in IPsec.

if you do the following, you should see more pppd debugging in journalctl output which might give a hint:

sudo killall -TERM nm-l2tp-service
sudo /usr/lib/NetworkManager/nm-l2tp-service --debug

With tcpdump on the wifi interface, I only see decapsulated l2tp traffic for inbound traffic. and encapsulate l2tp oubound.

That would be interesting if xl2tpd is trying to do a L2TP connection with the IPsec connection being down. I didn't trust the exit status of the strongswan ipsec up command which brings up an IPsec connection, so explicitly call the ipsec status command to determine if the IPsec connection is up by search for "ESTABLISHED" in the output of that command, see code after the comments on this line:

You should see the following in the logs if it determines the IPsec connection is established:
strongSwan ready for action

You might like to check if the IPsec connection is indeed up using just the command-line:

First add a pre-shared key to /etc/ipsec.secrets with a line something like:

: PSK this-is-my-PSK

with this-is-my-PSK replaced by the actual PSK.

You should hopefully have some ipsec.conf files under /var/run/nm-ipsec-l2tp.* that were generated by network-manager-l2tp. You can start the ipsec connection with something like:

sudo ipsec restart --conf /var/run/nm-ipsec-l2tp.12345/ipsec.conf --debug
sudo ipsec up nm-ipsec-l2tp-12345
sudo ipsec status
@mgedmin

This comment has been minimized.

Copy link
Author

commented Mar 22, 2017

nm-l2tp-service --debug doesn't say much more:

... (snip 112 lines) ...
nm-l2tp[22501] <info>  strongSwan ready for action.
xl2tpd[22588]: setsockopt recvref[30]: Protocol not available
xl2tpd[22588]: Using l2tp kernel support.
xl2tpd[22588]: xl2tpd version xl2tpd-1.3.6 started on platonas PID:22588
xl2tpd[22588]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
xl2tpd[22588]: Forked by Scott Balmos and David Stipp, (C) 2001
xl2tpd[22588]: Inherited by Jeff McAdams, (C) 2002
xl2tpd[22588]: Forked again by Xelerance (www.xelerance.com) (C) 2006
xl2tpd[22588]: Listening on IP address 0.0.0.0, port 57122
xl2tpd[22588]: get_call: allocating new tunnel for host 195.67.6.50, port 1701.
xl2tpd[22588]: Connecting to host 195.67.6.50, port 1701
xl2tpd[22588]: control_finish: message type is (null)(0).  Tunnel is 0, call is 0.
xl2tpd[22588]: control_finish: sending SCCRQ
xl2tpd[22588]: Maximum retries exceeded for tunnel 54546.  Closing.
xl2tpd[22588]: Connection 0 closed to 195.67.6.50, port 1701 (Timeout)
xl2tpd[22588]: Unable to deliver closing message for tunnel 54546. Destroying anyway.
nm-l2tp[22501] <warn>  Looks like pppd didn't initialize our dbus module
nm-l2tp[22501] <info>  Terminated xl2tpd daemon with PID 22588.
xl2tpd[22588]: death_handler: Fatal signal 15 received
Stopping strongSwan IPsec...
** Message: ipsec shut down
nm-l2tp[22501] <warn>  xl2tpd exited with error code 1
Stopping strongSwan IPsec failed: starter is not running
** Message: ipsec shut down

Manual IPsec setup seems fine:

# ipsec status
Security Associations (1 up, 0 connecting):
nm-ipsec-l2tp-5153[1]: ESTABLISHED 21 seconds ago, 192.168.2.105[192.168.2.105]...195.67.6.50[195.67.6.50]
nm-ipsec-l2tp-5153{1}:  INSTALLED, TRANSPORT, reqid 1, ESP in UDP SPIs: cf465b42_i 0b8586ba_o
nm-ipsec-l2tp-5153{1}:   192.168.2.105/32[udp/l2f] === 195.67.6.50/32[udp/l2f]

and, in fact, if I run watch ipsec status while I'm asking NetworkManager to enable the VPN, I see the same sort of output:

nm-ipsec-l2tp-24113[1]: ESTABLISHED 11 seconds ago, 192.168.2.105[192.168.2.105]...195.67.6.50[195.67.6.50]
nm-ipsec-l2tp-24113{1}:  INSTALLED, TRANSPORT, reqid 1, ESP in UDP SPIs: c3f2553a_i 079b4dbd_o
nm-ipsec-l2tp-24113{1}:   192.168.2.105/32[udp/l2f] === 195.67.6.50/32[udp/l2f]

and yet Wireshark still sees the outgoing L2TP messages in plaintext.

@mgedmin

This comment has been minimized.

Copy link
Author

commented Mar 22, 2017

I did a small experiment on a lark:

service xl2tpd stop

and then tried connecting again. And it worked!

journalctl shows

...
Kov 22 16:18:46 platonas NetworkManager[2280]: nm-l2tp[25789] <info>  strongSwan ready for action.
Kov 22 16:18:46 platonas charon[25825]: 07[CFG] rereading secrets
Kov 22 16:18:46 platonas charon[25825]: 07[CFG] loading secrets from '/etc/ipsec.secrets'
Kov 22 16:18:46 platonas charon[25825]: 07[CFG]   loaded IKE secret for %any

(which makes me wonder briefly if it would work if I remove the PSK from /etc/ipsec.sectets)

Kov 22 16:18:46 platonas nm-l2tp-service[25789]: xl2tpd started with pid 25871
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: setsockopt recvref[30]: Protocol not available
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Using l2tp kernel support.
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: xl2tpd version xl2tpd-1.3.6 started on platonas PID:25871
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Written by Mark Spencer, Copyright (C) 1998, Adtran, Inc.
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Forked by Scott Balmos and David Stipp, (C) 2001
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Inherited by Jeff McAdams, (C) 2002
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Forked again by Xelerance (www.xelerance.com) (C) 2006
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Listening on IP address 0.0.0.0, port 1701

(so now local port 1701 is free)

Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Connecting to host 195.67.6.50, port 1701
Kov 22 16:18:46 platonas NetworkManager[2280]: <info>  [1490192326.0821] vpn-connection[0x561df3b10210,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN plugin: state changed: starting (3)
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Connection established to 195.67.6.50, 1701.  Local: 56881, Remote: 27551 (ref=0/0).

(and we have success!)

Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Calling on tunnel 56881
Kov 22 16:18:46 platonas NetworkManager[2280]: xl2tpd[25871]: Call established with 195.67.6.50, Local: 61189, Remote: 58239, Serial: 1 (ref=0/0)
...

BTW Wireshark shows no plaintext L2TP packets going to 195.67.6.50 this time -- after the ISAKMP exchange all I see are ESP packets going in both directions.

If I compare the /var/run/nm-xl2tpd.conf.* files from non-working attempts to the latest (working) attempt, the only difference I see is port = 0 in the bad configs and port = 1701 in the good one. Don't know if that's relevant.

@mgedmin

This comment has been minimized.

Copy link
Author

commented Mar 22, 2017

FWIW I undid all of my debugging hacks (PSK in /etc/ipsec.secrets, dpkg diversions of /usr/sbin/xl2tpd etc.):

rm /usr/bin/pfc /usr/sbin/xl2tpd /usr/sbin/xl2tpd-control
dpkg-divert --rename --remove /usr/bin/pfc
dpkg-divert --rename --remove /usr/sbin/xl2tpd
dpkg-divert --rename --remove /usr/sbin/xl2tpd-control

and the VPN continues to work fine (tried turning it off and back on to be sure).

I also disabled the system-wide xl2tpd service permanently, so the VPN will continue working after a reboot:

update-rc.d xl2tpd disable

The Ubuntu-provided xl2tpd seems to be segfaulting every time the VPN goes down. I didn't see that with the xl2tpd that I built myself. The segfaults do not appear to be affecting the VPN connection itself in any way, and I probably wouldn't even notice them if I didn't have apport notifications enabled. One funny side effect of those segfaults is that the crash happens before the ppp interface is torn down, so the new connection gets to use a higher-numbered ppp interface. I'm on ppp4 right now.

@mgedmin

This comment has been minimized.

Copy link
Author

commented Mar 22, 2017

The xl2tpd segfaults are filed as https://bugs.launchpad.net/ubuntu/+source/xl2tpd/+bug/1509183. There's an upstream fix at xelerance/xl2tpd@a193e02, which is already present in the version of xl2tpd in zesty.

@mgedmin mgedmin changed the title Cannot connect to L2TP VPN via IPsec tunnel on on Ubuntu 16.10 Cannot connect to L2TP VPN via IPsec tunnel on on Ubuntu 16.10 without stopping the system xl2tpd service first Mar 22, 2017

@dkosovic

This comment has been minimized.

Copy link
Member

commented Mar 22, 2017

I started to think a correct solution for network-manager-l2tp would be to use xl2tpd-control to send configuration options and commands to a running xl2tpd. But that adds lots of complications if xl2tpd isn't already running as there is no portable way to start xl2tpd across various linux distros, other than forking xl2tpd as a child process. I'm still thinking about it.

I'll definitely need to update the documentation, and incorporate some of your above comments.

@fnordahl

This comment has been minimized.

Copy link

commented Mar 29, 2017

Just wanted to make a note about that I have the same issue here on Ubuntu 16.04 LTS.

I have to manually stop xl2tpd service before I can successfully connect using the NetworkManger plugin.

@dkosovic

This comment has been minimized.

Copy link
Member

commented Mar 30, 2017

With commit ed00db6 it now at least fails for L2TP/IPsec (but not L2TP) if UDP port 1701 is already in use, thus preventing the situation where L2TP packets are not being encapsulated in IPsec.

I'm still looking into a portable solution for using a running xl2tpd that is already using port 1701. There are issues with xl2tpd-control from earlier versions of xl2tpd. I might even consider talking directly to the /var/run/l2tp-control FIFO (which might be a configure time argument for linux distros not using /var/run/l2tp-control).

@dkosovic

This comment has been minimized.

Copy link
Member

commented May 2, 2017

The updated Ubuntu PPA packages now have a patch that does the following for the generated ipsec config file :

    if (is_port_free (1701)) {
        write_config_option (ipsec_fd, "  leftprotoport=udp/l2tp\n");
    }
    write_config_option (ipsec_fd, "  rightprotoport=udp/l2tp\n");

Note: leftprotoport=udp/l2tp is equivalent to leftprotoport=udp/1701

I think I'll probably do similar in the source code repository and postpone the approach using a named pipe or using the xl2tpd-control command.

I should have released a fix for the PPA packages earlier, rather than waiting for a new source code release which I still have issues to fix.

@dkosovic

This comment has been minimized.

Copy link
Member

commented May 21, 2017

The recently released version 1.2.6 has commit 13ea66b which doesn't write leftprotoport=udp/l2tp to the generated ipsec config file if L2TP port 1701 is in use.

So no longer need to stop the xl2tpd service.

@dkosovic dkosovic closed this May 21, 2017

@mgedmin

This comment has been minimized.

Copy link
Author

commented May 22, 2017

That is good news! Unfortunately I cannot confirm the fix -- I'm getting VPN connection failures with 1.2.6-0ubuntu1~zesty1 irrespective of whether the system xl2tpd service is stopped or not.

Journalctl shows

Geg 22 10:42:10 platonas NetworkManager[2513]: <info>  [1495438930.9305] audit: op="connection-activate" uuid="97ba413f-669b-4478-af49-a51312807a81" name="ID06 VPN" pid=4951 uid=1000 result="success"
Geg 22 10:42:10 platonas NetworkManager[2513]: <info>  [1495438930.9366] vpn-connection[0x55e41bd2a720,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: Started the VPN service, PID 10703
Geg 22 10:42:10 platonas NetworkManager[2513]: <info>  [1495438930.9465] vpn-connection[0x55e41bd2a720,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: Saw the service appear; activating connection
Geg 22 10:42:11 platonas NetworkManager[2513]: <info>  [1495438931.0385] vpn-connection[0x55e41bd2a720,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN connection: (ConnectInteractive) reply received
Geg 22 10:42:11 platonas nm-l2tp-service[10703]: Check port 1701
Geg 22 10:42:11 platonas NetworkManager[2513]: Stopping strongSwan IPsec failed: starter is not running
Geg 22 10:42:13 platonas NetworkManager[2513]: Starting strongSwan 5.5.1 IPsec [starter]...
Geg 22 10:42:13 platonas NetworkManager[2513]: Loading config setup
Geg 22 10:42:13 platonas NetworkManager[2513]: Loading conn '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 10:42:13 platonas ipsec_starter[10722]: Starting strongSwan 5.5.1 IPsec [starter]...
Geg 22 10:42:13 platonas ipsec_starter[10722]: Loading config setup
Geg 22 10:42:13 platonas ipsec_starter[10722]: Loading conn '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 10:42:13 platonas NetworkManager[2513]: found netkey IPsec stack
Geg 22 10:42:13 platonas ipsec_starter[10722]: found netkey IPsec stack
Geg 22 10:42:13 platonas ipsec_starter[10744]: Attempting to start charon...
Geg 22 10:42:13 platonas charon[10745]: 00[DMN] Starting IKE charon daemon (strongSwan 5.5.1, Linux 4.10.0-21-generic, x86_64)
Geg 22 10:42:13 platonas charon[10745]: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Geg 22 10:42:13 platonas charon[10745]: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Geg 22 10:42:13 platonas charon[10745]: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Geg 22 10:42:13 platonas charon[10745]: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Geg 22 10:42:13 platonas charon[10745]: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Geg 22 10:42:13 platonas charon[10745]: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Geg 22 10:42:13 platonas charon[10745]: 00[CFG] loading secrets from '/etc/ipsec.d/nm-l2tp-ipsec-97ba413f-669b-4478-af49-a51312807a81.secrets'
Geg 22 10:42:13 platonas charon[10745]: 00[CFG]   loaded IKE secret for %any
Geg 22 10:42:13 platonas charon[10745]: 00[LIB] loaded plugins: charon test-vectors aesni aes rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac ccm gcm attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic
Geg 22 10:42:13 platonas charon[10745]: 00[LIB] dropped capabilities, running as uid 0, gid 0
Geg 22 10:42:13 platonas charon[10745]: 00[JOB] spawning 16 worker threads
Geg 22 10:42:13 platonas ipsec_starter[10744]: charon (10745) started after 20 ms
Geg 22 10:42:13 platonas charon[10745]: 03[CFG] received stroke: add connection '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 10:42:13 platonas charon[10745]: 03[CFG] added configuration '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 10:42:14 platonas charon[10745]: 06[CFG] rereading secrets
Geg 22 10:42:14 platonas charon[10745]: 06[CFG] loading secrets from '/etc/ipsec.secrets'
Geg 22 10:42:14 platonas charon[10745]: 06[CFG] loading secrets from '/etc/ipsec.d/nm-l2tp-ipsec-97ba413f-669b-4478-af49-a51312807a81.secrets'
Geg 22 10:42:14 platonas charon[10745]: 06[CFG]   loaded IKE secret for %any
Geg 22 10:42:14 platonas charon[10745]: 09[CFG] received stroke: initiate '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 10:42:14 platonas charon[10745]: 10[IKE] initiating Main Mode IKE_SA 97ba413f-669b-4478-af49-a51312807a81[1] to 195.67.6.50
Geg 22 10:42:14 platonas charon[10745]: 10[IKE] initiating Main Mode IKE_SA 97ba413f-669b-4478-af49-a51312807a81[1] to 195.67.6.50
Geg 22 10:42:14 platonas charon[10745]: 10[ENC] generating ID_PROT request 0 [ SA V V V V V ]
Geg 22 10:42:14 platonas charon[10745]: 10[NET] sending packet: from 192.168.2.105[500] to 195.67.6.50[500] (240 bytes)
Geg 22 10:42:18 platonas charon[10745]: 11[IKE] sending retransmit 1 of request message ID 0, seq 1
Geg 22 10:42:18 platonas charon[10745]: 11[NET] sending packet: from 192.168.2.105[500] to 195.67.6.50[500] (240 bytes)
Geg 22 10:42:24 platonas nm-l2tp-service[10703]: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
Geg 22 10:42:24 platonas NetworkManager[2513]: <info>  [1495438944.1561] vpn-connection[0x55e41bd2a720,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN plugin: state changed: stopped (6)
Geg 22 10:42:24 platonas NetworkManager[2513]: <info>  [1495438944.1602] vpn-connection[0x55e41bd2a720,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN plugin: state change reason: unknown (0)
Geg 22 10:42:24 platonas NetworkManager[2513]: <info>  [1495438944.1616] vpn-connection[0x55e41bd2a720,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN service disappeared
Geg 22 10:42:24 platonas NetworkManager[2513]: <warn>  [1495438944.1632] vpn-connection[0x55e41bd2a720,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN connection: failed to connect: 'Message recipient disconnected from message bus without replying'

and then the charon process keeps running and keeps retransmitting, unsuccessfully

Geg 22 10:42:25 platonas charon[10745]: 12[IKE] sending retransmit 2 of request message ID 0, seq 1
Geg 22 10:42:25 platonas charon[10745]: 12[NET] sending packet: from 192.168.2.105[500] to 195.67.6.50[500] (240 bytes)

1.2.4-0ubuntu2~zesty1 worked fine (with the system xl2tpd service stopped).

@dkosovic dkosovic reopened this May 22, 2017

@dkosovic

This comment has been minimized.

Copy link
Member

commented May 22, 2017

Version 1.2.6 no longer overrides the default IPsec ciphers and I suspect your VPN server is using a legacy cipher newer strongSwan versions consider to be broken.

See the user specified IPsec cipher suites section in the README.md file on how to supplement the strongSwan default ciphers with your own :

I would recommend installing the ike-scan package to check what ciphers your VPN server is advertising it supports, e.g. :

$ sudo systemctl stop strongswan  
$ sudo ike-scan 123.54.76.9  
Starting ike-scan 1.9 with 1 hosts (http://www.nta-monitor.com/tools/ike-scan/)
123.54.76.9   Main Mode Handshake returned HDR=(CKY-R=5735eb949670e5dd) SA=(Enc=3DES Hash=SHA1 Auth=PSK Group=2:modp1024 LifeType=Seconds LifeDuration(4)=0x00007080)
Ending ike-scan 1.9: 1 hosts scanned in 0.263 seconds (3.80 hosts/sec).  1 returned handshake; 0 returned notify

So with this example where a broken 3DES cipher is advertised, in the advanced section of the IPsec dialog box for version 1.2.6, add the following:

  • Phase1 Algorithms : 3des-sha1-modp1024
  • Phase2 Algorithms : 3des-sha1
@dkosovic

This comment has been minimized.

Copy link
Member

commented May 22, 2017

Actually, I don't think ike-scan shows all the ciphers that the VPN server supports for the negotiation, just the initial one in a list that it'll try.

But the example in the README.md file will show how to revert back to previous behaviour by setting the Phase 1 and 2 algorithms boxes.

I'm using a fairly new VPN server, so I don't need to fill in the Phase 1 and 2 algorithms boxes.

In commit b10d9c7 the following lines were removed which supplemented the default ciphers :

    write_config_option (ipsec_fd, "  esp=aes128-sha1,3des-sha1\n");
    write_config_option (ipsec_fd, "  ike=aes128-sha1-modp2048,3des-sha1-modp1536,3des-sha1-modp1024\n");
@mgedmin

This comment has been minimized.

Copy link
Author

commented May 22, 2017

I seem to've hit a UI bug while attempting to set IPsec algorithms:

  • Open VPN settings
  • Select Identity on the left
  • Hit IPsec Settings... button
  • Open Advanced
  • Paste "aes128-sha1,3des-sha1" into Phase1 Algorithms
  • Paste "aes128-sha1-modp2048,3des-sha1-modp1536,3des-sha1-modp1024" into Phase2 Algorithms
  • Hit "OK"

Now the Apply button in the main settings dialog is greyed out, and if I hit Esc or Cancel, then go back, the algorithms input boxes are blank (and the VPN doesn't work).

Update: actually no matter what I change in the main configuration dialog, the Apply button is always greyed out!

2nd update: that's because I'm trying to set up a point-to-point route, because I need the VPN to go to only one host. The way I do it is go to IPv4, turn off automatic routes, add a route to X.X.X.X netmask 255.255.255.255 gateway 0.0.0.0 (can't be blank! but 0.0.0.0 works). Now whenever I go back to the settings dialog, I must remember to go to the IPv4 section and re-enter gateway 0.0.0.0, because it gets cleared automatically and is outlined in red and disables the Apply button.

Anyway, I realize now that I've mixed up which of ESP/IKE was considered Phase 1 because I basically know nothing about IPsec, so I entered the wrong values in the wrong boxes and that's why it doesn't work. ;)

@mgedmin

This comment has been minimized.

Copy link
Author

commented May 22, 2017

I'm now able to connect to the VPN with version 1.2.6, but only when the system xl2tpd service is stopped.

When xl2tpd is running, journalctl shows

Geg 22 15:38:38 platonas NetworkManager[2513]: <info>  [1495456718.9725] audit: op="connection-activate" uuid="97ba413f-669b-4478-af49-a51312807a81" name="ID06 VPN" pid=30501 uid=1000 result="success"
Geg 22 15:38:38 platonas NetworkManager[2513]: <info>  [1495456718.9803] vpn-connection[0x55e41bd2a180,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: Started the VPN service, PID 962
Geg 22 15:38:38 platonas NetworkManager[2513]: <info>  [1495456718.9920] vpn-connection[0x55e41bd2a180,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: Saw the service appear; activating connection
Geg 22 15:38:39 platonas NetworkManager[2513]: <info>  [1495456719.0985] vpn-connection[0x55e41bd2a180,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN connection: (ConnectInteractive) reply received
Geg 22 15:38:39 platonas nm-l2tp-service[962]: Check port 1701
Geg 22 15:38:39 platonas nm-l2tp-service[962]: Can't bind to port 1701
Geg 22 15:38:39 platonas NetworkManager[2513]: Stopping strongSwan IPsec failed: starter is not running
Geg 22 15:38:41 platonas NetworkManager[2513]: Starting strongSwan 5.5.1 IPsec [starter]...
Geg 22 15:38:41 platonas NetworkManager[2513]: Loading config setup
Geg 22 15:38:41 platonas NetworkManager[2513]: Loading conn '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 15:38:41 platonas ipsec_starter[982]: Starting strongSwan 5.5.1 IPsec [starter]...
Geg 22 15:38:41 platonas ipsec_starter[982]: Loading config setup
Geg 22 15:38:41 platonas ipsec_starter[982]: Loading conn '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 15:38:41 platonas NetworkManager[2513]: found netkey IPsec stack
Geg 22 15:38:41 platonas ipsec_starter[982]: found netkey IPsec stack
Geg 22 15:38:41 platonas ipsec_starter[1004]: Attempting to start charon...
Geg 22 15:38:41 platonas charon[1005]: 00[DMN] Starting IKE charon daemon (strongSwan 5.5.1, Linux 4.10.0-21-generic, x86_64)
Geg 22 15:38:41 platonas charon[1005]: 00[CFG] loading ca certificates from '/etc/ipsec.d/cacerts'
Geg 22 15:38:41 platonas charon[1005]: 00[CFG] loading aa certificates from '/etc/ipsec.d/aacerts'
Geg 22 15:38:41 platonas charon[1005]: 00[CFG] loading ocsp signer certificates from '/etc/ipsec.d/ocspcerts'
Geg 22 15:38:41 platonas charon[1005]: 00[CFG] loading attribute certificates from '/etc/ipsec.d/acerts'
Geg 22 15:38:41 platonas charon[1005]: 00[CFG] loading crls from '/etc/ipsec.d/crls'
Geg 22 15:38:41 platonas charon[1005]: 00[CFG] loading secrets from '/etc/ipsec.secrets'
Geg 22 15:38:41 platonas charon[1005]: 00[CFG] loading secrets from '/etc/ipsec.d/nm-l2tp-ipsec-97ba413f-669b-4478-af49-a51312807a81.secrets'
Geg 22 15:38:41 platonas charon[1005]: 00[CFG]   loaded IKE secret for %any
Geg 22 15:38:41 platonas charon[1005]: 00[LIB] loaded plugins: charon test-vectors aesni aes rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac ccm gcm attr kernel-netlink resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic
Geg 22 15:38:41 platonas charon[1005]: 00[LIB] dropped capabilities, running as uid 0, gid 0
Geg 22 15:38:41 platonas charon[1005]: 00[JOB] spawning 16 worker threads
Geg 22 15:38:41 platonas ipsec_starter[1004]: charon (1005) started after 20 ms
Geg 22 15:38:41 platonas charon[1005]: 06[CFG] received stroke: add connection '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 15:38:41 platonas charon[1005]: 06[CFG] added configuration '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 15:38:42 platonas charon[1005]: 07[CFG] rereading secrets
Geg 22 15:38:42 platonas charon[1005]: 07[CFG] loading secrets from '/etc/ipsec.secrets'
Geg 22 15:38:42 platonas charon[1005]: 07[CFG] loading secrets from '/etc/ipsec.d/nm-l2tp-ipsec-97ba413f-669b-4478-af49-a51312807a81.secrets'
Geg 22 15:38:42 platonas charon[1005]: 07[CFG]   loaded IKE secret for %any
Geg 22 15:38:42 platonas charon[1005]: 08[CFG] received stroke: initiate '97ba413f-669b-4478-af49-a51312807a81'
Geg 22 15:38:42 platonas charon[1005]: 10[IKE] initiating Main Mode IKE_SA 97ba413f-669b-4478-af49-a51312807a81[1] to 195.67.6.50
Geg 22 15:38:42 platonas charon[1005]: 10[IKE] initiating Main Mode IKE_SA 97ba413f-669b-4478-af49-a51312807a81[1] to 195.67.6.50
Geg 22 15:38:42 platonas charon[1005]: 10[ENC] generating ID_PROT request 0 [ SA V V V V V ]
Geg 22 15:38:42 platonas charon[1005]: 10[NET] sending packet: from 192.168.1.165[500] to 195.67.6.50[500] (304 bytes)
Geg 22 15:38:42 platonas charon[1005]: 11[NET] received packet: from 195.67.6.50[500] to 192.168.1.165[500] (156 bytes)
Geg 22 15:38:42 platonas charon[1005]: 11[ENC] parsed ID_PROT response 0 [ SA V V V V ]
Geg 22 15:38:42 platonas charon[1005]: 11[IKE] received XAuth vendor ID
Geg 22 15:38:42 platonas charon[1005]: 11[IKE] received NAT-T (RFC 3947) vendor ID
Geg 22 15:38:42 platonas charon[1005]: 11[IKE] received DPD vendor ID
Geg 22 15:38:42 platonas charon[1005]: 11[IKE] received FRAGMENTATION vendor ID
Geg 22 15:38:42 platonas charon[1005]: 11[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
Geg 22 15:38:42 platonas charon[1005]: 11[NET] sending packet: from 192.168.1.165[500] to 195.67.6.50[500] (244 bytes)
Geg 22 15:38:42 platonas charon[1005]: 12[NET] received packet: from 195.67.6.50[500] to 192.168.1.165[500] (228 bytes)
Geg 22 15:38:42 platonas charon[1005]: 12[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
Geg 22 15:38:42 platonas charon[1005]: 12[IKE] local host is behind NAT, sending keep alives
Geg 22 15:38:42 platonas charon[1005]: 12[ENC] generating ID_PROT request 0 [ ID HASH ]
Geg 22 15:38:42 platonas charon[1005]: 12[NET] sending packet: from 192.168.1.165[4500] to 195.67.6.50[4500] (68 bytes)
Geg 22 15:38:42 platonas charon[1005]: 13[NET] received packet: from 195.67.6.50[4500] to 192.168.1.165[4500] (92 bytes)
Geg 22 15:38:42 platonas charon[1005]: 13[ENC] parsed ID_PROT response 0 [ ID HASH V ]
Geg 22 15:38:42 platonas charon[1005]: 13[IKE] received DPD vendor ID
Geg 22 15:38:42 platonas charon[1005]: 13[IKE] IKE_SA 97ba413f-669b-4478-af49-a51312807a81[1] established between 192.168.1.165[192.168.1.165]...195.67.6.50[195.67.6.50]
Geg 22 15:38:42 platonas charon[1005]: 13[IKE] IKE_SA 97ba413f-669b-4478-af49-a51312807a81[1] established between 192.168.1.165[192.168.1.165]...195.67.6.50[195.67.6.50]
Geg 22 15:38:42 platonas charon[1005]: 13[IKE] scheduling reauthentication in 9847s
Geg 22 15:38:42 platonas charon[1005]: 13[IKE] maximum IKE_SA lifetime 10387s
Geg 22 15:38:42 platonas charon[1005]: 13[ENC] generating QUICK_MODE request 3867164705 [ HASH SA No ID ID NAT-OA NAT-OA ]
Geg 22 15:38:42 platonas charon[1005]: 13[NET] sending packet: from 192.168.1.165[4500] to 195.67.6.50[4500] (244 bytes)
Geg 22 15:38:46 platonas charon[1005]: 06[IKE] sending retransmit 1 of request message ID 3867164705, seq 4
Geg 22 15:38:46 platonas charon[1005]: 06[NET] sending packet: from 192.168.1.165[4500] to 195.67.6.50[4500] (244 bytes)
Geg 22 15:38:52 platonas nm-l2tp-service[962]: g_dbus_method_invocation_take_error: assertion 'error != NULL' failed
Geg 22 15:38:52 platonas NetworkManager[2513]: <info>  [1495456732.1765] vpn-connection[0x55e41bd2a180,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN"lines 31624-31658/32145 99%
Geg 22 15:38:52 platonas NetworkManager[2513]: <info>  [1495456732.1765] vpn-connection[0x55e41bd2a180,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN plugin: state changed: stopped (6)
Geg 22 15:38:52 platonas NetworkManager[2513]: <info>  [1495456732.1801] vpn-connection[0x55e41bd2a180,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN plugin: state change reason: unknown (0)
Geg 22 15:38:52 platonas NetworkManager[2513]: <info>  [1495456732.1840] vpn-connection[0x55e41bd2a180,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN service disappeared
Geg 22 15:38:52 platonas NetworkManager[2513]: <warn>  [1495456732.1851] vpn-connection[0x55e41bd2a180,97ba413f-669b-4478-af49-a51312807a81,"ID06 VPN",0]: VPN connection: failed to connect: 'Message recipient disconnected from message bus without replying'
Geg 22 15:38:53 platonas charon[1005]: 04[IKE] sending retransmit 2 of request message ID 3867164705, seq 4
Geg 22 15:38:53 platonas charon[1005]: 04[NET] sending packet: from 192.168.1.165[4500] to 195.67.6.50[4500] (244 bytes)
Geg 22 15:39:06 platonas charon[1005]: 09[IKE] sending retransmit 3 of request message ID 3867164705, seq 4
Geg 22 15:39:06 platonas charon[1005]: 09[NET] sending packet: from 192.168.1.165[4500] to 195.67.6.50[4500] (244 bytes)
Geg 22 15:39:13 platonas chromium-browser.desktop[5487]: [5487:5487:0522/153913.994035:ERROR:os_exchange_data_provider_aurax11.cc(528)] Not implemented reached in virtual uint32_t ui::OSExchangeDataProviderAuraX11::DispatchEvent(const PlatformEvent &)
Geg 22 15:39:26 platonas charon[1005]: 11[IKE] sending keep alive to 195.67.6.50[4500]
Geg 22 15:39:29 platonas charon[1005]: 12[IKE] sending retransmit 4 of request message ID 3867164705, seq 4
Geg 22 15:39:29 platonas charon[1005]: 12[NET] sending packet: from 192.168.1.165[4500] to 195.67.6.50[4500] (244 bytes)
Geg 22 15:39:50 platonas charon[1005]: 14[IKE] sending keep alive to 195.67.6.50[4500]

which looks remarkably like the earlier IPsec failure, and I've no idea why, since I thought xl2tp was running on top of IPsec, so why would port 1701 being busy affect IKE in any way?

@dkosovic

This comment has been minimized.

Copy link
Member

commented May 22, 2017

Regarding the UI issue, under the Unity desktop environment or running /usr/bin/nm-connection-editor directly I don't see 'Identity' on the left and the 'Apply' button on the bottom.

In the GNOME desktop environment and going to 'VPN Settings', I do see 'Identity' on the left and the 'Save' button has been replaced with an 'Apply' button, also the 'Export...' button is missing.

The only control I have for the 'Apply' or 'Save button toggling gray in the source code is handled by the check_validity() function on the following line :

and it is pretty simple, if the Gateway text box is not empty, then the 'Apply' or 'Save button is enabled, otherwise it is gray. But sounds like you worked out the IPv4 settings also have an impact on if it is gray.

Regarding the IPsec failure, some VPN servers have the following lines (or equivalent) in their IPsec config files:

leftprotoport=udp/1701
rightprotoport=udp/1701

With version 1.2.6 of this VPN plug-in, when port 1701 is busy, leftprotoport is not set in the local IPsec config.

Some VPN servers may insist on the client having the same leftprotoport and rightprotoport when negotiating the initial proposal. With Libreswan (but not sure about strongSwan) you might see a warning (but not an error) like the following when they don't match:

#2: our client peer returned port doesn't match my proposal - us:0 vs them:1701

Also with version 1.2.6, there is now a 10 second timeout if the IPsec connection can not be established, and the 'ipsec up' script is then killed on timeout. In previous versions, 'ipsec up' might continue to run indefinitely when it got into a bad state like this when bad settings were supplied.

For a majority of people, not using port 1701 on the client side won't be an issue and the packets will still be encapsulated.

Are you saying it now works for you with the correct phase 1 & 2 settings and with the xl2tpd service still running? If xl2tpd needs to be stopped, I may need to document it in the known issues.

@mgedmin

This comment has been minimized.

Copy link
Author

commented May 23, 2017

Are you saying it now works for you with the correct phase 1 & 2 settings and with the xl2tpd service still running? If xl2tpd needs to be stopped, I may need to document it in the known issues.

It works for me with the correct phase 1 & 2 settings and with the xl2tpd service stopped.

@dkosovic

This comment has been minimized.

Copy link
Member

commented May 23, 2017

hmm, I wonder if I should have used leftprotoport=udp/%any for the IPsec config file instead of not setting it if port 1701 was busy.

Assuming the run-time generated files as mentioned on the following page are still around :

would you be able to edit /var/run/nm-l2tp-ipsec-97ba413f-669b-4478-af49-a51312807a81.conf and add leftprotoport=udp/%any then issue the following:

sudo ipsec restart --conf /var/run/nm-l2tp-ipsec-97ba413f-*.conf --debug
sudo ipsec up 97ba413f-669b-4478-af49-a51312807a81

and then double check the IPsec connection is up by issuing sudo ipsec status.

The above ipsec commands are the same as what Networkmanger-l2tp uses to establish an IPsec connection.

@dragon788

This comment has been minimized.

Copy link

commented Jun 8, 2017

I'm having the same issue on 16.04 with the system strongswan and the latest nm plugin. port=0 if xl2tpd is running which causes a failure to connect, stopping the service allows it to work.

@dkosovic

This comment has been minimized.

Copy link
Member

commented Jun 11, 2017

I'm none the wiser, I've tried 4 different L2TP/IPsec VPN servers located on 3 different continents and wasn't able to reproduce the issue with my current setup, it didn't matter if NetworkManager-l2tp started xl2tpd process was using an ephemeral port or port 1701.

But when I threw a firewall into the mix, I think I reproduced the issue.

I wrote the following in the known issues :

it's a bit vague on the issue(s) as to why the xl2tpd service might need to be stopped, but should do.

For those pointing to this thread about using ike-scan to find out what cipher is used, I was wrong, you need to use a script like described here:

and try to but the 3DES cipher last in the list

@dkosovic

This comment has been minimized.

Copy link
Member

commented Jul 19, 2017

I've released NetworkManager-l2tp 1.2.8 and README.md file now mentions the issue with not stopping system xl2tpd service. So I will close this github issue.

@dkosovic dkosovic closed this Jul 19, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.