A couple usability issues

[kmansoft]

1 - When no *swan is installed - clicking on "IPsec Settings..."

I get a crash report in Fedora 30 - "Sorry! Looks like Advanced Network Configuration has crashed".

Maybe it woudl be better to disable "IPsec Setttings..." - or show a message that this option requires *swan - but not crash.

2 - It looks like there is no way to choose between IKEv1 and IKEv2 - the generated ipsec.conf always uses ikev2=never.

This can be a problem depending on the server.

In general v2 is better - fewer roundtrips to establish an connection.

Perhaps there can be a setting? Version 1 / 2?

[dkosovic]

Thanks for the crash bug report, I'll look into it when I get home.

Just curious, have you seen any other L2TP VPN clients that use IKEv2? This L2TP client neither supports IKEv1 XAUTH nor IKEv2, both of which don't need L2TP (including PPP for user authentication). There is already NetworkManager-strongswan (IKEv2) and NetworkManager-libreswan (IKEv1 XAUTH and IKEv2) which provide IKEv2 support without the overhead of also providing L2TP. But I'm open to the idea, I just want to understand why IKEv2 would need L2TP or wouldn't be configured for user authentication for remote access?

[dkosovic]

Forgot to mention the reason I explicitly set ikev2=never was because it seemed to be using the default libreswan cryptographic proposal set for IKEv2 even when IKEv1 was used, which caused some clients to break after a libreswan upgrade.

[kmansoft]

Just curious, have you seen any other L2TP VPN clients that use IKEv2?

No I haven't - maybe because L2TP has nothing to do with IPSec - it's an additional layer and can be configured on the IPSec server in any unpredictable way.

IKEv2 is definitely "out there" - it has more efficient handshaking, has NAT traversal officially built-in (vs. extension in IKEv1). The RFC is from 2010.

default libreswan cryptographic proposal set for IKEv2

... and it's even used by default by libreSwan :) and those guys know what they're doing.

I would think a setting with a default value (IKEv1 as default, to preserve how things are for existing users) should take care of that, no?

[kmansoft]

PS - I don't know if your app supports strongSwan as well, the syntax is a bit different:

https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection

keyexchange = ike | ikev1 | ikev2

method of key exchange; which protocol should be used to initialize the connection. Prior to 5.0.0 connections marked with ikev1 were initiated with Pluto, those marked with ikev2 with Charon. An incoming request from the remote peer was handled by the correct daemon, unaffected from the keyexchange setting. Starting with strongSwan 4.5.0 the default value ike is a synonym for ikev2, whereas in older strongSwan releases ikev1 was assumed. Since 5.0.0 both protocols are handled by Charon and connections marked with ike will use IKEv2 when initiating, but accept any protocol version when responding.

So here too IKEv2 is default and you have to opt into IKEv1, same as with libreSwan (based on what you wrote... I normally use strongSwan but with new-style config files...)

[kmansoft]

Oh and to answer this:

I just want to understand why IKEv2 would need L2TP

L2TP is often set up with IPSec protection - that's your wizard isn't it?

It has a button for "IPSec settings" - for the L2TP connection specifically, so that it's only brought up when the L2TP connection is brought up.

IKEv2 / v1 is really an IPSec option not an L2TP option, it doesn't "need" L2TP.

But someone might set up an L2TP / IPSec server side with IKEv2 and try to use your wizard to connect to it. That's the scenario I ran into.

There is already NetworkManager-strongswan

Sure, and those are completely independent of your project, right?

[dkosovic]

I reproduced the crash with both nm-connection-editor and gnome-control-center, like you suspected it happens when no *swan is installed. With version 1.2.12 i added code to the GUI to gray out the "Disable PFS" option if it detected strongswan.

