Re: [strongSwan] Small Problems with 5.2
Hi Dirk, Not sure why the behavior changed between 5.1.3 and 5.2.0 in this regard; likely that it is related to the replaced ipsec.conf parser. It's probably the new parser. Checking the logs on the gateway running 5.1.3 I discovered that the rightsendcert = never wasn't honoured for any connection. Windows 7 eap clients received a cert request too. So your suggestion to remove this option from our config should be no problem. Intriguing. Could you send me the complete config file that manifests this difference in behavior? Thanks, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Hi Tobias, --On Wednesday, July 16, 2014 10:48:30 AM +0200 Tobias Brunner tob...@strongswan.org wrote: Not sure why the behavior changed between 5.1.3 and 5.2.0 in this regard; likely that it is related to the replaced ipsec.conf parser. It's probably the new parser. Checking the logs on the gateway running 5.1.3 I discovered that the rightsendcert = never wasn't honoured for any connection. Windows 7 eap clients received a cert request too. So your suggestion to remove this option from our config should be no problem. Intriguing. Could you send me the complete config file that manifests this difference in behavior? sure The normal ipsec.conf includes all *.conf files in the connections directory. The files in this directory are named: 0_all_w7_eapmschap.conf which I attached as its holds the rightsendcert = never. One file 98_partner1.conf. The rest are subnet related config files named 172.xx.xx-name.conf I added one too. Best regards Dirk ipsec.conf Description: Binary data 0_all_w7_eapmschap.conf Description: Binary data 98_partner1.conf Description: Binary data 172.25.22-abt1.conf Description: Binary data ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Hi Dirk, Not sure why the behavior changed between 5.1.3 and 5.2.0 in this regard; likely that it is related to the replaced ipsec.conf parser. It's probably the new parser. Checking the logs on the gateway running 5.1.3 I discovered that the rightsendcert = never wasn't honoured for any connection. Windows 7 eap clients received a cert request too. So your suggestion to remove this option from our config should be no problem. Intriguing. Could you send me the complete config file that manifests this difference in behavior? sure The normal ipsec.conf includes all *.conf files in the connections directory. The files in this directory are named: 0_all_w7_eapmschap.conf which I attached as its holds the rightsendcert = never. One file 98_partner1.conf. The rest are subnet related config files named 172.xx.xx-name.conf I added one too. Thanks a lot. It's definitely caused by the new parser. The difference is the order in which included files are handled. I wasn't fully aware of this, but apparently the old parser stored the included files (as returned by glob) on a stack and then parsed them beginning from the top. So the example files were read in this order: ipsec.conf before include 98_partner1.conf 172.25.22-abt1.conf 0_all_w7_eapmschap.conf ipsec.conf after include Which is probably exactly the opposite of what you intended to achieve with those number prefixes. So with the old parser the win7eapmschap config was the last one passed to charon, and thus never got used for the early IKE phase where the left|rightsendcert option applies and the IP addresses and IKE version are used to find a matching config. The new parser handles included files in alphabetical order (i.e. reversed in comparison), which means the win7eapmschap config is now the first one passed to charon. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Hi Martin, --On Friday, July 11, 2014 03:04:27 PM +0200 Martin Willi mar...@strongswan.org wrote: ipsec_starter[3318]: notifying watcher failed: Broken pipe I got: no trusted RSA public key found for NAME Btw, I don't think these two issues are directly related. While asynchronous IPC operation is affected, starter actually doesn't use that. Probably something else is wrong with that key: trust chain validation, certificate exchange, or loading trusted certificates. Your log might have more details. was there a change in 5.2 about charon asking for the certificate of the peer? I can establish a connection when I add leftsendcert=yes to the configuration of my roadwarrior. If I don't add it I get a connection with 5.1.3 but on 5.2 I get: [IKE] no trusted RSA public key found for 'C=DE, O=' in the log of the server. Best Regards Dirk pgpKoigv8o7Ll.pgp Description: PGP signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Dirk, was there a change in 5.2 about charon asking for the certificate of the peer? I can establish a connection when I add leftsendcert=yes to the configuration of my roadwarrior. None that I'm aware of. leftsendcert=ifasked was the policy ever since. If I don't add it I get a connection with 5.1.3 but on 5.2 I get: [IKE] no trusted RSA public key found for 'C=DE, O=' in the log of the server. As the default policy is ifasked, this most likely implies that your server does not send a certificate request. By default certificate requests are sent; what is your rightsendcert setting on the server? charon logs the certificates and certificate requests sent/received during the exchange, that should help in analyzing what is missing. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
With this connection active it doesn't matter if I set rightsendcert to ifasked or yes in the default section or the specific connection section of my linux roadwarrior. I can't connect because charon doesn't send a certificate request. If I remove the conn section for win 7 eap, I can connect. Certificate requests are sent very early in the IKE negotiation. As a responder, it is sent in the first IKE_SA_INIT response. At this stage, charon can not reliably select a configuration, as no peer identities or authentication methods are known yet. If no IP address selectors are in place (using left/right), usually just the first matching configuration is used. This probably is the win7 connection in your configuration. I set rightsendcert = never as mentioned in the wiki page While this recommendation is fine if you handle Windows clients only, for mixed setups it can result in these issues. I'll add a note to the wiki. If you can't apply IP based selectors to your configuration using left/right, you should consider removing the rightsendcert option. Not sure why the behavior changed between 5.1.3 and 5.2.0 in this regard; likely that it is related to the replaced ipsec.conf parser. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Hi Martin, --On Tuesday, July 15, 2014 01:52:45 PM +0200 Martin Willi mar...@strongswan.org wrote: With this connection active it doesn't matter if I set rightsendcert to ifasked or yes in the default section or the specific connection section of my linux roadwarrior. I can't connect because charon doesn't send a certificate request. If I remove the conn section for win 7 eap, I can connect. Certificate requests are sent very early in the IKE negotiation. As a responder, it is sent in the first IKE_SA_INIT response. At this stage, charon can not reliably select a configuration, as no peer identities or authentication methods are known yet. If no IP address selectors are in place (using left/right), usually just the first matching configuration is used. This probably is the win7 connection in your configuration. ah ok I see I set rightsendcert = never as mentioned in the wiki page While this recommendation is fine if you handle Windows clients only, for mixed setups it can result in these issues. I'll add a note to the wiki. If you can't apply IP based selectors to your configuration using left/right, you should consider removing the rightsendcert option. Not sure why the behavior changed between 5.1.3 and 5.2.0 in this regard; likely that it is related to the replaced ipsec.conf parser. It's probably the new parser. Checking the logs on the gateway running 5.1.3 I discovered that the rightsendcert = never wasn't honoured for any connection. Windows 7 eap clients received a cert request too. So your suggestion to remove this option from our config should be no problem. Thanks Dirk ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Hi Noel,
--On Thursday, July 10, 2014 06:35:40 PM +0200 Noel Kuntze
n...@familie-kuntze.de wrote:
Can you please provide your strongswan.conf?
sure.
Server now back on 5.1.3 is simple using still the single
strongswan.conf:
=
charon {
threads = 16
cisco_unity = yes
send_vendor_id = yes
plugins {
sql {
loglevel = -1
}
attr {
dns = xx.xx.xx.xx, xx.xx.xx.xx
nbns = xx.xx.xx.xx
}
}
libhydra {
plugins {
attr-sql {
database =
sqlite:///etc/ipsec.d/database/strongswandb.sqlite
}
}
}
pluto {
}
libstrongswan {
}
=
I think it's a good time to remove pluto from it.
Client still running 5.2 using the split config:
=
charon {
load_modular = yes
plugins {
include strongswan.d/charon/*.conf
}
}
include strongswan.d/*.conf
aes {
load = yes
}
attr {
load = yes
}
blowfish {
load = yes
}
cmac {
load = yes
}
constraints {
load = yes
}
curl {
load = yes
}
des {
load = yes
}
dnskey {
load = yes
}
fips-prf {
load = yes
}
gmp {
load = yes
}
hmac {
load = yes
}
kernel-netlink {
load = yes
}
md5 {
load = yes
}
nonce {
load = yes
}
ntru {
load = yes
}
openssl {
load = yes
}
pem {
load = yes
}
pgp {
load = yes
}
pkcs12 {
load = yes
}
pkcs1 {
load = yes
}
pkcs7 {
load = yes
}
pkcs8 {
load = yes
}
pubkey {
load = yes
}
random {
load = yes
}
rc2 {
load = yes
}
resolve {
file = /etc/resolve.strongswan
load = yes
resolvconf {
}
}
revocation {
load = yes
}
sha1 {
load = yes
}
sha2 {
load = yes
}
socket-default {
load = yes
}
sshkey {
load = yes
}
stroke {
load = yes
}
updown {
load = yes
}
x509 {
load = yes
}
xcbc {
load = yes
}
charon {
send_vendor_id = yes
crypto_test {
}
host_resolver {
}
leak_detective {
}
processor {
priority_threads {
}
}
tls {
}
x509 {
}
}
charon {
filelog {
}
syslog {
auth {
default = 1
enc = 0
lib = 0
knl = 0
job = 0
}
}
}
pki {
}
scepclient {
}
starter {
}
openac {
}
pki {
}
scepclient {
}
=
Thanks
Dirk
Am 10.07.2014 15:54, schrieb Dirk Hartmann:
Hi,
I hit two problems after upgrading to 5.2.
System on both sides is a Debian wheezy 64. Strongswan compiled with:
[client]
./configure --prefix=/usr --sysconfdir=/etc --enable-blowfish
--enable-curl --enable-openssl --disable-ikev1 --enable-ntru
[gateway]
./configure --prefix=/usr --sysconfdir=/etc --enable-blowfish
--enable-curl --enable-eap-radius --enable-ha --enable-openssl
--enable-xauth-eap --enable-eap-mschapv2 --enable-eap-identity
--enable-sql --enable-attr-sql --enable-sqlite --enable-xauth-noauth
--enable-ntru
1. I get this error on both systems after upgrade:
ipsec_starter[3318]: notifying watcher failed: Broken pipe
2. I had to roll back to 5.1.3 on the gateway because I couldn't
connect from other linux IKEv2 clients which authenticate via X.509
certificates. I got: no trusted RSA public key found for NAME
On the other side IKEv1 connections from Mac/iOS with certificates
and IKEv2 connections from Windows clients with eap-mschapv2 had no
problems. (No Win7 Client with IKEv2 and X509 certificates try to
connect that time)
As the gateway is in productive use I coudn't debug the problem for
long.
I have a second server with the same configuration that I can use to
dig deeper into the problem. What further information would you
need, what debug levels should I use?
All the while the gateway is back on 5.1.3 while my home client is
still on 5.2 and can connect despite the Broken Pipe error.
Best Regards
Dirk
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTvsDcAAoJEDg5KY9j7GZY5NwQAJU4RfQJ763TjqYIGkMOZlzG
sg7U66+Fxwe39pzyr6qL/vrSBMyMDrogc4unvT6N3vfRduK24n7ZOqo+UjcsM62X
gJON8ODTNywIxP08zXm2zWkJwfXqr3H/ApBveVlMyPJ/9pBFe3o7vBoKN+XOJkrY
b8oqhHxOJ0LTu+N03U7GjFLPE/RVVg4LzRrRXQoAISiCo9te0kFjC5Ah3xjwpABz
zMFjt5fnKXN6nVvOboQSO7sAK9EHy0f6IqCQp6LApa809FBDrLvcOLd1Wes3K8L6
PD+PVRQKXtZhx8nBBo4sZAXCSTNDTlrTXfm8aMjzjNyJoqluga/qrj0o7NmsXqx9
wDYmNcSSwpqAiRT9fN8uHuMZK1m51ZD1anDM1+fzMbG33zkqwPKPKWbw8Rm8r1Xg
p8/iHpQqFtAf7lElaCHboUXffz+YDFM/iDTRb0W2XFqe73CWL85gNUvdA1XEAcB+
Re: [strongSwan] Small Problems with 5.2
Dirk, 1. I get this error on both systems after upgrade: ipsec_starter[3318]: notifying watcher failed: Broken pipe Hm, interesting, not sure were this broken pipe could come from, nor do I see this error on my 64bit Wheezy. Can you provide a little more context to this error message? What gets logged before/after this error? What further information would you need, what debug levels should I use? After building strongSwan, can you try to run make check on this system? Do the watcher/stream tests complete successfully? If not, the output of TESTS_VERBOSITY=2 TESTS_SUITES=watcher, stream make check could help in debugging this issue. Best regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Hi Martin, --On Friday, July 11, 2014 09:52:40 AM +0200 Martin Willi mar...@strongswan.org wrote: 1. I get this error on both systems after upgrade: ipsec_starter[3318]: notifying watcher failed: Broken pipe Hm, interesting, not sure were this broken pipe could come from, nor do I see this error on my 64bit Wheezy. Can you provide a little more context to this error message? What gets logged before/after this error? Jul 10 10:31:28 media charon: 00[CFG] loaded crl from '/etc/ipsec.d/crls/crl.pem' Jul 10 10:31:28 media charon: 00[CFG] loading secrets from '/etc/ipsec.secrets' Jul 10 10:31:28 media charon: 00[CFG] loaded RSA private key from '/etc/ipsec.d/private/dhaKey.pem' Jul 10 10:31:28 media charon: 00[CFG] loaded RSA private key from '/etc/ipsec.d/private/dhanetKey.pem' Jul 10 10:31:28 media ipsec_starter[1712]: charon (1713) started after 100 ms Jul 10 10:31:28 media charon: 03[CFG] received stroke: add connection 'dhanet' Jul 10 10:31:28 media charon: 03[CFG] left nor right host is our side, assuming left=local Jul 10 10:31:28 media charon: 03[CFG] loaded certificate MYCERT from 'dhanetCert.pem' Jul 10 10:31:28 media charon: 03[CFG] added configuration 'dhanet' Jul 10 10:31:28 media ipsec_starter[1712]: notifying watcher failed: Broken pipe Jul 10 10:31:28 media charon: 06[CFG] received stroke: initiate 'dhanet' Jul 10 10:31:28 media charon: 06[IKE] initiating IKE_SA dhanet[1] to SERVERIP Jul 10 10:31:28 media charon: 06[NET] sending packet: from LOCALIP[500] to SERVERIP[500] (452 bytes) Jul 10 10:31:28 media ipsec_starter[1712]: notifying watcher failed: Broken pipe Jul 10 10:31:28 media charon: 08[NET] received packet: from SERVERIP[500] to LOCALIP[500] (465 bytes) Jul 10 10:31:28 media charon: 08[IKE] local host is behind NAT, sending keep alives Jul 10 10:31:28 media charon: 08[IKE] received cert request for CACERT Jul 10 10:31:28 media charon: 08[IKE] sending cert request for CACERT Jul 10 10:31:28 media charon: 08[IKE] authentication of 'MYCERT' (myself) with RSA signature successful Debuglevel was: charondebug=cfg 2 ike 2, knl 2, net 2 What further information would you need, what debug levels should I use? After building strongSwan, can you try to run make check on this system? Do the watcher/stream tests complete successfully? yes no problems reported. Passed all 4 'watcher' test cases Passed all 4 'stream' test cases the same on both gateways. If not, the output of TESTS_VERBOSITY=2 TESTS_SUITES=watcher, stream make check could help in debugging this issue. Thanks Dirk pgpFIyQe4FAX0.pgp Description: PGP signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Dirk, Thanks for the update. I could reproduce the issue, it happens when starter forks() to the background. I haven't seen that, as starter logs to a different file here. Due to [1], starter closefrom()s all open file descriptors after the fork. As we now use libstrongswan to manage IPC sockets, this won't work. The file descriptor watcher class uses a pipe() to signal FDSET changes. And the closefrom() just kills our pipe. Not sure what the best approach is to address this, but the closefrom() is definitely not that elegant. The attached patch fixes the issue here. @Tobias: What do you think about reverting [1]? Could we use a less aggressive mechanism to close these FDs for Android? Probably we should go through a libstrongswan deinit/init cycle after/during the fork(), so we don't share the pipe with the parent process. This is a little tricky with leak-detective, though. Regards Martin [1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=652ddf5c From 468b8159ee0b18143706f86ed0a1233b901c9d02 Mon Sep 17 00:00:00 2001 From: Martin Willi mar...@revosec.ch Date: Fri, 11 Jul 2014 14:40:56 +0200 Subject: [PATCH] starter: Do not close all file descriptors after fork() As we use libstrongswan and expect that it still works after the fork, we can't just closefrom() all file descriptors. Watcher, for example, uses a pipe to notify FDSET changes, which must be kept open. --- src/starter/starter.c | 1 - 1 file changed, 1 deletion(-) diff --git a/src/starter/starter.c b/src/starter/starter.c index ef57808..71f33ae 100644 --- a/src/starter/starter.c +++ b/src/starter/starter.c @@ -612,7 +612,6 @@ int main (int argc, char **argv) int fnull; close_log(); -closefrom(3); fnull = open(/dev/null, O_RDWR); if (fnull = 0) -- 1.9.1 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
ipsec_starter[3318]: notifying watcher failed: Broken pipe I got: no trusted RSA public key found for NAME Btw, I don't think these two issues are directly related. While asynchronous IPC operation is affected, starter actually doesn't use that. Probably something else is wrong with that key: trust chain validation, certificate exchange, or loading trusted certificates. Your log might have more details. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Hi Martin, --On Friday, July 11, 2014 02:55:26 PM +0200 Martin Willi mar...@strongswan.org wrote: Thanks for the update. I could reproduce the issue, it happens when starter forks() to the background. I haven't seen that, as starter logs to a different file here. ah yes I use auth.log for all strongswan related lines. Due to [1], starter closefrom()s all open file descriptors after the fork. As we now use libstrongswan to manage IPC sockets, this won't work. The file descriptor watcher class uses a pipe() to signal FDSET changes. And the closefrom() just kills our pipe. Not sure what the best approach is to address this, but the closefrom() is definitely not that elegant. The attached patch fixes the issue here. tested and works. Thank you! Dirk ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
Hi Martin, @Tobias: What do you think about reverting [1]? Could we use a less aggressive mechanism to close these FDs for Android? I guess we could. I don't remember what the problem was exactly, probably that charon was still attached to the shell somehow. Looking at the time stamp, this fix was for Android 2.x, so it's definitely possible that the original issue has since been fixed. Probably we should go through a libstrongswan deinit/init cycle after/during the fork(), so we don't share the pipe with the parent process. Yeah, leaking those FDs to charon isn't optimal. But since we will remove starter sometime in the future, I guess reverting the patch should do it for now. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Small Problems with 5.2
Hi, I hit two problems after upgrading to 5.2. System on both sides is a Debian wheezy 64. Strongswan compiled with: [client] ./configure --prefix=/usr --sysconfdir=/etc --enable-blowfish --enable-curl --enable-openssl --disable-ikev1 --enable-ntru [gateway] ./configure --prefix=/usr --sysconfdir=/etc --enable-blowfish --enable-curl --enable-eap-radius --enable-ha --enable-openssl --enable-xauth-eap --enable-eap-mschapv2 --enable-eap-identity --enable-sql --enable-attr-sql --enable-sqlite --enable-xauth-noauth --enable-ntru 1. I get this error on both systems after upgrade: ipsec_starter[3318]: notifying watcher failed: Broken pipe 2. I had to roll back to 5.1.3 on the gateway because I couldn't connect from other linux IKEv2 clients which authenticate via X.509 certificates. I got: no trusted RSA public key found for NAME On the other side IKEv1 connections from Mac/iOS with certificates and IKEv2 connections from Windows clients with eap-mschapv2 had no problems. (No Win7 Client with IKEv2 and X509 certificates try to connect that time) As the gateway is in productive use I coudn't debug the problem for long. I have a second server with the same configuration that I can use to dig deeper into the problem. What further information would you need, what debug levels should I use? All the while the gateway is back on 5.1.3 while my home client is still on 5.2 and can connect despite the Broken Pipe error. Best Regards Dirk ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Small Problems with 5.2
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Dirk, Can you please provide your strongswan.conf? Regards, Noel Kuntze GPG Key id: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 10.07.2014 15:54, schrieb Dirk Hartmann: Hi, I hit two problems after upgrading to 5.2. System on both sides is a Debian wheezy 64. Strongswan compiled with: [client] ./configure --prefix=/usr --sysconfdir=/etc --enable-blowfish --enable-curl --enable-openssl --disable-ikev1 --enable-ntru [gateway] ./configure --prefix=/usr --sysconfdir=/etc --enable-blowfish --enable-curl --enable-eap-radius --enable-ha --enable-openssl --enable-xauth-eap --enable-eap-mschapv2 --enable-eap-identity --enable-sql --enable-attr-sql --enable-sqlite --enable-xauth-noauth --enable-ntru 1. I get this error on both systems after upgrade: ipsec_starter[3318]: notifying watcher failed: Broken pipe 2. I had to roll back to 5.1.3 on the gateway because I couldn't connect from other linux IKEv2 clients which authenticate via X.509 certificates. I got: no trusted RSA public key found for NAME On the other side IKEv1 connections from Mac/iOS with certificates and IKEv2 connections from Windows clients with eap-mschapv2 had no problems. (No Win7 Client with IKEv2 and X509 certificates try to connect that time) As the gateway is in productive use I coudn't debug the problem for long. I have a second server with the same configuration that I can use to dig deeper into the problem. What further information would you need, what debug levels should I use? All the while the gateway is back on 5.1.3 while my home client is still on 5.2 and can connect despite the Broken Pipe error. Best Regards Dirk ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTvsDcAAoJEDg5KY9j7GZY5NwQAJU4RfQJ763TjqYIGkMOZlzG sg7U66+Fxwe39pzyr6qL/vrSBMyMDrogc4unvT6N3vfRduK24n7ZOqo+UjcsM62X gJON8ODTNywIxP08zXm2zWkJwfXqr3H/ApBveVlMyPJ/9pBFe3o7vBoKN+XOJkrY b8oqhHxOJ0LTu+N03U7GjFLPE/RVVg4LzRrRXQoAISiCo9te0kFjC5Ah3xjwpABz zMFjt5fnKXN6nVvOboQSO7sAK9EHy0f6IqCQp6LApa809FBDrLvcOLd1Wes3K8L6 PD+PVRQKXtZhx8nBBo4sZAXCSTNDTlrTXfm8aMjzjNyJoqluga/qrj0o7NmsXqx9 wDYmNcSSwpqAiRT9fN8uHuMZK1m51ZD1anDM1+fzMbG33zkqwPKPKWbw8Rm8r1Xg p8/iHpQqFtAf7lElaCHboUXffz+YDFM/iDTRb0W2XFqe73CWL85gNUvdA1XEAcB+ hwjcY/1cgWeK9mJzQ2zl1rB7vLP4TD6wtY4EjFvvXRNfx5VO1gwq/m2GI5gEWtS4 MNb3aGtJmrq9ZvztoqwWJ8NEp7Tz1axB14VxwyhEI998R+Hyf9sFcujHW+oPkBis YlTrTXIqacObqcKf3q/gnUCgLK1OdFgp6bOHq+SGulKJ6w6pDXeDJr/GU8Uurjam wC7poreK5XYAjGTnpO6/ =f+Xu -END PGP SIGNATURE- ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
