Re: [strongSwan] Android client supported Cipher Suites? trouble getting aes256 to work
Hmmm, in fact, very strange collection of cipher suites the strongSwan Android client is proposing: received proposals: ESP: AES_CBC_128/AES_CBC_192/AES_CBC_256/ 3DES_CBC/BLOWFISH_CBC_256/ HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/ NO_EXT_SEQ I'm not aware that libipsec would support blowfish_cbc, 3des_cbc, aes_xcbc, and hmac_md5_96 and sha256_128,sha384_192 and sha512_256 are prominently missing. Tobias could you check that? Regards Andreas On 27.09.2012 05:19, Mark M wrote: Hi, I have been trying to get my Android client to work with aes256 with esp=aes256-sha256-aes256 but it would always default to aes128, the default. After looking at the logs for awhile I noticed that the client sends very few proposals and the only one I could get to work is esp=aes256-sha1-modp1024! so for my connection I use ike=aes256-sha256-modp1024! esp=aes256-sha1-modp1024! Is this the best I can for the Android client? Is there a list of supported cipher suites for the Android client?. I am also using this connection for a server 2008/Windows 7 client and noticed that they send different cipher suites as well and had to settle on the ones I posted above for both the Windows client and Android to work at the same time. Mark- == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Linux VPN Solution!www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[ITA-HSR]== smime.p7s Description: S/MIME Cryptographic Signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Android client supported Cipher Suites? trouble getting aes256 to work
Hi Andreas, in fact, very strange collection of cipher suites the strongSwan Android client is proposing: received proposals: ESP: AES_CBC_128/AES_CBC_192/AES_CBC_256/ 3DES_CBC/BLOWFISH_CBC_256/ HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/ NO_EXT_SEQ I'm not aware that libipsec would support blowfish_cbc, 3des_cbc, aes_xcbc, and hmac_md5_96 and sha256_128,sha384_192 and sha512_256 are prominently missing. Tobias could you check that? That's just charon's default ESP proposal (see proposal.c). Because charon currently doesn't know which algorithms the IPsec stack actually supports this is static (unlike the dynamically constructed default IKE proposal). With kernel-pfkey we could theoretically query the kernel for its supported algorithms, libipsec would obviously support it too but kernel-netlink has no interface to do so. But I suppose we could construct a custom proposal for the Android app with the knowledge of what libipsec actually supports (which currently is AES + SHA1/SHA2). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Android client supported Cipher Suites? trouble getting aes256 to work
Hi Tobias, yes I would strongly advocate a specific proposal for Android clients using libipsec, restricted to AES combined with SHA1/SHA2. And we should definitively add HMAC_SHA2_256_128 to our default ESP proposal, putting it in front of AES_XCBC_96 and HMAC_MD5_96. Andreas On 27.09.2012 09:34, Tobias Brunner wrote: Hi Andreas, in fact, very strange collection of cipher suites the strongSwan Android client is proposing: received proposals: ESP: AES_CBC_128/AES_CBC_192/AES_CBC_256/ 3DES_CBC/BLOWFISH_CBC_256/ HMAC_SHA1_96/AES_XCBC_96/HMAC_MD5_96/ NO_EXT_SEQ I'm not aware that libipsec would support blowfish_cbc, 3des_cbc, aes_xcbc, and hmac_md5_96 and sha256_128,sha384_192 and sha512_256 are prominently missing. Tobias could you check that? That's just charon's default ESP proposal (see proposal.c). Because charon currently doesn't know which algorithms the IPsec stack actually supports this is static (unlike the dynamically constructed default IKE proposal). With kernel-pfkey we could theoretically query the kernel for its supported algorithms, libipsec would obviously support it too but kernel-netlink has no interface to do so. But I suppose we could construct a custom proposal for the Android app with the knowledge of what libipsec actually supports (which currently is AES + SHA1/SHA2). Regards, Tobias == Andreas Steffen andreas.stef...@strongswan.org strongSwan - the Linux VPN Solution!www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===[ITA-HSR]== smime.p7s Description: S/MIME Cryptographic Signature ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] 5.0.1rc1 and FreeBSD
Hi David, The first was some simple compile errors which I think I fixed in the attached patch. Thanks, applied to master. On startup I get the following messages: 00[DMN] Starting IKE charon daemon (strongSwan 5.0.1rc1, FreeBSD 9.0-RELEASE-p4, amd64) 00[KNL] unable to set UDP_ENCAP: Invalid argument 00[NET] enabling UDP decapsulation failed This happens when the NAT-T IPv6 socket is opened and the daemon tries to enable UDP en-/decapsulation for that port. Linux supports this for IPv6, FreeBSD apparently not. The patch at [1] improves the error message if this fails. As long as it works for IPv4 (requires the kernel to be built with the IPSEC_NAT_T option) this should be fine. 03[NET] received packet: from 192.168.1.201[500] to 192.168.1.1[500] 03[KNL] 192.168.1.1 is not a local address or the interface is down 03[NET] received packet from 192.168.1.201[500] to 192.168.1.1[500] on ignored interface This is caused by a new check for inbound packets which together with the new options charon.interfaces_ignore and charon.interfaces_use allow one to ignore specific interfaces. Unfortunately, the map used for this check in kernel-pfroute was not properly initialized, see [2] for a patch. Actually, the patch at [3] avoids the check altogether if the above options are not used. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=45178362 [2] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=9845391a [3] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=2e2feffb ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Replay window weirdness with charon
Hi Guru, My primary goal is to disable the replay protection. In strongswan.conf, if I set the replay_window = 0 (or any value = 32), I see the replay window to be stuck at 32 (when seen with setkey -D). You couldn't configure the replay window to be below the default of 32 via strongswan.conf until now (see the patch at [1] for a fix). But, if I set the replay_window with any value = 32, I see the replay window size as 0. That's a limitation of setkey and iproute2 (ip xfrm state), both these commands are not able to read the newer attributes used to configure replay windows larger than 32, which is the largest window supported by the legacy replay protection code in the kernel. They simply print the attribute used to configure that legacy replay window, which has to be zero if the new attributes are used. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=a79af394 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] [Strongswan]expected hash algorithm HASH_SHA1, but found HASH_SHA256 error
Hi,
Whether Certificate signing using SHA256 is supported in Strongswan.
strongSwan can use and verify certificates signed with SHA256, and it
can issue certificates using SHA256 with our pki tool.
src/libcharon/sa/ikev2/authenticators/pubkey_authenticator.c
switch (private-get_type(private))
{
case KEY_RSA:
/* we currently use always SHA1 for signatures,
* TODO: support other hashes depending on configuration/auth */
scheme = SIGN_RSA_EMSA_PKCS1_SHA1;
auth_method = AUTH_RSA;
break;
To sign the data for the IKEv2 AUTH payload, charon currently always
uses SHA1. This is independent from the hash used in certificate
signing. SHA1 is the only mandatory algorithm in IKEv2, and there is no
way to negotiate support for specific hash algorithms. Therefore we
currently use SHA1 only.
I've experimented with a configuration option to define the hash
algorithm [1]. It requires major changes to our public key API, so I
haven't completed this work yet.
Alternatively, I'm considering an option to use the same hash algorithm
as used in the certificate used for signing. But this isn't done yet.
Regards
Martin
[1]http://git.strongswan.org/?p=strongswan.git;a=shortlog;h=refs/heads/sig-hash-cfg
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Cannot do IKEv1/PSK Main Mode in Cisco ASA 5510
I tried doing this a couple of times and did succeed with configuring a StrongSwan client connecting to a Cisco ASA 5510 in IKEv1/PSK Main Mode. What works at present is the IKEv1/PSK Aggressive mode. I am no Cisco expert, so its possible (pointed by endre that it works as well over freenode #strongswan) that I am missing a Cisco ASA config. Any pointers (doc, etc) will be of great help. Thanks,Neeraj ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Cannot do IKEv1/PSK Main Mode in Cisco ASA 5510
I just went through this same problem -- still struggling with routing but seem to habe the connection. What's the Cisco config and you ipsec.conf? Neeraj Sharma kaj...@live.in wrote: I tried doing this a couple of times and did succeed with configuring a StrongSwan client connecting to a Cisco ASA 5510 in IKEv1/PSK Main Mode. What works at present is the IKEv1/PSK Aggressive mode. I am no Cisco expert, so its possible (pointed by endre that it works as well over freenode #strongswan) that I am missing a Cisco ASA config. Any pointers (doc, etc) will be of great help. Thanks,Neeraj ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] [Strongswan]expected hash algorithm HASH_SHA1, but found HASH_SHA256 error
Hi, Please try to keep the discussion on the list. Could you please once again confirm the problem scenario I have pointed in the first mail? Is it because of Certificate corruption or Is it failed, because there is no support in Strongswan? If you are talking about the error: 08[LIB] expected hash algorithm HASH_SHA1, but found HASH_SHA256 It is because your certificate contains an invalid encoding, as I explained in the first answer: Your certificate looks bogus. The certificate itself says (in the X.509 encoding) it is signed by the CA using SHA1, but the PKCS#1 signature contains an OID for SHA256. Because of this inconsistency, the certificate is rejected. Regards Martin ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Issue configuring IPSec routes
We have an issue configuring Strongswan to a Cisco router. The connection is made, but I'm not getting the routing correct. There are multiple networks behind the router on the remote side (operated by a vendor) and we need to snat the IP's we come from to match their assigned range (so it routes back to us). ipsec status shows the connection: 000 vpn: 10.10.0.42/32===12.34.56.78[12.34.56.78]:47/0---12.34.56.80...78.56.34.12[78.56.34.12]:47/0===10.10.254.1/32; erouted; eroute owner: #31 000 vpn: newest ISAKMP SA: #29; newest IPsec SA: #31; 000 000 #31: vpn STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLACE in 2886s; newest IPSEC; eroute owner 000 #31: vpn esp.b3a4e070@78.56.34.12 (0 bytes) esp.6405defd@12.34.56.78 (1872 bytes, 1s ago); tunnel 000 #29: vpn STATE_MAIN_I4 (ISAKMP SA established); EVENT_SA_REPLACE in 81890s; newest ISAKMP 000 ip route show table 220 10.10.254.1 via 12.34.56.80 dev eth1 src 10.10.0.42 We need to get to segments 10.20.1.0, 10.20.5.0 and 10.20.6.0 and appear to come from 10.10.2.2-254 The internal range we have is 10.1.0.0/32 (iptables snat?) Here's the ipsec.conf, I did try multiple segments on the rightsubnet- line, but they never ended up in table 220. I'm not sure I understand how that route interacts with the normal routes. config setup plutodebug=control # plutodebug=all plutostart=yes charondebug=none charonstart=no conn vpn ikelifetime=86400s keylife=3600s rekeymargin=3m keyingtries=1 keyexchange=ikev1 authby=secret ike=3des-md5-modp1024 esp=3des-md5 right=78.56.34.12 rightsubnet=10.10.254.1/32 rightprotoport=47/0 left=%defaultroute leftsourceip=10.10.0.42 leftprotoport=47/0 leftfirewall=yes auto=add pfs=no ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Replay window weirdness with charon
On 27 September 2012 04:04, Tobias Brunner tob...@strongswan.org wrote: Hi Guru, My primary goal is to disable the replay protection. In strongswan.conf, if I set the replay_window = 0 (or any value = 32), I see the replay window to be stuck at 32 (when seen with setkey -D). You couldn't configure the replay window to be below the default of 32 via strongswan.conf until now (see the patch at [1] for a fix). [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=a79af394 Thank you. I have tested this in 4.5.2 and it works (atleast setkey -D, gives the right values for replay_window = 32). I suppose there is no way with popular tools to cross-verify that replay_window is being set fine for values greater than 32 (It is not a use case for me, so doesn't matter). Thanks, Guru ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Kernel crashes with AES-GCM
This probably is not a strongswan issue, as it is the Linux kernel that crashes. But, I felt the wider community may have seen this and have some opinions on how to avoid it. My ipsec.conf summary is as follows: esp=aes128gcm12-modp1024 ike=aes-sha1-modp1024 type=transport When I use the hardware acceleration provided by Intel CPUs (by loading the aesni-intel kernel module), and run netperf tests in a loop on a 10G NIC, I see kernel crashes (I do get a very good throughput boost). I have seen this issue in Linux 3.2, 3.3, 3.4 and 3.5. It is very easy to reproduce in Linux 3.2 (This is the stock kernel that comes with Ubuntu 12.04). Since Ubuntu 12.04 is a very popular distribution, I was surprised to see no prior bug reports on this front. This makes me wonder, whether there are other ways the wider community is making use of the hardware acceleration. Any inputs are deeply appreciated. For those of you interested, here is the actual kernel back traces. http://marc.info/?l=linux-crypto-vgerm=134852306202727w=2 Thanks, Guru ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel crashes with AES-GCM
I can replicate this as well - usually in 2-5 hours with 3.2.23 and 3.4.11, on 82571EB NICs and a E3-1270 CPU. I don't have a full call trace yet (need to set up a serial console first) but the last 25 lines of mine look pretty similar to yours. I'm using tunnel mode, not transport, with aes128gcm16. -Original Message- From: users-bounces+robert.woodcock=cobaltmortgage@lists.strongswan.org [mailto:users-bounces+robert.woodcock=cobaltmortgage@lists.strongswan.org] On Behalf Of Guru Shetty Sent: Thursday, September 27, 2012 9:59 AM To: users@lists.strongswan.org Subject: [strongSwan] Kernel crashes with AES-GCM This probably is not a strongswan issue, as it is the Linux kernel that crashes. But, I felt the wider community may have seen this and have some opinions on how to avoid it. My ipsec.conf summary is as follows: esp=aes128gcm12-modp1024 ike=aes-sha1-modp1024 type=transport When I use the hardware acceleration provided by Intel CPUs (by loading the aesni-intel kernel module), and run netperf tests in a loop on a 10G NIC, I see kernel crashes (I do get a very good throughput boost). I have seen this issue in Linux 3.2, 3.3, 3.4 and 3.5. It is very easy to reproduce in Linux 3.2 (This is the stock kernel that comes with Ubuntu 12.04). Since Ubuntu 12.04 is a very popular distribution, I was surprised to see no prior bug reports on this front. This makes me wonder, whether there are other ways the wider community is making use of the hardware acceleration. Any inputs are deeply appreciated. For those of you interested, here is the actual kernel back traces. http://marc.info/?l=linux-crypto-vgerm=134852306202727w=2 Thanks, Guru ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] 5.0.1rc1 and FreeBSD
Hi Tobias, I am also seeing this UDP_ENCAP error in 5.0.1rc1 on my Red Hat Enterprise Linux 5.6 machine. I did not see it in the 5.0.0 release, so looks like this error is new in 5.0.1 and is happening not only on the FreeBSD: Sep 27 11:44:53 sit-iwf charon: 00[DMN] Starting IKE charon daemon (strongSwan 5.0.1rc1, Linux 2.6.18-238.el5, x86_64) Sep 27 11:44:53 sit-iwf charon: 00[KNL] unable to set UDP_ENCAP: Protocol not available Sep 27 11:44:53 sit-iwf charon: 00[NET] enabling UDP decapsulation failed Thanks! Zhiheng -Original Message- From: users-bounces+zmao=qualcomm@lists.strongswan.org [mailto:users-bounces+zmao=qualcomm@lists.strongswan.org] On Behalf Of Tobias Brunner Sent: Thursday, September 27, 2012 3:51 AM To: David Shane Holden Cc: users@lists.strongswan.org Subject: Re: [strongSwan] 5.0.1rc1 and FreeBSD Hi David, The first was some simple compile errors which I think I fixed in the attached patch. Thanks, applied to master. On startup I get the following messages: 00[DMN] Starting IKE charon daemon (strongSwan 5.0.1rc1, FreeBSD 9.0-RELEASE-p4, amd64) 00[KNL] unable to set UDP_ENCAP: Invalid argument 00[NET] enabling UDP decapsulation failed This happens when the NAT-T IPv6 socket is opened and the daemon tries to enable UDP en-/decapsulation for that port. Linux supports this for IPv6, FreeBSD apparently not. The patch at [1] improves the error message if this fails. As long as it works for IPv4 (requires the kernel to be built with the IPSEC_NAT_T option) this should be fine. 03[NET] received packet: from 192.168.1.201[500] to 192.168.1.1[500] 03[KNL] 192.168.1.1 is not a local address or the interface is down 03[NET] received packet from 192.168.1.201[500] to 192.168.1.1[500] on ignored interface This is caused by a new check for inbound packets which together with the new options charon.interfaces_ignore and charon.interfaces_use allow one to ignore specific interfaces. Unfortunately, the map used for this check in kernel-pfroute was not properly initialized, see [2] for a patch. Actually, the patch at [3] avoids the check altogether if the above options are not used. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=45178362 [2] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=9845391a [3] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=2e2feffb ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel crashes with AES-GCM
On 27 September 2012 11:13, Robert Woodcock robert.woodc...@cobaltmortgage.com wrote: I can replicate this as well - usually in 2-5 hours with 3.2.23 and 3.4.11, on 82571EB NICs and a E3-1270 CPU. I don't have a full call trace yet (need to set up a serial console first) but the last 25 lines of mine look pretty similar to yours. I'm using tunnel mode, not transport, with aes128gcm16. I am glad that I am not the only person seeing this. As a workaround, I am currently running longterm traffic tests with just the aes + hardware acceleration. It does not give as good a performance as aes-gcm+hardware acceleration, but it is better than without hardware help. No crashes yet. PS: If your sole goal is to collect the back trace, you do not need a serial console. You can collect it by booting into a kdump kernel. https://wiki.ubuntu.com/Kernel/CrashdumpRecipe?action=showredirect=KernelTeam%2FCrashdumpRecipe Summary: sudo apt-get install linux-crashdump reboot cat /sys/kernel/kexec_crash_loaded should give 1. echo c | sudo tee /proc/sysrq-trigger - This triggers a crash. - The machine reboots. - In /var/crash, you will have a file like this: linux-image-3.2.0-24-generic.0.crash * mkdir -p /root/temp * apport-unpack /var/crash/linux-image-3.2.0-24-generic.0.crash /root/temp - This will unpack the *.crash and give you a VmCore * Create a new file - /etc/apt/sources.list.d/ddebs.list Add the following content: deb http://ddebs.ubuntu.com precise main restricted universe multiverse deb http://ddebs.ubuntu.com precise-updates main restricted universe multiverse deb http://ddebs.ubuntu.com precise-security main restricted universe multiverse deb http://ddebs.ubuntu.com precise-proposed main restricted universe multiverse - sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 428D7C01 - sudo apt-get update * sudo apt-get install linux-image-$(uname -r)-dbgsym * cd /root/temp (the unpacked .crash exists there) * crash /boot/System.map-3.2.0-24-generic /usr/lib/debug/boot/vmlinux-3.2.0-24-generic VmCore - bt: Will show you the trace. Thanks, Guru -Original Message- From: users-bounces+robert.woodcock=cobaltmortgage@lists.strongswan.org [mailto:users-bounces+robert.woodcock=cobaltmortgage@lists.strongswan.org] On Behalf Of Guru Shetty Sent: Thursday, September 27, 2012 9:59 AM To: users@lists.strongswan.org Subject: [strongSwan] Kernel crashes with AES-GCM This probably is not a strongswan issue, as it is the Linux kernel that crashes. But, I felt the wider community may have seen this and have some opinions on how to avoid it. My ipsec.conf summary is as follows: esp=aes128gcm12-modp1024 ike=aes-sha1-modp1024 type=transport When I use the hardware acceleration provided by Intel CPUs (by loading the aesni-intel kernel module), and run netperf tests in a loop on a 10G NIC, I see kernel crashes (I do get a very good throughput boost). I have seen this issue in Linux 3.2, 3.3, 3.4 and 3.5. It is very easy to reproduce in Linux 3.2 (This is the stock kernel that comes with Ubuntu 12.04). Since Ubuntu 12.04 is a very popular distribution, I was surprised to see no prior bug reports on this front. This makes me wonder, whether there are other ways the wider community is making use of the hardware acceleration. Any inputs are deeply appreciated. For those of you interested, here is the actual kernel back traces. http://marc.info/?l=linux-crypto-vgerm=134852306202727w=2 Thanks, Guru ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