Most linux distributions use /usr/sbin/ipsec for both libreswan and strongswan. I use ipsec --version to determine if it is libreswan or strongswan at runtime, Fedora is a bit different as it renames /usr/sbin/ipsec to /usr/sbin/strongswan so both swan packages can be installed simultaneously. NetworkManager-l2tp on Fedora will default to libreswan if it finds an ipsec script, it then tries looking for a strongswan script. I shouldn't have tried to determine the swan version if it couldn't find either as it is literally trying to do NULL --version and seg faults.

I'm thinking of greying out the enable IPsec tick box if it can't find any *swan, like you suggested.

On Debian the package dependencies have: Depends strongswan | libreswan

On Fedora I wasn't able to do the same dependencies, so changed requires: libreswan since Fedora 24 to : Recommends: libreswan to allow uninstalling libreswan and using strongswan instead. I guess I could have used a config option to explicitly specify which *swan to use, but that adds an extra complexity for end users.

Anyway, I'm glad you let me know about the bug. I didn't get a chance to commit the fix, just want to do a bit more testing before I commit anything.

I'll get back to the other issues you raised later.

[kmansoft]

Anyway, I'm glad you let me know about the bug.

Cool. I like filing bugs against Fedora software because developers are so responsive :)

[dkosovic]

I'm in the process of adding an IKEv2 Keyexchange option, but time escaped me over the weekend.

I've been reluctant to add many of the IPsec options, I always want to make sure they are needed. For some scenarios, new options can break non-GNOME NetworkManager-l2tp GUI clients that i don't maintain. I think this option should be okay with non-GNOME GUIs as I will force it to IKEv1 if no keyexchange option is set.

Regarding your strongswan comment, keyexchange = ikev1 has been set with NetworkManager-l2tp ever since it was modified to support strongswan back in 2015, which was just a bit before my time as maintainer.

I'm planning on modifying "Legacy Proposals" from having Windows Server 2019 proposals to Win10 proposals (which I need to determine) and renaming the button to "Windows Algorithms". Once I've done that and added an IKEv2 Keyexchange tick box, I'll make a new 1.2.14 release hopefully this week (with Fedora release soon after).

[kmansoft]

I've been reluctant to add many of the IPsec options

I think it's understandable that a combined UI can only serve most common cases - it's for convenience really.

For example I'm not (and neither is anyone else, I guess) raising any issues with configuring the IPSec part to use certificate based authentication (as opposed to PSK). That can be configured separately, in *swan config files or on an in-between router.

[dkosovic]

There were a significant number of requests for certificate support for NetworkManager-l2tp. You are using an old branch which doesn't have certificate support. For user and machine certificate support, NetworkManager-l2tp needs to be linked against OpenSSL. Fedora doesn't allow GPLv2 NetworkManager code to be to be linked against OpenSSL.

This VPN plugin auto detects the following TLS certificate and private key file formats by looking at the file contents and not the file extension :

• PKCS#12 certificates.
• X509 certificates (PEM or DER).
• PKCS#8 private keys (PEM or DER).
• traditional OpenSSL RSA, DSA and ECDSA private keys (PEM or DER).

For TLS user certificate support, the ppp package has to have the EAP-TLS patch for pppd applied to the ppp source code (which Fedora already does) :

• https://www.nikhef.nl/~janjust/ppp/

Fedora 31 will probably come with OpenSSL 3.0.0 which will allows linking NetworkManager GPLv2 code with openSSL.

[kmansoft]

Fedora 31 will probably come with OpenSSL 3.0.0 which will allows linking NetworkManager GPLv2 code with openSSL.

Oh I see - thanks for the clarification!

[dkosovic]

NetworkManager-l2tp-1.2.14-1 RPMs for Fedora 29 to 32 which include a "Use IKEv2 key exchange" check box are being pushed out. The following page shows the status of the RPMs, they should eventually make it to stable/updates :

• https://apps.fedoraproject.org/packages/NetworkManager-l2tp/updates/

I originally planned on updating the source with the "Use IKEv2 key exchange" check box much earlier, but ran out of time before going on leave, then had hardware issues and almost gave up on maintaining this package.

I'll now close this issue.