Bug#1020495: [Pkg-swan-devel] Bug#1020495: Error: unable to load VPN connection editor - on Identity tab at Gnome Network manager VPN
That's because the settings app uses GTK 4, while `nm-connection-editor` still uses GTK 3. In order for the strongSwan plugin to work with GTK 4, it has to be built with `--with-gkt4`. That creates an additional version of the editor that's linked against GTK 4 (besides the one linked against GTK 3). These are actually two shared libraries that are loaded dynamically at runtime by the main editor plugin depending on whether it's loaded by a GTK 3 or 4 application. Ah, thanks for the information. So that means at some point we should enable that in our build I guess. Yep. Is it a problem if the package depends on both libgtk-3-0 and libgtk-4-0 as well as libnma0 and libnma-gtk4-0? Or does that require a separate package for the GTK 4 version? Or is there some metadata magic that can make it work with GTK 3 and/or GTK 4 (at least one, but does not require both)? Technically, as I mentioned before, the main plugin (libnm-vpn-plugin-strongswan.so), that's the one actually loaded by NM or any other GUI, does not depend on libgtk or libnma. However, depending on whether it was loaded by an application that uses GTK 3 or GTK 4 (it uses dlsym() to search for a GTK3-only symbol), it then dynamically loads either libnm-vpn-plugin-strongswan-editor.so or libnm-gtk4-vpn-plugin-strongswan-editor.so via dlopen(), which are linked against the corresponding libgtk/libnma. So I guess one could argue that neither is a hard dependency for the package as the application that loads the plugin must have such a dependency on either version of these libraries anyway (at least libgtk, not sure about libnma). So maybe those dependencies could also be omitted? Regards, Tobias
Bug#1020495: Error: unable to load VPN connection editor - on Identity tab at Gnome Network manager VPN
Hi Patrik, * What was the outcome of this action? With the `nm-connection-editor` you can edit it, but you can not do that via network-manager! That's because the settings app uses GTK 4, while `nm-connection-editor` still uses GTK 3. In order for the strongSwan plugin to work with GTK 4, it has to be built with `--with-gkt4`. That creates an additional version of the editor that's linked against GTK 4 (besides the one linked against GTK 3). These are actually two shared libraries that are loaded dynamically at runtime by the main editor plugin depending on whether it's loaded by a GTK 3 or 4 application. Regards, Tobias
Bug#1004166: strongswan-nm: Creates VPN configs that disable using system CA certificate directories
Hi Daniel, Applying any change to any field in the NetworkManager strongswan VPN plugin config will write a text config file with the 'certificate=' line. As I said, I can't reproduce this. I can change whatever in the GUI, no "certificate=" line is added to the config file. Notice the missing 'certificate=' line. However, any change made in the GUI would restore the certificate= line as show below: I don't see how. The GUI checks gtk_file_chooser_get_filename() and only if that returns a value != NULL will "certificate" be written to the config. That's why I was asking what the GUI actually displays in that file chooser in your case. According to the reference [1], NULL is returned "if no file is selected, or the selected file can't be represented with a local filename", I don't think an empty string should be returned. Alternatively, strongswan should assume 'certificate=' indicates the system certificates should be used. Yes, we could add a check for an empty string, but the setting shouldn't be there with an empty string in the first place. Regards, Tobias [1] https://docs.gtk.org/gtk3/method.FileChooser.get_filename.html
Bug#1004166: strongswan-nm: Creates VPN configs that disable using system CA certificate directories
Hi Daniel, Removing the blank "certificate=" line from the VPN connection config in /etc/NetworkManager/system-connections/ restores the original behavior. However, modifying the connection config in NetworkManager will again add the blank "certficiate=" line, once again breaking the connection config. I can't reproduce this. What does the "Certificate" file chooser display when you open the editor? "(None)"? Regards, Tobias
Bug#941972: strongswan: eap-mschapv2 plugin not loaded
Hi Richard, You either need the md4 plugin, or one of the openssl or gcrypt plugins (which also provide the MD4 algorithm) to use EAP-MSCHAPv2 (there should be error in the log during startup regarding the missing dependency). The openssl plugin is shipped with libstrongswan-standard-plugins, the gcrypt plugin with libstrongswan-extra-plugins, the md4 plugin is not built/packaged by Debian. If you already have the plugins installed, make sure they are loaded [1]. Regards, Tobias [1] https://wiki.strongswan.org/projects/strongswan/wiki/PluginLoad
Bug#927158: strongswan-nm: charon-nm reports no usable smartcard found despite the smartcard working with charon as called by swanctl
Hi Robert,
> The contents of /etc/strongswan.d/charon/pkcs11.conf are:
> pkcs11 {
The contents of that file are not relevant to charon-nm (unless you
changed strongswan.conf). Configure the plugin's settings directly in
strongswan.conf in the charon-nm.plugins.pkcs11 section (or set them in
the libstrongswan section so they apply to both daemons).
Regards,
Tobias
Bug#807057: Incorrect PRF used by tls1_export_keying_material() with TLS 1.2
Package: libssl1.0.0 Version: 1.0.1e-2+deb7u18 When calling tls1_PRF() tls1_export_keying_material() directly passes the value of algorithm2 instead of using ssl_get_algorithm2(), which overrides the default PRF algorithm when TLS 1.2 is used. Therefore, the keying material is actually derived using the old PRF (combination of MD5/SHA1), which breaks e.g. EAP-TLS with newer versions of FreeRADIUS. The problem is corrected in later versions of OpenSSL. The fix can be found at [1]. Regards, Tobias [1] https://github.com/openssl/openssl/commit/4fdf91742e3b7eb73e41b38d8d5b2f17d4d5b544
Bug#718302: strongswan: Enable sqlite and mysql plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I'm unsure about this, but I'm also unsure what's the difference between the sql plugin and the mysql/sqlite plugins. Is the sql plugin without at least one of the database backends plugins? The sql plugin [1] is a configuration backend based on SQL databases. The mysql/sqlite plugins are database drivers/interfaces, of which at least one is required to use the sql plugin (or the attr-sql plugin [2] for that matter). My point was: does it make sense to have the sql/attr-sql plugins without any database backend enabled? No, enabling those without any database backends is pointless. In any case, I'm not sure about adding the MySQL dependency (both build-dep and dep). At one point, we might create a new -plugins binary package for all those extra plugins which might not be needed in the general case but that some people might find useful. I assume separate packages e.g. libstrongswan-mysql and libstrongswan-sqlite that provide those backends would make sense. The sql/attr-sql plugin could still be provided by the default package without dependencies on any specific SQL implementation/library. Having one package per plugin might be a bit overkill though… Perhaps, but isn't that how it is done for many other packages that have plugins like that (e.g. libqt4[-sql-mysql|-sql-sqlite], php5[-mysql|-sqlite], postfix[-mysql|-pgsql]). Regards, Tobias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlJTxmUACgkQR2BKbzEc4IW4WgCgrcvwIOMBLLXwU+yF0YYa3p15 /DYAn3X84BHVrQHKlRC50Ockoz+HBngN =xlZ0 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718302: strongswan: Enable sqlite and mysql plugins
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Yves-Alexis, I'm unsure about this, but I'm also unsure what's the difference between the sql plugin and the mysql/sqlite plugins. Is the sql plugin without at least one of the database backends plugins? The sql plugin [1] is a configuration backend based on SQL databases. The mysql/sqlite plugins are database drivers/interfaces, of which at least one is required to use the sql plugin (or the attr-sql plugin [2] for that matter). In any case, I'm not sure about adding the MySQL dependency (both build-dep and dep). At one point, we might create a new -plugins binary package for all those extra plugins which might not be needed in the general case but that some people might find useful. I assume separate packages e.g. libstrongswan-mysql and libstrongswan-sqlite that provide those backends would make sense. The sql/attr-sql plugin could still be provided by the default package without dependencies on any specific SQL implementation/library. Keeping those dependencies from build-dep might be tricky though. Or wouldn't that require a separate source package? Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/SQL [2] http://wiki.strongswan.org/projects/strongswan/wiki/AttrSQL -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAlJSeuoACgkQR2BKbzEc4IXRpgCgm60kHST1sC2ougNc81iygG2n 0FwAn2Qz6Dxbkkp5QqOSbZe9R63vGmKa =FiCX -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#718291: strongswan: Enable duplicheck plugin
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Please enable the ‘duplicheck’ plugin. This plugin is a more specialized form of the ‘uniqueids’ feature for detecting duplicate identities. This plugin is marked as stable according to the PluginList¹ wiki and doesn't require any additional build dependencies. I'm not sure if it's a good idea to enable this plugin. As Gerald says it is a very specialized check for duplicate SAs. Well, perhaps not the check itself, but certainly the behavior once a duplicate is found. The problem is that if a duplicate is detected by this plugin, if the old IKE_SA is still alive, you'll end up with no SA at all. I guess that's not what most users expect. This problem gets worse because the plugin is enabled by default: You may want to add charon.plugins.duplicheck.enable = no to strongswan.conf since this plugin is enabled by default. This is reasonable but will not help users that upgrade an existing installation for which they already have created a strongswan.conf file. Granted, enabling plugins like these by default (there are others that are enabled when loaded) was not a very good idea. In particular because we still have no decent way yet to enable/disable plugins in a more dynamic fashion (something like Apache's a2enmod perhaps). It would be great if there was a way to ship all plugins but let users enable them on demand (charon.load does not work very well for this). We actually considered just changing the defaults for the .enable options of all plugins to no with 5.1.0, which at least would allow shipping all plugins. But it would also require many users to update their strongswan.conf and enable plugins manually after upgrading. Not sure it that's any better. What is the package maintainer's point of view on this? Regards, Tobias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlH22AwACgkQR2BKbzEc4IW+wgCfVWyomLT9GjrBaeaPD0cHqB3z F1IAoL38y83MCb8CziygwvrxHwlTQPWV =0xr9 -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703032: strongswan: It totally breaks local network
Hi Vladimir, It may be possible I am only one who encounter this problem, because of very unusual configuration: leftsubnet = 192.168.0.0/24 rightsubnet = 0.0.0.0/0 With this configuration I had a problem in version 4.5 also, but I have solved it by deleting second default route from table 220. What exactly is the point of rightsubnet=0.0.0.0/0 if you don't want to tunnel everything? How does your network topology look like? With this configuration the machine where this strongswan is running announces all address of local network 192.168.0.0/24 as it's own, so all IP address becomes binded with the same MAC address and network stops working: nobody can connect each other. That's due to the farp plugin that is enabled by default in the Debian package. With rightsubnet=0.0.0.0/0 It will fake ARP responses for every IP address, which is certainly not optimal. Try disabling the plugin by specifying a custom list of plugins with the charon.load option in strongswan.conf (you can use the list returned in 'ipsec statusall' as template, just remove the farp plugin from it). Regards, Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#664873: strongswan-starter: strongswan replaces /etc/resolv.conf instead of adding information
Since Ubuntu 12.04 seems to come with resolvconf installed by default it
would make sense to add support for it. Which is what I did in the
resolvconf branch of our repository (see [1]). Would be great if you
could try the patches (only [2] is really required).
Thanks, will do and report back.
Unfortunately, sid is still at 4.5.2 and the patch doesn't apply cleanly
against it, so I'll first try to backport it.
The attached patch should apply cleanly to 4.5.2.
Regards,
Tobias
From 1ad1c0f41311296d22fa183a7b7cba0b97dc03b3 Mon Sep 17 00:00:00 2001
From: Tobias Brunner tob...@strongswan.org
Date: Mon, 26 Mar 2012 15:00:14 +0200
Subject: [PATCH] Added support for the resolvconf framework in resolve plugin.
If /sbin/resolvconf is found nameservers are not written directly to
/etc/resolv.conf but instead resolvconf is invoked.
---
src/libhydra/plugins/resolve/resolve_handler.c | 201 ++--
1 files changed, 149 insertions(+), 52 deletions(-)
diff --git a/src/libhydra/plugins/resolve/resolve_handler.c b/src/libhydra/plugins/resolve/resolve_handler.c
index feb2fd0..21bc3af 100644
--- a/src/libhydra/plugins/resolve/resolve_handler.c
+++ b/src/libhydra/plugins/resolve/resolve_handler.c
@@ -1,4 +1,5 @@
/*
+ * Copyright (C) 2012 Tobias Brunner
* Copyright (C) 2009 Martin Willi
* Hochschule fuer Technik Rapperswil
*
@@ -15,12 +16,20 @@
#include resolve_handler.h
+#include sys/types.h
+#include sys/stat.h
#include unistd.h
#include hydra.h
#include debug.h
#include threading/mutex.h
+/* path to resolvconf executable */
+#define RESOLVCONF_EXEC /sbin/resolvconf
+
+/* prefix used for resolvconf interfaces */
+#define RESOLVCONF_PREFIX lo.inet.ipsec.
+
typedef struct private_resolve_handler_t private_resolve_handler_t;
/**
@@ -39,49 +48,35 @@ struct private_resolve_handler_t {
char *file;
/**
+ * use resolvconf instead of writing directly to resolv.conf
+ */
+ bool use_resolvconf;
+
+ /**
* Mutex to access file exclusively
*/
mutex_t *mutex;
};
/**
- * Implementation of attribute_handler_t.handle
+ * Writes the given nameserver to resolv.conf
*/
-static bool handle(private_resolve_handler_t *this, identification_t *server,
- configuration_attribute_type_t type, chunk_t data)
+static bool write_nameserver(private_resolve_handler_t *this,
+ identification_t *server, host_t *addr)
{
FILE *in, *out;
char buf[1024];
- host_t *addr;
size_t len;
bool handled = FALSE;
- switch (type)
- {
- case INTERNAL_IP4_DNS:
- addr = host_create_from_chunk(AF_INET, data, 0);
- break;
- case INTERNAL_IP6_DNS:
- addr = host_create_from_chunk(AF_INET6, data, 0);
- break;
- default:
- return FALSE;
- }
-
- if (!addr || addr-is_anyaddr(addr))
- {
- DESTROY_IF(addr);
- return FALSE;
- }
- this-mutex-lock(this-mutex);
-
in = fopen(this-file, r);
/* allows us to stream from in to out */
unlink(this-file);
out = fopen(this-file, w);
if (out)
{
- fprintf(out, nameserver %H # by strongSwan, from %Y\n, addr, server);
+ fprintf(out, nameserver %H # by strongSwan, from %Y\n, addr,
+server);
DBG1(DBG_IKE, installing DNS server %H to %s, addr, this-file);
handled = TRUE;
@@ -99,40 +94,17 @@ static bool handle(private_resolve_handler_t *this, identification_t *server,
{
fclose(in);
}
- this-mutex-unlock(this-mutex);
- addr-destroy(addr);
-
- if (!handled)
- {
- DBG1(DBG_IKE, adding DNS server failed, this-file);
- }
return handled;
}
/**
- * Implementation of attribute_handler_t.release
+ * Removes the given nameserver from resolv.conf
*/
-static void release(private_resolve_handler_t *this, identification_t *server,
- configuration_attribute_type_t type, chunk_t data)
+static void remove_nameserver(private_resolve_handler_t *this,
+ identification_t *server, host_t *addr)
{
FILE *in, *out;
char line[1024], matcher[512];
- host_t *addr;
- int family;
-
- switch (type)
- {
- case INTERNAL_IP4_DNS:
- family = AF_INET;
- break;
- case INTERNAL_IP6_DNS:
- family = AF_INET6;
- break;
- default:
- return;
- }
-
- this-mutex-lock(this-mutex);
in = fopen(this-file, r);
if (in)
@@ -142,7 +114,6 @@ static void release(private_resolve_handler_t *this, identification_t *server,
out = fopen(this-file, w);
if (out)
{
- addr = host_create_from_chunk(family, data, 0);
snprintf(matcher, sizeof(matcher),
nameserver %H # by strongSwan, from %Y\n,
addr, server);
@@ -160,13 +131,133 @@ static void release(private_resolve_handler_t *this, identification_t *server,
fputs(line, out);
}
}
- addr-destroy(addr);
fclose(out);
}
fclose(in);
}
+}
+/**
+ * Add or remove the given nameserver by invoking resolvconf.
+ */
+static bool invoke_resolvconf(private_resolve_handler_t *this,
+ identification_t *server, host_t *addr,
+ bool install)
+{
+ char cmd[128];
+
+ /* we use the nameserver's IP address as part
Bug#664873: strongswan-starter: strongswan replaces /etc/resolv.conf instead of adding information
Hi Yves-Alexis, thanks for the report. Strongswan, when adding a dns server in /etc/resolv.conf, seems to remove the file and recreate it, thus not preserving the symlink. True, charon adds the received DNS server to a new file with the same name (after opening and unlinking the existing /etc/resolv.conf) and appends the previous content afterwards. Since Ubuntu 12.04 seems to come with resolvconf installed by default it would make sense to add support for it. Which is what I did in the resolvconf branch of our repository (see [1]). Would be great if you could try the patches (only [2] is really required). Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=log;h=refs/heads/resolvconf [2] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=99636819 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#665612: strongswan: Including individual glib headers no longer supported
Hi Michael, fixed upstream in [1]. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=8e066237 -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661524: strongswan: Compatibility for Apple iOS devices
Hi Tony, I cannot use iOS to connect to my server using IKEv1, prompting could not validate server certificate (I have installed both client p12 and CA certificate on the iOS device). This is more likely related to missing subjectAltNames in the gateway certificate. You have to make sure the DNS name or IP address you configure on the iOS device is contained as subjectAltName in the gateway certificate. Regards, Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#661524: strongswan: Compatibility for Apple iOS devices
Hi Tony, I'm not sure if --enable-cisco-quirks is actually required to support iOS devices. I know our wiki says otherwise, but the page you refer to was written mainly by a user who apparently assumed the client on iOS devices is written by Cisco, which is a common misconception. The fact is, thought, that the client on the iOS devices is actually racoon (the Cisco logo and name is just for marketing reasons). Could you please try without the option (i.e. with the stock Debian package). If it works I will change the wiki page accordingly. Thanks, Tobias -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
