nm-l2tp / NetworkManager-l2tp

L2TP and L2TP/IPsec support for NetworkManager
GNU General Public License v2.0
488 stars 84 forks source link

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

Closed mgedmin closed 7 years ago

mgedmin commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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

dkosovic commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

With commit https://github.com/nm-l2tp/network-manager-l2tp/commit/ed00db61036addb21a77c06d2031b5922dc2efab 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 commented 7 years ago

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 commented 7 years ago

The recently released version 1.2.6 has commit https://github.com/nm-l2tp/network-manager-l2tp/commit/13ea66b02b7775e7c018621786d9a619c20cce02 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.

mgedmin commented 7 years ago

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 commented 7 years ago

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:

dkosovic commented 7 years ago

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 https://github.com/nm-l2tp/network-manager-l2tp/commit/b10d9c72bfc4a9b2ee5409e0e3b8a4394854ff51 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 commented 7 years ago

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

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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 commented 7 years ago

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.

mgedmin commented 4 years ago

FWIW I still need the sudo service xl2tpd stop; sudo update-rc.d xl2tpd disable workaround to make the VPN work on Ubuntu 19.04, using network-manager-l2tp 1.2.10-1.

dkosovic commented 4 years ago

The original maintainer who first created Ubuntu packages in 2012 :

had the following instructions on that page:

sudo service xl2tpd stop
sudo update-rc.d xl2tpd disable

I wasn't aware it was a problem until it was raised in this issue, but I did update the README.md file with the following and subsequently closed this issue :

Issue with not stopping system xl2tpd service

NetworkManager-l2tp starts its own instance of xl2tpd and if the system xl2tpd service is running, its own xl2tpd instance will not be able to use UDP port 1701, so will use an ephemeral port (i.e. random high port).

Although the use of an ephemeral port is considered acceptable in RFC3193, the L2TP/IPsec standard co-authored by Microsoft and Cisco, there are some L2TP/IPsec servers and/or firewalls that will have issues if an ephemeral port is used.

Stopping the system xl2tpd service should free UDP port 1701 and on systemd based Linux distributions, the xl2tpd service can be stopped with the following:

sudo systemctl stop xl2tpd

If stopping the xl2tpd service fixes your VPN connection issue, you can disable the xl2tpd service from starting at boot time with :

sudo systemctl disable xl2tpd

Using /usr/sbin/xl2tpd-controlwith the system xl2tpd could be a workaround, except not all linux distros ship with xl2tpd-control and some versions of xl2tpd-control are buggy and crash (most websites that give examples of xl2tpd command-line usage, don't use xl2tpd-control, so linux distro bug reports haven't been submitted too often for xl2tpd-control).

With many VPN servers, it's pretty simple to configure them to allow connections from a client that is using an ephemeral port.

Fedora and derivatives don't start the xl2tpd service when the xl2tp package is installed, not sure why Debian and Ubuntu do.

I'm not spending much time on maintaining this package now days, but will be more than happy to accept any github pull requests that fix this issue.

mgedmin commented 4 years ago

I had a brain fart and remembered the part where you attempted to solve the issue with xl2tpd-control, but forgot the eventual resolution, which was documenting the workaround. Sorry for the unnecessary noise!

delanym commented 1 year ago

@dkosovic On ubuntu 20.04 running strongswan 5.8.2 i can connect even with lx2tpd running and nm-l2tp-service reporting "can't bind to port 1701" so I dont know what going on there.

But then on my new ubuntu 22.04 running strongswan 5.9.5 the connection attempt fails. It fails after 10s. I dont see any handshake timeout configuration in the connection file at /etc/NetworkManager/system-connections and then I see this https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/420411

How can I configure this?

dkosovic commented 1 year ago

@delanym back in the day when most ISPs were still providing public IPv4 addresses it was not uncommon for L2TP servers to only accept connections that were using source port 1701. But it doesn't make much sense now that many ISPs are using CGNAT because in this scenario you can't have more than one L2TP client behind the same NAT as any new client connection will conflict with any pre-existing client.

The vast majority of L2TP servers accept an ephemeral source port for L2TP connections (and is the recommended setup), so I'm not surprised you are able to connect with Ubuntu 20.04.

Your Ubuntu 22.04 issue is unrelated to the topic in this issue, I suspect it is due to bugs introduced with NetworkManager 1.36, e.g., spuriously introduced routes and IP addresses:

As your issue is not related to this closed issue, I would recommend opening a new issue and I would also recommend including the logs by issuing:

sudo journalctl --no-hostname _SYSTEMD_UNIT=NetworkManager.service + SYSLOG_IDENTIFIER=pppd

Obfuscate any sensitive public IP addresses in the log output if you wish.

delanym commented 1 year ago

@dkosovic thanks, it seems the port doesn't matter, and the 10s timeout was warranted given that the remote refused my incorrect PSK - sorry. Some good came of this as it prompted an upgrade to IKEv2

dkosovic commented 1 year ago

@delanym oh I see, I now understand.

The 10 second timeout for the IPsec connection is defined here in the source: https://github.com/nm-l2tp/NetworkManager-l2tp/blob/1.20.4/src/nm-l2tp-service.c#L92

That timeout was introduced because in some cases the only way to kill the ipsec client was to send a SIGKILL signal which is a bit extreme but was necessary when the more graceful SIGHUP produced by the ipsec stop command wouldn't kill it and it would never die and cause all sorts of grief. The unresponsive ipsec client would usually happen in Quick mode (phase 2) when either PFS was enabled or the wrong PSK was supplied, but I stress only with some VPN servers. in combination with some versions of libreswan or strongswan

In hindsight I should have provide some sort of configuration for that timeout.

The maintainers of libreswan and strongswan strongly recommend moving from L2TP/IPsec to theIKEv2.

Android 12 no longer supports adding new L2TP connections and Google recommends moving to the more secure and less battery hungry IKEv2.