-
Notifications
You must be signed in to change notification settings - Fork 84
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
IPSec options hard coded #34
Comments
There was a voluteer that was going to write code to add the more obscure options in a config file, but I never heard anything back from him. Although I don't disagree with you that many parameters should be user configurable, I'm not sure if the ones you listed need to be: pfsSince strongSwan version 5.0.0, this parameter has no effect anymore, please see the strongSwan docs for more details. strongSwan version 5.0.0 was released in 2012 and most Linux distributions were still using Openswan back then. With Libreswan, even if "pfs=no" is set, PFS will still be used if the VPN server wants to use it. esp and ikeWith Libreswan these hardcoded parameters were removed as it has an extensive set of default initial proposal ciphers to negotiate with the VPN server. There were lots of requests to remove these hardcoded parameters in Fedora Bugzilla and I haven't seen any new cipher related bugs since removing them. With newer versions of strongSwan, it has been removing the weaker ciphers from the default initial proposals. So I've been adding the older ciphers for backwards compatiblity using these parameters. See commit 45815d1 . The ciphers added using these parameters are in addition to the default initial proposal ciphers. Are there some missing ciphers that users would need to add for strongSwan? Perhaps I should modify the code to add all the default ciphers Libreswan uses. keyexchangeIf a user wants to use IKEv2, they should use network-manager-strongswan instead. For a L2TP NetworkManager plugin with optional IPsec support, IKEv2 doesn't make sense (as L2TP isn't needed), so "keyexchange=ikev1" is hard coded in this case. |
@dkosovic, thank you for your extensive answer. I'm no IPSec expert, but your explanations make sense to me. There seems to be no reason for the options The reason why I'd like to change those options is, that I'm having problems connecting to a proprietary Zyxel firewall using the default settings. In order for the connection to work, I have to apply the following patch:
The exclamation mark is important here. If I understand it correctly, this prevents the default ciphers from being appended to the list. I don't know why it does not work otherwise, since I'm not sure if anybody else has problems like this, but the possibility to configure these settings would certainly help me in this situation. |
I'll look into it after I get back from holiday leave after the new year. |
Hey guys! Are you think it would be good idea to make an ability to configure/override all strongswan options, on IPSec configuration window maybe? I think that it is not too hard to implement and I can do it if you think my proposal it is a right way. |
As a general rule of thumb, the L2TP/IPsec VPN GUI shouldn't need to expose anything more than GUI clients on Windows, macOS, iOS or Android. The biggest thing missing that the other platforms have is the support of certificates for authentication (L2TP and IPsec). To add certificates support will involve using Gnome libsecret with the GUI and src/nm-l2tp-service.c (libsecret is currently used with the passwords). There are other NetworkManger VPN clients that support certificates and would be a good place to see how it is done. I don't think the list of ciphers discussed above should be added as a GUI option as it will only confuse users. In this case the need to configure I think I don't know if any of the other NetworkManger VPN clients have any config files, although I suspect NetworkManager-strongswan might. |
+1 For the config file for ike and esp. My VPN provider's Cisco Unity seems to want ike=aes128-sha1-modp1024,3des-sha1-modp1024! for the connection to work (that is if I control strongswan and xl2tpd manually). Weirdly enough network-manager-l2tp made ipsec connection establishes with esp=aes128-sha1,3des-sha1 (as it is now in the network-manager-l2tp generated config), but xl2tpd just cannot send anything through the connection. So, I do not know if just adding 3des-md5 to esp list would work since it seems already accept aes128-sha1 or 3des-sha1 and then fail to send anything through. Can be of course some other setting, but at least if I change esp=aes128-sha1,3des-sha1 in my "manual" config, it does not work. So, I think it would be nice to have option to override ike and esp completely in my setup. |
I've been wanting to make a new release soon of this VPN plug-in and started thinking about this issue more in the last few days. I noticed NetworkManager-libreswan :
has an Advanced expander that hides Phase 1 Algorithms (i.e. ike) and Phase 2 Algorithms (i.e. esp) text boxes. So I'll probably do the same. I'm thinking of not explicitly setting Hopefully have something out soon after I've fixed up a few other issues. |
This commit produces some problems
Because of that it is impossible to change phase2 cipher. Unfortunately it accompanied with additional issue:
It looks like in my personal case my provider (Cisco Meraki is used) denies sha256 so it doesn't allow to use current defaults (there is no sha1 in current defaults). Previous settings "3des-sha1-modp1024" and "3des-sha1" works just fine. I think Cisco Meraki is actually not so rare case, so probably this change will affect many users. |
Thanks, the ipsec_phase2 typo has now been corrected in the repo. Before I explicitly added the weaker ciphers in commit 45815d1 that were dropped in the initial proposal defaults with newer versions of strongSwan, there weren't that many people with issues. But things might have changed by now with more people using newer versions of strongSwan. Apparently SHA-1 was removed from the strongSwan initial proposal defaults as they claim it is broken and insecure, they list the broken algorithms on the following page : In a new troubleshooting section on the wiki, I was going to document how to add the weak algorithms that earlier versions of strongSwan used. I have mixed feelings about not using explicit |
@dkosovic, I can confirm that the recent changes allow us to override the I don't quite understand your concerns regarding the new settings, though. Couldn't you just provide the same values as before as default? If strongSwan changed their preferences, this sounds like a different issue to me. |
The updated README.md file has links to the strongswan documentation regarding the broken ciphers and which ciphers they recommend not to use, It also includes an example of how to add the ciphers back that earlier versions of NetworkManager-l2tp and strongswan used. Although I was slow to admit the need to override esp and ike options, now they can be overridden, I figured it's better for the end-user to decide if they want to risk using a broken cipher. |
The KDE users can use |
@corro in a sense I am going back to the same values of ike and esp prior to NetworkManager-l2tp 1.2.4 which was not explicitly setting them. I only started setting ike and esp because of a newer strongSwan which dropped a few ciphers that I added back. At the time I figured I might as well add 3des-sha1-modp1024 as the earlier versions of NetworkManager were using them. So I think I agree with you. NetworkManager-l2tp 0.9.8.8 and earlier had the following supplementary cipher suites:
NetworkManager-l2tp 1.2.2, 1.2.0, 1.0.2 and 1.0.0 didn't set ike or esp. NetworkManager-l2tp 1.2.4 had the following supplementary cipher suites:
|
Most configuration options of the IPSec connection are hard coded in
nm-l2tp-service.c
. There seems to be no possibility to adjust these options to match the requirements of a VPN server other than patching the source code.I understand that not every option needs to be configurable, but some of them depend on the configuration of the remote VPN server. The ones I encountered so far are:
pfs
esp
ike
keyexchange
Please see the strongSwan documentation for an explanation of these options.
Would it be possible to allow users to tune these options to their needs?
The text was updated successfully, but these errors were encountered: