Re: [strongSwan] Kernel-netlink issue
Hi, 1. I was going through the update SA code, I figured out that the replay data for an SA is fetched separately from the other SA data, however, while adding the updated SA replay value is sent with other entries. What is the reason for this discrepancy. That's due to a limitation of the XFRM API the kernel provides. Unfortunately, the sequence numbers are not included in the response to a XFRM_MSG_GETSA request. These are therefore fetched using a separate XFRM_MSG_GETAE request. On the other hand, the kernel accepts the sequence numbers as part of an XFRM_MSG_NEWSA or XFRM_MSG_UPDSA request. 2. We did not find the query_sa function called from any place in the code, is this function redundtant. It is and it was removed in 4.2.9. 3. Once IKE stack detects that it is behinf NAT, does it still accept packets at port 500. Yes. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Kernel-netlink issue
Hi Vivek, Now in this Scenario when the stack has exhausted the Max. No. of retries and the SA is still not established, How can we make the stack recover. i.e.when the problem is fixed(destination becomes reachable), how can we make the stack to retry SA establishment. You can set 'keyingtries = %forever' for that connection in ipsec.conf then charon will start the initiation anew after it reached the maximum number of retransmissions. This setting is only relevant for the initiation of an IKE SA, though. If you want your connection to stay up, you will also want to activate DPD by adding 'dpdaction = restart' and most likely 'dpddelay = time' to the config. Regards, Tobias -- == Tobias Brunner tob...@strongswan.org strongSwan - the Linux VPN Solution! http://www.strongswan.org == ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Remove all elements from a hashtable_t
Does the hashtable_t+enumerator_t support this mode of operation ?
I think so. The hashtable is based on many linked_lists, and the
remove function from list can handle this.
@Tobias: Please correct me if I'm wrong.
That wouldn't work. For the linked list you also can't just call
remove, but have to call remove_at, otherwise the enumerator's internal
state would get invalid. I've added such a function to the hash table,
see the attached patch (I hope it compiles, did this on a Windows machine).
Or, is there a better way of doing this ?
Our list has handy destroy_offset/destroy_function helpers for cleanup
purposes, but the hashtable is currently missing these functions. So:
No.
We could add such functions to the hash table too, but we would probably
need two parameters, in order to free the keys and the values (since you
could use the same object as key and as value one of these would be
optional).
Alternatively, we could also add a new constructor, which would take two
new function parameters to free the keys and the values. If they were
set, destroy/remove/remove_at would automatically free the memory of the
key and value. We could then also easily add a remove_all method to
clear the whole hash table.
If all else fails, it may be better to free all the memory that the
elements point to and to then destroy the hashtable_t and create a
new one.
Might be a little more efficient for large tables (?), but shouldn't
really matter.
It probably depends on how often you have to clear the whole hash table,
how large it gets and how fast it grows. If it grows fast to about the
same significant size, it might be better to remove all elements to
avoid the hash table getting resized all the time (you can avoid this if
you set the initial capacity to an appropriate value).
Regards,
Tobias
From 3339a7e974eaa581678d3e57f1cc9c94924acecd Mon Sep 17 00:00:00 2001
From: Tobias Brunner tob...@strongswan.org
Date: Sat, 5 Jun 2010 09:50:07 +0200
Subject: [PATCH] Adding a remove_at method to the hash table in order to remove
items while enumerating them.
---
src/libstrongswan/utils/hashtable.c | 33 -
src/libstrongswan/utils/hashtable.h |7 +++
2 files changed, 35 insertions(+), 5 deletions(-)
diff --git a/src/libstrongswan/utils/hashtable.c
b/src/libstrongswan/utils/hashtable.c
index 02c2258..1813d42 100644
--- a/src/libstrongswan/utils/hashtable.c
+++ b/src/libstrongswan/utils/hashtable.c
@@ -127,6 +127,11 @@ struct private_enumerator_t {
u_int row;
/**
+* current pair
+*/
+ pair_t *pair;
+
+ /**
* enumerator for the current row
*/
enumerator_t *current;
@@ -318,6 +323,25 @@ static void *remove_(private_hashtable_t *this, void *key)
}
/**
+ * Implementation of hashtable_t.remove_at
+ */
+static void remove_at(private_hashtable_t *this,
+ private_enumerator_t *enumerator)
+{
+ if (enumerator-current)
+ {
+ linked_list_t *list;
+ list = this-table-table[enumerator-row];
+ if (list)
+ {
+ list-remove_at(list, enumerator-current);
+ free(enumerator-pair);
+ this-count--;
+ }
+ }
+}
+
+/**
* Implementation of hashtable_t.get_count
*/
static u_int get_count(private_hashtable_t *this)
@@ -334,17 +358,15 @@ static bool enumerate(private_enumerator_t *this, void
**key, void **value)
{
if (this-current)
{
- pair_t *pair;
-
- if (this-current-enumerate(this-current, pair))
+ if (this-current-enumerate(this-current,
this-pair))
{
if (key)
{
- *key = pair-key;
+ *key = this-pair-key;
}
if (value)
{
- *value = pair-value;
+ *value = this-pair-value;
}
return TRUE;
}
@@ -426,6 +448,7 @@ hashtable_t *hashtable_create(hashtable_hash_t hash,
hashtable_equals_t equals,
this-public.put = (void*(*)(hashtable_t*,void*,void*))put;
this-public.get = (void*(*)(hashtable_t*,void*))get;
this-public.remove = (void*(*)(hashtable_t*,void*))remove_;
+ this-public.remove_at = (void(*)(hashtable_t*,enumerator_t*))remove_at;
this-public.get_count = (u_int(*)(hashtable_t*))get_count;
this-public.create_enumerator =
(enumerator_t*(*)(hashtable_t*))create_enumerator;
this-public.destroy = (void(*)(hashtable_t*))destroy;
diff --git a/src
Re: [strongSwan] Remove all elements from a hashtable_t
Hi Graham, If I get a chance, I'll try out your patch, this may take some weeks to getting around to though. Unfortunately, the patch contained a small bug. But I commited a proper version to master on Monday (see [1]). Regards, Tobias [1]http://git.strongswan.org/?p=strongswan.git;a=commit;h=b2ddaf07755176eab43bc8c58aa632eb915f4786 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Trouble compiling StrongSWAN 4.4.0 on FreeBSD 8.1-PRERELEASE on amd64
Hi Holger, I've read the instructions at http://wiki.strongswan.org/projects/strongswan/wiki/FreeBSD As you've probably seen, this currently covers only FreeBSD 7.x and its NAT-T patches. With the inclusion of NAT-T in FreeBSD 8 some details have changed. For instance, the SADB_X_NAT_T_NEW_MAPPING event is not supported: kernel_pfkey_ipsec.c:1141: error: 'SADB_X_NAT_T_NEW_MAPPING' undeclared (first use in this function) I've commited a patch for this to master (see [1]). Then there is a problem with the handling of ports when NAT-T is actually used, which is resolved with another patch (see [2]). Nevertheless, I still had to add #include stdint.h to src/libcharon/config/child_cfg.c in order to proceed further, since UINT64_MAX wasn't declared. Thanks, fixed in [3]. If you find anything else, let me know. Regards, Tobias [1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=ed76b21652a46ead384ba2b372d40395de8bae82 [2]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=668e84d904e9cacc4ef18b478f843312357a3721 [3]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=4e9d313ff81f7d6bc2f001772d96c7d2eb8e510d ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] non-zero reserved fields in IKE_AUTH response.
Hi Richard, from the log it looks like the ID is parsed incorrectly (you could increase the loglevel to see the details): 09[AUD] authentication of '2001:db8:f:1::1f5c57111eaff84b7' with pre-shared key failed The reason for this could be an alignment issue in the parser that has been fixed in [1] (4.3.1 was the first release to contain that fix). Since you are running 4.1.10 on an embedded platform, there might well be other alignment issues that have since been fixed, so please be aware. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=42748858 -- == Tobias Brunner tob...@strongswan.org strongSwan - The Linux VPN Solution! http://www.strongswan.org == ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] non-zero reserved fields in IKE_AUTH response.
If we change the reserved fields to to zero for the same given test-case it works fine. Would it then be a parse issue? It could be (the zeroed fields then not affecting the result). It would really help if you could add enc 3 to charondebug in ipsec.conf and rerun the failing test. That would show us how exactly the ID payload is parsed. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] non-zero reserved fields in IKE_AUTH response.
Hi Richard, The trace file is below. Thanks, but the file seems to be incomplete (e.g. no chunk contents are listed, IKE_AUTH is never mentioned etc.). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] non-zero reserved fields in IKE_AUTH response.
Hi Richard, I found the reason for this failure. The only thing from the IKE_AUTH request, that affects the computation of the AUTH value is the ID as in prf(Sk_px, IDx'). Now I somehow assumed IDx' is just the Identification Data of the IDx payload, but it's not, IDx' is actually IDType | RESERVED | IDData. The problem is that in build_tbs_octets ([1]) IDx' is built from the identification_t object, it's not based on the actually received payload and there it is assumed that RESERVED is zero. Fixing this properly would probably need quite some changes, I have to discuss that with Martin first. To verify it you can set the three reserved bytes in build_tbs_octets to the value sent by the initiator. Regards, Tobias [1] src/charon/sa/authenticators/psk_authenticator.c ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] SIGILL in 4.3.5 and above
Looks suspicious: +return rekey - jitter * (random() / (RAND_MAX + 1.0)); @Tobias: What's the idea behind RAND_MAX + 1.0? Might this end in a division by zero? random() / (RAND_MAX + 1.0) returns a random floating point number in the range [0, 1). The value of RAND_MAX depends on the C library and in glibc it's 0x7fff. Which shouldn't overflow a double-precision floating point number (in what RAND_MAX + 1.0 implicitly should result). As Martin recommended, using a debugger is probably be the fastest way to find the cause for this SIGILL. If you can't use a debugger, it would help to know in what situations the SIGILL actually occurs (i.e. config, log). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] SIGILL in 4.3.5 and above
I am unable to find what __fixunsdfdi is. child_cfg.c is indeed the line mentioned above. Anyone who has any ideas? __fixunsdfdi is a GCC-internal function which converts a double to an uint64. It seems that an instruction in that function raises the SIGILL on your platform. This suggests that it's actually a GCC bug. What version of GCC do you use? Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ANNOUNCE: strongswan-4.4.1 released
Hi Holger, are the patches needed for FreeBSD 8.1 support also integrated? Yes. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] [RFC][PATCH] set negotiated traffic selectors in SAs for transport mode
Hi Jiri, Currently, negotiated traffic selectors are only applied on SPs. Certain situations require them in SAs as well. Example (taken from a previously failig ipv6ready IKEv2.EN.I.1.1.7.1 test case): ... This patch makes strongSwan set the negotiated TSs the SAs it creates. ... Does this look like the right thing to do? Why was this ever limited to the BEET mode? Shouldn't the same thing be done for TUNNEL mode as well? Actually, in your example (and probably in all similar narrowing cases) the real problem is not that the traffic selectors are only applied to the policies, but that the same reqid is used for both policies. So what happens is that although the traffic selectors are correctly narrowed and installed, the IPsec SA and the new policy use the same reqid as the initial trap policy (which stays installed). So any traffic that matches the trap policy is now also handled by the IPsec SA (due to the reqid). Your patch does indeed fix the problem for this case, because the IPsec SA now no longer matches the packet that matched the trap policy, but I'm not sure whether that's the right way to go. The behavior in this test case is strange anyway, because when testing it, I get a new IPsec SA (all with the same reqid) for each packet that matches the trap policy but does not match the narrowed TS. Anyway, thanks for the patch and for bringing this issue to our attention, we will sure have a look into it. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ipsec_starter strikes charon for pluto's misdeeds
Hi Jan, #config setup #nothing here Just define config setup plutostart=no and you should be fine. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan 4.4.0 - routing problem from local system - possible PLUTO_NEXT_HOP wrong
Hi Danny, But why is PLUTO_NEXT_HOP not the leftnexthop=xx.xx.xx.xx or leftnexthop=%defaultroute from my config? Unfortunately, the left-/rightnexthop options were broken since 4.4.0. I pushed a fix for it to master (see [1]). Regards, Tobias [1]http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=ddc961c369 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] FW: Is that a security Issue?
Hi Michalle, there will be a plain text of ICMP echo request (which decrypyt the orignial ESP packet from my implementation) in the network. You didn't write on which host you captured the packets with Wireshark. If it was on the same host on which strongSwan was running then this behavior is normal. It is a quirk of the Linux kernel that for incoming traffic both the ESP packet and the decrypted payload are captured and that for outgoing traffic only encrypted ESP packets are visible. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] FW: Is that a security Issue?
Hi Michalle, I have other question about this. Why it only happens when the ESP protects a Tunnel mode IP traffic. I have never seen that plain text under the transport model. Yes, this only happens with tunnel mode. I don't know the exact reason for it, it's probably just a side effect of how tunnel mode is implemented in the kernel. And also does that means the the Linux Kernal knows the SA Key which established between Strongswan and my implementation, otherwise how it could decrypt the ESP packet. That's exactly how it works. All the IPsec traffic (ESP/AH) is directly handled by the Linux kernel. strongSwan just acts as a keying daemon that operates in userland and writes the keys it establishes via IKE to the Linux kernel using Netlink/XFRM or PF_KEY. To see the SAs and keys that are currently configured in the kernel you can also use the 'ip xfrm state' command. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Setting of NATTKeepaliveTimer and IPsecWindowSize.
Hi Jessie, the keep-alive interval can actually be configured, although, not on a per-connection basis, by setting the charon.keep_alive option in strongswan.conf. Regarding the IPsecWindowSize option, keep in mind that the maximum window size currently supported by the Linux kernel is 32, which is what strongSwan configures, by default. As for adding options to ipsec.conf, you would have to change quite a lot of code. First there is the parsing in starter, then you would have to add the options to stroke and to one of the config objects in libcharon and then finally use them wherever appropriate, which would probably require additional changes (e.g. additional parameters in the kernel interface). Therefore, for daemon wide options it's a lot easier to just add them to strongswan.conf, which basically means you read the options wherever you actually need them. As an example, you can see how charon.keep_alive is read and used in src/libcharon/sa/ike_sa.c. Regards, Tobias Jessie Liu wrote: Hi all, I'd like to add setting the two parameters NATTKeepaliveTimer and IPsecWindowSize in ipsec.conf. Which section should I add the two parameters, such as conn part of ipsec.conf ? I want to modify source codes to fit the configurations, but I have no idea which section I should add. The two parameters could be different with each connection? Thanks very much. B.R. Jessie ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] About the IPsec rekey lifetime calculation
Hi David, I added some notes to our wiki about the lifetime/rekeytime calculation: http://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey Regards, Tobias David Deng wrote: Hi All, When I Initiated some testing about the IPsec rekey mechanism, and I found the rekey lifetime seems like a randam number (according to the fuzz setting) and I am so puzzled. I am wonder that if the following calculation method of IPsec rekey lifetime is right: IPsec rekey lifetime = lifetime - (1 + fuzz%) * margin for example: if lifetime was set as 9m, and fuzz was set as 50, and margin was set as 2, and then the IPsec rekey lifetime will be calculated as: 9 - (1+0.5)*2 = 6m so the IPsec rekey lifetime will be in the scope of 5 ~ 7 m is it right? look forward to your answer! thanks a lot! Besides, I found that the IPsec rekey lifetime still is a random value even if the above function existed. so I have no any idea about the IPsec rekey lifetime. can you explain how IPsec rekey mechanism work? thanks again! Best wishes David Morris ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] eap-mschapv2 NetworkManager
Hi Peter, Is there also an workaround for the strongSwan NetworkManager plugin? There is no need for that, as the NetworkManager indirectly uses charon, fixing charon fixes the NM plugin. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] No known IPsec stacks found on Freebsd 8.1
Yatong Cui wrote: Yet I cannot start the daemon because the system cannot identify any IPsec stack. That's not really a problem, the detection code is Linux specific and not actually executed by the daemon, but by a wrapper tool called starter. The daemon charon (with the proper plugin loaded) should be able to communicate with the kernel, just fine. The actual problem you seem to have is that starter and charon are either already running or have crashed and the pid files are still lying around: charon is already running (/var/run/charon.pid exists) -- skipping charon start starter is already running (/var/run/starter.pid exists) -- no fork done Check that they are not running and then delete these pid files and try to start them again with ipsec start. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] [RFC][PATCH] set negotiated traffic selectors in SAs for transport mode
Hi Richard, Hi Tobias, was this ever included in strongswan. We are failing this test while undergoing USGv6 certification testing and would like to be able to have a fix. No, it has not yet been applied. The patch still fixes this particular test case, so you may try applying it. But we still have no fix for the underlying problem and the patch does not translate well to tunnel mode as only one selector can be configured per installed SA in the kernel. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] IKEv1 connection issues after upgrading from 4.4.1 to 4.5.0
Hi Benoit, Hi Andreas, as Benoit already confirmed, this problem is related to using the kernel-pfkey plugin in combination with pluto. I tried to reproduce the behavior using Benoit's config and I was able to do so with the PF_KEY interface, but not with the Netlink interface. Some debugging showed that the problem is a limit set in ipsec.h and consequentially used in af_key in the kernel, which defines 0x3fff (16383) as the upper limit (IPSEC_MANUAL_REQID_MAX) for the reqids that can be specified by user-land tools. If the supplied reqid exceeds this value the kernel starts generating them itself. Subsequently, the installed policies don't match the installed SAs anymore (because there, the reqids are not changed). Hence, acquires are triggered for packets that match any installed policies. Now the fun part is that pluto actually bases its generated reqids on the above limit, so the first one generated is 14384 (followed by 14388, because an offset of 4 was required in the old kernel interface and I missed to changed that). Starting at IPSEC_MANUAL_REQID_MAX probably made sense in the early days, when people wanted to configure some SAs manually. And because charon starts generating reqids with 1 it also prevented any conflicts between the two daemons. But this difference between the two daemons also meant that I never came across this limitation of the kernel's PF_KEY interface while testing it with charon. In my opinion the check in the kernel is rather bogus, as it has no means to decide whether the SADB_X_SPDADD is sent by a keying daemon or a tool like setkey. To fix this, I propose to modify pluto so that it generates reqids from the range [0x1fff, 0x3fff] (incrementing them by 1 instead of 4). This would avoid the problem with the PF_KEY interface and would still largely avoid conflicts with charon (at least as long as charon has fewer than 8191 connections). But then again, using the kernel-netlink plugin avoids this problem altogether, so there is probably no change needed at all. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] routing issue with IKEv1 tunnels after upgrade to 4.5.0
Hi Benoit, If defaultTunnel is established first and t1 second, the strongSwan server receives the traffic from the tunnel t1 but doesn't send back packets through it. The traffic seems to always be routed to the tunnel defaultTunnel. If t1 is established first and defaultTunnel second, it works. Any ideas why this doesn't work anymore after upgrading? Is there a way to ensure this always work regardless of the connection establishment order? The observed behavior is due to a difference between pluto's 4.4.1 kernel interface and charon's kernel interface plugins which pluto uses in 4.5.0. The difference is the calculation of the priorities assigned to policies installed in the kernel. Whereas pluto did include the netmask of the destination net in this calculation, charon did not so far. Thus, the priorities of the policies installed in your case are equal and the kernel obviously chooses the one installed first. I commited a patch to master [1] which changes the kernel interfaces to include the destination net into the priority calculation. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=e6f42b07 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] ANNOUNCE: strongSwan packages for Maemo (Nokia N900)
Hello, despite the recent news about Nokia's plans to partner with Microsoft, we are happy to announce that packages for strongSwan 4.5.1 are now available in the maemo.org Extras repository, which provides software for Maemo based devices such as the Nokia N900. Package: strongswan-applet [1] -- This package provides a settings applet and a status bar widget which allow to easily configure and control IKEv2 connections with EAP authentication (username/password). Package: strongswan [2] --- This package contains the key exchange daemons, starter and the ipsec script for use on the mobile device. To configure strongSwan via /etc/ipsec.conf the 'rootsh' package is required to gain root access. You'll find more information about both packages on our wiki [3]. Because strongSwan depends on the native IPsec implementation of the Linux kernel, the enhanced 'Kernel Power' [4] kernel is required, which provides the required modules disabled in the default kernel. Both packages are currently available in the Extras-testing [5] repository. So, in order for them to become available in the main Extras repository, we'd like to invite fellow Nokia N900 owners to test the two packages and vote for them accordingly on the respective maemo.org pages ([1], [2]). Thanks in advance! Best regards Tobias Brunner, Martin Willi Andreas Steffen The strongSwan Team [1]http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/strongswan-applet/1.0.1-2/ [2]http://maemo.org/packages/package_instance/view/fremantle_extras-testing_free_armel/strongswan/4.5.1-1/ [3]http://wiki.strongswan.org/projects/strongswan/wiki/Maemo [4]http://wiki.maemo.org/Kernel_Power [5]http://wiki.maemo.org/Extras-testing -- == Tobias Brunner tob...@strongswan.org strongSwan - The Linux VPN Solution! http://www.strongswan.org == ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Deleting connections
Hi Mike, The crash is in thread 08 in the DBG2 processing below, because the thread's ike_sa value is set to the now-deleted ike_sa_t. That's exactly what happened. The problem is that the IKE_SA is checked out by one thread and then checked in by another, thus the thread local IKE_SA is not reset in the thread that checked it out. I pushed a patch to master that should fix it (see [1]). Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=dcab9d39 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan on android
Hi Antoine, PS:The custom kernel is not yet built because I have planned to it after compiling the entire android sources including strongswan. It should normally won't be disturbing? No, you can build that later without problem. external/strongswan-4.5.1/src/libstrongswan/settings.c:23:18: error: glob.h: No such file or directory ... The compiler doesn't find the glob.h file. Indeed this file is part of the glibc library of my linux host system but is not present in the libc for android, provided in DROID_ROOT/bionic. Android seems to have a partial support of the glibc. With 4.5.1 we introduced the include keyword for strongswan.conf, which allows to use file patterns (e.g. include /etc/ipsec.d/*.conf). Resolving such patterns uses the glob function declared in glob.h. Which as you saw is not provided by the C library on Android. This issue has already been reported last week [1], and I will push a fix for it as soon as possible. Regards, Tobias [1] http://wiki.strongswan.org/issues/125 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strong swan doesn't compile - Froyo
Hi Avinash, target SharedLib: libcharon (out/target/product/generic/obj/SHARED_LIBRARIES/libcharon_intermediates/LINKED/libcharon.so) out/target/product/generic/obj/SHARED_LIBRARIES/libcharon_intermediates/daemon.o: In function `daemon_create': /root/bin/newfroyo/external/strongswan-4.5.1/src/libcharon/daemon.c:288: undefined reference to `sim_manager_create' Could you try it with the latest Developer Release from [1]. I think in 4.5.1 the file lists in the Android.mk files were not up-to-date. Regards, Tobias [2] http://www.strongswan.org/download.html ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] multiple ipsec tunnels (multiple ipsec/esp SAs between 2 peer gws with 1 IKE SA)
Hi Rajiv, - is there a better way and a simple and elegant way to simulate 1000 tunnels (2000 SAs)? Did you already have a look at the load-tester plugin [1]? Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/LoadTests ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] regarding reauthenticating IKE_SA due to address change
Hi Ujjal, 1) Is reauth=no has any effect or i am doing some wrong configuration The reauth option allows to configure whether an IKE_SA is rekeyed or reauthenticated once it is about to expire (ikelifetime/margintime). It has no effect on other circumstances where a reauthentication might be required. 3) why the reauthentication is happening for the virtual ip address not for the actual ip address configured . The IKEv2 daemon charon listens for any address or route changes reported by the kernel. If any occur the MOBIKE/roaming process is started. Now in your situation two things seem to happen. First, charon thinks the current path to the other peer is not available anymore. Charon checks this with a route lookup (similar to 'ip route get x.x.x.x' where x.x.x.x is the address of the peer) and then compares the returned source address with the one currently used for the IKE_SA. If it is equal not much more is done, otherwise charon tries to find a new path using MOBIKE. Which brings me to the second observation, you seem to either have disabled MOBIKE (mobike=no) or your peer does not support it. Due to this charon, as a last resort, tries to reauthenticate the IKE_SA (i.e. tear it down and set it up anew) in order to find a new path to the peer. Please not that before 4.5.0 the mentioned route lookup sometimes did not return an IP address even if there was a route available. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Problem About Dscp Support in scenario of end to end tunnel
Hi David, iptables -t mangle -A OUTPUT -p icmp -j DSCP --set-dscp 10 iptables -t mangle -A OUTPUT -p icmp -m dscp --dscp 10 -j MARK --set-mark 10 If you add these rules on both sides. Then you also have to specify mark=10 in both configs. You seem to have done so on the gateway but not on the client. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Help, charon: 03[CFG] issuer of fetched CRL does not match CRL issuer
Hi, Jul 23 12:41:28 lag3 charon: 03[CFG] issuer of fetched CRL 'C=US, ST=CO, L=Denver, O=igvpn.com, CN=igvpn.com CA, E=i...@igvpn.com' does not match CRL issuer '9b:00:ad:ef:3d:af:74:3b:72:6e:28:33:f5:33:4a:6a:e8:77:2e:bb' It seems your CA certificate contains the X509v3 Subject Key Identifier extension which in turn means your CRL has to contain the X509v3 Authority Key Identifier extension. Otherwise charon won't be able to match the two. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] MOBIKE
Hi Patricia, I've tested strongswan-4.5.3rc2 and I still get the same behaviour. I'm testing MOBIKE by sending CBR traffic from the initiator at a rate of 45Kbps. When I deactivate eth0 I obtain the behavior that you can see on one.png. Then, I activate eth0 again and deactivate eth1 and I obtain the behaviour showed in two.png (nothing strange). Ah, the problem here is not exactly what I described previously and not quite what the patch fixes. The problem in this situation is that the original IPsec SA covers packets between 163.117.141.82 and 163.117.141.81. Now, when 163.117.141.82 goes down, there is simply no IPsec SA yet which covers eth1's 163.117.14.33. MOBIKE has first to determine this as a valid path and then update the SA appropriately. The submitted patch basically fixes this last update step. So how do you fix it? Well, you have to make sure that 'left' (the IP address that might change) is not part of the local traffic selector. To do so I'd recommend you assign your client a virtual IP address. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] MOBIKE
Hi Patricia, I've test also with virtual IP's and I obtain the same behaviour :( Ah, yes. The source route installed by charon only covers eth0 and its default gateway. Andreas, Martin, any ideas? Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] MOBIKE
iptables -A INPUT -m policy --dir in --pol ipsec --proto esp -j ACCEPT iptables -A OUTPUT -m policy --dir out --pol ipsec --proto esp -j ACCEPT Thus no plaintext packets should leave the VPN endpoint. That's probably the best solution for now. The problem with the virtual IP approach is that the route has to be changed to the new interface, even when the IP is bound to a dummy interface. And there we currently have the same delete/add race condition we had with the policies. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] regarding reauthenticating IKE_SA due to address change
Hi Ujial, Interface eth1 ipaddress is given as : 10.29.11.66 /16 and the viratual ip address 10.29.11.67/16 http://10.29.11.67/16 . The tunnels as follows 1)10.29.11.66--10.29.11.36 2)10.29.11.67--10.29.11.36 This looks like you have setup two IKE_SAs. One from each IP address. When charon does perform a route lookup this will cause the observed problem for the second SA as its source IP will not match the address returned from the lookup. Now, why don't you setup just one IKE_SA and two CHILD_SAs on top of that? Something like: conn %default right=10.29.11.36 ... other shared options conn child-one leftsubnet=10.29.11.66/32 auto=add conn child-two leftsubnet=10.29.11.67/32 auto=add The config on the other peer (10.29.11.36) has to match these (e.g. rightsubnet=10.29.11.64/29 or with two separate configs as above). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] MOBIKE
Hi Patricia, Can this packet be tunneled at that point? are initiator and responder updating the SAs after the liveness test? I think this packet should not be received through the tunnel until the handover process ends. Is the return routability check activated by default? by who? In the current implementation charon as the initiator of a MOBIKE exchange updates the IPsec SAs right after it determined a working address pair. At the same time, it sends the address update which also includes a COOKIE2 payload, thus, is acting as routability check. The responder only updates the addresses of the IPsec SAs after receiving an address update. Since the observed ESP packet and the address update do not necessarily have to arrive in that order, it could very well be that the other peer successfully receives the ESP packet. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongSwan on Maemo (Nokia N900)
Hi Peter, Martin, [IKE] unable to allocate SPIs from kernel Unfortunately, the stock N900 kernel does not support the required IPsec modules. You'll have to install the kernel-power [1] package. It seems that such a hint is missing on our wiki page, I'll fix that. Hm, that's strange since the Maemo strongswan package actually has a dependency on kernel-power (= 2.6.28-maemo42). Peter, did you restart your device after installing the packages? Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Charon doesn't set the routes
Hi Diego, I forgot to clarify that route is inserted if compress=no. In kernel_netlink_ipsec.c add_policy methed, the code checks if mode != MODE_TRANSPORT to insert to route. Yes, if IPComp is enabled the actual IPsec SA uses transport mode in the kernel as the inner IPComp SA does the tunneling. Up to 4.4.1 charon did this slightly wrong because the mode is changed while installing the policy and later when installing the route and checking the mode it's not the original mode that is compared. Please update to at least 4.5.0 to fix this. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan on android gingerbread
Hi Federico, The problem comes when I try to patch the VPN frontend as written here: http://wiki.strongswan.org/projects/strongswan/wiki/AndroidFrontend. Did the patches apply cleanly? Look for .rej files. The android source doesn’t compile anymore. I suspect it is because I am using Gingerbread instead of Froyo maybe? Probably, the patch was initially created for 1.6 and then ported to Froyo which also needed some tweaking. So it's reasonable to assume that there will be stuff that does not work properly on Gingerbread. I get the following errors that have to do with this strings.xml file (the actual list of errors is much longer, but they are all of the same type of these): frameworks/base/core/res/res/values/strings.xml:2458: Originally defined here. frameworks/base/core/res/res/values/strings.xml.orig:2461: error: You get these errors because patch created a copy of the original unpatched file as strings.xml.orig. Since both files define the same strings and the build system seems to include all files in res/values (not just *.xml) you get the observed errors. Patch will do this if called with the -b option or if a patch did not apply cleanly. In the latter case you should also see a strings.xml.rej file containing the failed hunk. If so, you should be able to easily fix it as the patch for strings.xml contains just one added line (be sure to delete the files created by patch). Also, in practice, is the frontend patch only for usability? In other words, if there is no fix to my problem, is it actually possible to use strongswan without the frontend patch? And if so, how? That depends on what you intend to do. Currently only charon (the IKEv2 daemon) and the newer libraries are built with the provided Android.mk files, so there is no pluto (IKEv1 daemon) or starter. Without starter you won't be able to use ipsec.conf to configure the daemon. Also, the ipsec script and stroke are not built so interaction with the daemon is not directly possible (the frontend uses charon's android plugin for this). What you could do is build your own plugin with your own config backend (e.g. using an sqlite database, although the sql plugin could probably also be used for that) and your own frontend to control the daemon. You could also try to build the stroke plugin and then use the stroke socket to control the daemon. We also know that there are currently some people working on getting starter and pluto running on Android, but they are not yet there. Anyway, the frontend patch should be considered as a proof of concept. It simply adds an additional type of VPN to the default Android VPN applet, which allows to easily setup IKEv2 connections but is fairly limited at that. For instance, the only authentication methods currently supported are EAP methods with username/password authentication (e.g. eap-mschapv2 or eap-md5). Also, there are basically only two configuration options, the IP/hostname of the gateway and the CA certificate (read from the Android KeyStore). Other options are predefined for usage in road-warrrior scenarios (e.g. a virtual IP is requested from the gateway and the the proposed traffic selector is simply VirtualIP/32 === 0.0.0.0/0). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan on android gingerbread
Hi Federico, I still get some .orig files after patching although no .rej file is produced and no error messages are given when I patch. Perhaps patch is aliased to 'patch -b' on your system (check with 'alias' in a console window). Problem is that it looks like when I try to use the VPN, charon doesn't start. Did you apply all the patches? Please have a look the the init.rc file in system/core/rootdir in the Android sources. There you should have a service entry for charon. Also make sure charon does actually run. Just connect to the emulator via 'adb shell' and execute charon. We are planning to use IPsec on a IPv6 network. Does the StrongSwan IKEv2 port for android fully support IPv6, or only IPv4? It should (although I did not test it) if the corresponding modules are activated in the kernel (see [1]). Unfortunately, I have to amend this statement. It looks like strongSwan currently does not support IPv6 on Android because there seems to be no way to get and set the local IP address when sending/receiving packets over an IPv6 UDP socket. At least struct in6_pktinfo is not defined in Android's header files, not sure if that's intentional or not (strangely IPV6_PKTINFO and IPV6_RECVPKTINFO are defined). It might work if we define that struct ourselves, as the kernel is supposed to understand it anyway... Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan on android gingerbread
What does not seem to be there instead is the charon service itself. When I went in the adb shell and tried to start it, I got an error, and noticed that in /system/bin/ of the running emulator, there is no charon command at all.which would explain a lot. What can be the cause? Is it supposed to be there by default or is it enabled by some of the patches, or as a module of the kernel? Charon is built by the Android.mk files included in the strongSwan source tree. Follow the instructions at [1], the last section explains how to get strongSwan built within the Android source tree. Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/Android ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan on android gingerbread
Now I don't understand why I should build a tarball just to extract it again Yes, that's strange, isn't it ;-) The reason for this is that building the tarball also creates several generated files, which cannot be done that easily directly inside the Android build system. These files are generated by bison/flex, gperf and some contain variables replaced with sed (the top Android.mk for instance). Anyway, you can actually do this without explicitly building a tarball, right within the strongSwan source tree. Please run the following commands: ./autogen.sh ./configure make make distclean This result in a tree similar to an unpacked tarball. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan on android gingerbread
But what about just copying the android.mk file from the source tree inside the folder I get from extracting the strongswan-4.2.9-stable-4853.tar.bz2 file instead? Would that work? No, not really. There were quite a lot changes needed to make strongSwan run on Android. Now, strongSwan 4.2.9 is nearly three years old and building strongSwan with Android.mk has not been supported until 4.4.0, which we released about 1.5 years ago. Is there any reason you want to use 4.2.9 specifically and not a current version? Also, there have been several Android-specific changes in the last few weeks so I'd actually recommend you use 4.6.0 which we intend to release in a few weeks (i.e. use the current master branch via git for now). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan on android gingerbread
Hi Federico, What else could it be? (just as a note I have note enabled anything extra with the cryptographic API modules. ) It could very well be a problem with the algorithms. Which algorithms are negotiated between the two hosts? Did you configure anything special on the responder? Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Pluto is adding a second ip rule
Hi Elmar, I thought, this happens in the _updown-Script It did but this is now done by the kernel-netlink plugin (see [1]). Pluto still installs the source routes with the _updown script, though. Now, the kernel-netlink plugin doesn't check if the rule already exists and just installs it anyway. In 4.6.0 it actually gets installed up to three times since the kernel-netlink plugin is now loaded by starter, pluto and charon. If none of these crashes they also get removed afterwards. I'm not sure if that's a problem, the kernel at least does not seem to care about the duplicate rules. Strongswan was compiled with “--with-routing-table=254 --with-routing-table-prio=100 (254 is “main”). Actually, you should set --with-routing-table=0 to install routes into the main routing table. This way no rule is installed at all and the source route is simply added to the main table. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=blob;f=src/libhydra/plugins/kernel_netlink/kernel_netlink_net.c;hb=HEAD#l1411 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] route disappears on PPP renegotiation
Hi Mirko, However, I found another problem, possibly related, which can be reproduced as follows with Strongswan 4.6.0: - setup the test scenario as in ikev2/net2net-cert (ignoring winnetou) - replace the ethernet link between moon and sun by a serial line, run PPP on it with the IP addresses that were previously on ethernet - start the IPsec tunnel - route in table 220 is OK - trigger PPP renegotiation - route is gone Charon log: see attachment. Hm, I don't see that charon is actually able to find a new route to the other host. The last log entries are Nov 9 17:32:55 moon charon: 03[KNL] interface ppp0 activated Nov 9 17:32:55 moon charon: 12[KNL] creating roam job due to address/link change Nov 9 17:32:55 moon charon: 12[KNL] getting address to reach 192.168.0.2 Could it be that the log is truncated? Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan Unable to load OpenSSL RSA Private-Key File
Hi Rajiv, Try adding an empty line between the third and fourth line of your private key file, like this: -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,2FC8D750D505E922 D8p/CHn/F5PuiLtSIp9AWfZ9Iig9VQydF7uhCDgJKgOutYGj7PkoufOhFsJ+H7D1 85P87fkzGA6LYj8LyF7/UXKGs0eBC8BT+c6zlVO1SVgvUii5A42oYXKUQQD1AA6d ... -END RSA PRIVATE KEY- -BEGIN RSA PRIVATE KEY- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,2FC8D750D505E922 D8p/CHn/F5PuiLtSIp9AWfZ9Iig9VQydF7uhCDgJKgOutYGj7PkoufOhFsJ+H7D1 85P87fkzGA6LYj8LyF7/UXKGs0eBC8BT+c6zlVO1SVgvUii5A42oYXKUQQD1AA6d ... -END RSA PRIVATE KEY- Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan Unable to load OpenSSL RSA Private-Key File
Hi Rajiv, 00[LIB] key integrity tests failed Seems like the gmp plugin has some issues with your key. It would help if you could send us an example private key file causing this error. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] route disappears on PPP renegotiation
Hi Mirko, I may be wrong, but I don't think it has been truncated. No you were right, it was the complete log. At 18:49:25, the route to 192.168.0.2 does exist, but charon hasn't noticed it. Well, charon does notice that the interface comes up again. But the issue here is that the IP address doesn't change. What happens is that charon sees that the interface goes down, tries to find a new route, doesn't find one and defers any further updates. Now, when the interface comes back up again, charon does indeed notice it, but since the IP is the same as before there is no need for it to trigger the MOBIKE process and update the installed SA/policies and, thus, does not retrigger the installation of the route. The solution to this problem would require a change in how the routes are managed in charon. Currently every installed forward policy manages some metadata about the route installed together with it. But there is no global list of installed routes. The latter would help in this case as we could simply reinstall all installed routes on reactivated interfaces. I can't give you an ETA for a solution at the moment, but if this is a real issue for you, there might be some hackish workarounds, e.g. triggering MOBIKE updates even if not really needed. Patches for a proper solution are welcome too. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan Unable to load OpenSSL RSA Private-Key File
Hi Rajiv, When I use openssl rsa -in mfcgw1key2.pem -check -noout on my x86_64 machine with OpenSSL 0.9.8o I get RSA key error: dmp1 not congruent to d RSA key error: dmq1 not congruent to d which is also the reason why our libgmp based plugin doesn't like the keys, i.e. 00[LIB] key integrity tests failed is logged. Actually, OpenSSL reports this error for all the keys you sent. So it sure looks like your keys got corrupted somehow (or never were valid in the first place). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] unable to add pseudo IPIP SA with SPI c1bb6ffe: Invalid argument
Hi, strongswan4-mod-kernel-klips - 4.5.2-1 Please try to remove this module from your build. The kernel-klips plugin was done for a very specific (and rather old) KLIPS release. And depending on whether your kernel actually includes the KLIPS patch or not might never work. So, do you actually use KLIPS? If so, you might have to go back to a 2.x strongSwan release that supported KLIPS. If not, then just use the kernel-netlink plugin. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] NAT-T and StrongSwan conf
Hi Alex, Thank you for your help and suggestions guys, got it working with OpenSwan. Interesting. Would you care to share the config that enabled you to do this with OpenSwan? Because I'm pretty sure L2TP/IPsec with destination NAT (i.e. the responder behind a NAT) is currently not possible with strongSwan. Thanks, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Android/Stongswan Integration
Hello Zhen, I have been trying to bring Strongswan 4.5.3 to Android If possible, you should update to 4.6.1 as there are several Android related improvements included in that release. 1. When I ran charon in adb shell, it started, but said: android plugin failed to load, can't open android control socket. That's because the control socket is only available, if charon gets started by the patched Android VPN GUI. With 4.6.1 it's possible to use the plugin even if charon is not started by the GUI. I did some search, the android plugin is something related to DNS. That's correct it installs DNS servers received from the gateway where Android expects them to be (there is no resolv.conf on Android). Question: do i have to to enable this plugin for VPN to work on the emulator? Only if you need DNS servers installed, or logging via logcat. These are currently the only two functions provided by the plugin, which are usable without GUI patch. If so, i did some ./configure --enable-android, it failed because it couldn't find a requied lib. Running ./configure won't work. To enable/disable plugins you have to edit the plugin list in the top Android.mk within the strongSwan source tree. But the plugin is enabled anyway, by default, it just can't be loaded without the control socket provided by the frontend in 4.5.3. 2. In the frontend integration site, it says it needs CA assigned certs, quoted below. Question: Does the certificate have to be issued by CA? Would self-assigned certificate work? I am just playing with it and wouldn't want to spend $1500 to buy one from verisign. :( Don't worry :) You can absolutely build your own CA (e.g. with the ipsec pki tool [1]). Just make sure you install the CA certificate in the Android certificate store as described on the page you quoted. Then use this CA to issue a certificate for the gateway you want to test against. With 4.6.1 you now have also the option to build starter and stroke which allows you to use an ipsec.conf based configuration, instead of using the frontend patch. Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/SimpleCA ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Strongswan support on Android
Hi Deepika, Does that mean that we will be having ipsec.conf file for Android as well, in the same way we have for Linux. Yes, it does. But you currently can't use the ipsec script, so you have to use starter and stroke directly. If that is the case, can somebody help me on how/where to create that file and the steps to make that work on Android. The directory where ipsec.conf and the other config files and directories are expected can be configured (with strongswan_CONFDIR) in the top Android.mk file within the strongSwan source tree. The default is /system/etc. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Android/Stongswan Integration
Hi Zhen, If I used 4.6.1, is there any special configuration I need to enable to build the starter and stroke when I build the Android? Have a look at the top Android.mk. There you can uncomment the strongswan_BUILD_STARTER line to enable the build of starter and stroke. I assume I wouldn't need to apply any of the three frontend patches any more? No, you don't. But you still could, as the two config methods are not mutually exclusive. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Android/Stongswan Integration
1. Doesn't seem that Charon loads the the ipsec.conf file. What makes you say so? Do you get any errors? Where did you put the file? Can you verify that it's there when you log into the emulator with 'adb shell'? And is that path equal to what you configured in the top Android.mk file as strongswan_CONFDIR? 2. If I use ipsec up to force the starter to bring up the conn, ipsec up gave some error like unnamed error ] ] ]. The ipsec script is not really working on Android as there is no 'test' or '[' command, of which the script makes use extensively. Simply use starter and stroke directly. Use 'starter' to start starter and charon and use 'stroke up' to start a connection (to terminate them just kill starter). Have a look at how the script uses starter and stroke to implement individual commands. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Help with UNITY_SAVE_PASSWD attribute
Hi Chris, If anyone could help me out in figuring out why: A) the attr plugin doesn't seem to be working I looked into that and it seems the attr plugin only supports IP addresses and subnets as values (i.e. no strings or ints). The attr-sql plugin [1] supports more types, so that might be worth a try to avoid having to change the code. B) if I'm sending down the value incorrectly in my hack inside modecfg.c No, the changes to pluto look fine. Whether the value is correct I don't know, but racoon at least uses the same. Are you sure the iPhone actually supports this attribute? I'm not sure but I suppose Apple uses racoon in iOS, which actually ignores this attribute when used as client. At least by default, could be that they somehow added support for it, though. Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/AttrSQL ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Help with UNITY_SAVE_PASSWD attribute
Hi Chris, which iOS version do you use on your device? Because I just tried how the VPN client behaves on an iPhone 3GS with iOS 5.0.1. And well, I can save the password even without sending UNITY_SAVE_PASSWD (I did not try what happens if I do, actually). https://discussions.apple.com/thread/2390965?start=0tstart=0 Since this thread was started quite a while ago and refers to iOS 3.x up to 4.0 I guess Apple changed their client's behavior in the mean time. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Help with UNITY_SAVE_PASSWD attribute
Hi Chris, With this config, w/ and w/o UNITY_SAVE_PASSWD, I get prompted for XAuth credentials on each VPN connect. The VPN connection is added through a .mobileconfig file, using VPN on demand on the iOS side. Ah, I didn't know this feature and I never actually used Apple's configuration utility. My tests were with a configuration created directly on the phone (which has no option to configure VPN on demand). Anyway, it seems the client behaves differently if the config is created on the phone than if it is created with the configuration utility. I found a (german) tutorial describing how to configure a VPN connection using said tool, which also offers a solution to store the XAuth password [1]. It roughly translates to this: Instead of transferring the config with the configuration utility directly to the phone, export it as file and import that file via email on the phone. (That's probably something you already did as the export results in a .mobileconfig file). Before sending the config to the phone, edit the XML file, search for the XAuthName entry and add the following two lines after it: keyXAuthPassword/key stringyourpassword/string As opening the patched .mobileconfig file in the configuration utility would remove the added lines, the file has to be transferred to the phone via email. I did not try this, so I'm not sure if it works. Of course, this also doesn't answer the question why UNITY_SAVE_PASSWD does not work, or if it is even supported by iOS. Regards, Tobias [1] http://www.apfeltalk.de/forum/tutorial-vpn-demand-t335026.html ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] leftid in non-default conn ignored
Hi Diego, First, what's your strongSwan version? If you configure this: conn LabMPLS-site1 ... leftid=@site1.example.com leftcert=site1.pem Do you by any chance see a log message like id 'site1.example.com' is not confirmed by certificate, defaulting to 'C=AR, ...' when you start charon? This would happen if the ID does not match the certificate's subject and is not contained in one of its subjectAltNames. If you do, it is strange that the same thing wouldn't happen if you moved leftid to %default. LabMPLS-site1: local: [site1.example.com] uses public key authentication Was that really the only thing you changed? Could you send me the two config files that demonstrate this problem? Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Compilation error in strongswan 4.6.1
Hello Deepika, eap_sim_plugin_create:*external/strongswan/src/libcharon/plugins/eap_sim/eap_sim_plugin.c:87: error: undefined reference to 'simaka_manager_create'* The files from libsimaka are included manually in the libcharon Android.mk and some of the new files were missing. I pushed a fix for this to our master branch [1]. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=3eff54a5 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] unable to allocate SPIs from kernel
Hi Milton, For some reasons, I don't see aes, hmac plugins on Nexus One device: That's correct because the functionality of these plugins is provided by the openssl plugin on Android. Which I assume is the issue? No, as these plugins provide functionality for the IKEv2 charon daemon and work solely in userland these have nothing with the unable to allocate SPIs from kernel error message. I'm running the stock cyanogenmod kernel, which I assume has the appropriate E A support? That's more likely the problem. I suppose the kernel lacks some of the required modules (see [1] for a list). There is a page on the CyanogenMod wiki which explains how to build a custom kernel (see [2]). Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/KernelModules [2] http://wiki.cyanogenmod.com/wiki/Building_Kernel_from_source ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] dns entries in config payload
Hi Milton,
Does libcharon process dns entries in the IKEv2 config payload?
I defined following in /etc/strongswan.conf
charon {
dns1 = 8.8.8.8
dns2 = 8.8.4.4
}
but the client does not appear to change local dns configuration.
The IKEv2 daemon charon currently only supports the CFG_REQUEST and
CFG_REPLY pair of configuration payloads. So in order for the gateway
to send config payloads to the client the latter has to request a list
of attributes. The only way to make charon as a client do so is by
having it request an internal IP address from the gateway. That is, the
client has to be configured with leftsourceip=%config.
Regards,
Tobias
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] configuring gcm mode on android
Hi Bill, I want to use the gcm block cypher. (esp=aes128cgm16-sha256!) I added gcm to the Android.mk in the strongswan_CHARON_PLUGINS list and also added it to the Android.mk in src/libstrongswan. The gcm plugin you activated with the above is for strongSwan internal use with the key exchange protocol IKEv2 and not on the IPsec level with ESP, which is what you want to enable with the esp= option. Since ESP is handled by the Linux kernel you have to build your own kernel with CRYPTO_GCM enabled in the options. So if you don't want to actually use AES-GCM with IKEv2 itself you don't have to do anything special when building strongSwan. The server was configured using --enable-gcm option and an ipsec listall seems to confirm that the server supports it. Same applies here, --enable-gcm only enables GCM for IKEv2. Depending on the Linux distribution you use, GCM may already be enabled in the default kernel. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] expected record boundary in key
Hi, When I try to add 'leftcert', I can no longer use PSK. Well, what's the point of defining a certificate if you want to use a pre-shared secret for authentication? conn %default ... leftcert=host_domain_tld.pem leftid=@host.domain.tld This gives me the following in the logs: Feb 7 15:35:20 192.168.69.1 pluto[3398]: id 'host.domain.tld' not confirmed by certificate, defaulting to 'C=SE, O=Bayour.COM, OU=System, CN=host.domain.tld, E=tu...@bayour.com' and if removing the leftid: Feb 7 15:36:28 192.168.69.1 pluto[3466]: id '%any' not confirmed by certificate, defaulting to 'C=SE, O=Bayour.COM, OU=System, CN=host.domain.tld, E=tu...@bayour.com' If leftid is not specified it defaults to the certificate's subject if a certificate is specified (otherwise the local IP address is used as ID). If both leftid and leftcert are specified, leftid has to match the subject or one of the subjectAltNames of the certificate, otherwise it defaults back to the subject (which is what happened in the first case above). That is, if you want to use @host.domain.ltd as leftid you have to add DNS:host.domain.ltd as subjectAltName to your certificate. C=SE, O=Bayour.COM, OU=System, CN=host.domain.tld, E=tu...@bayour.com A_RIGHTID_IP : PSK SomESecReet C=SE, O=Bayour.COM, OU=System, CN=host.domain.tld, E=tu...@bayour.com %any : PSK aNothEERseCreT There is currently no support to use DNs as ID selectors in ipsec.secrets. As indicated by my initial question above this wouldn't make much sense anyway. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Traffic Selector problem when using IKEv2 IPV6
Hi Eric, However, when I specify a port value in the protoport designations (E.g. leftprotoport=tcp/0 + rightprotoport=tcp/3260 OR leftprotoport=6/0 + rightprotoport=6/3260 OR leftprotoport=tcp/any + rightprotoport=tcp/3260), the IKE authentication fails due to a traffic selector mismatch. When I use any of the previous conventions the traffic selectors appear as the following on the remote peer: Find a rule matching the first traffic selectors of: TS_r=ipv6(tcp:3260,fc00:2518::10:125:56:16),ipv6(tcp:3260,fc00:2518::10:125:56:16) and *_TS_i_*=ipv6(tcp,fc00:2518::221:9bff:fe98:854b),ipv6(*_tcp,fc00:2518::221:9bff:fe98:854b_*) In this case, the traffic selectors from the Strongswan host appear to be sending tcp,fc00:2518::221:9bff:fe98:854b. Which do not appear fine since I specified the port values in the protoport designations. In fact they appear to be exactly the same as when I didnät specify the port values in the protoport designations. Hm, no you actually didn't specify a port value in the leftprotoport option (i.e. TSi). Specifying leftprotoport=tcp/%any or tcp/0 means you don't want to restrict the traffic to a specific port, which is the same as specifying just leftprotoport=tcp. On the wire this part of the traffic selector is encoded as a range of accepted port values (i.e. 0-65535). The responder is then free to narrow this range to a specific port (i.e. with rightprotoport) or a smaller range (can't be configure in ipsec.conf yet) if it likes to do so. So I guess the question is why are the port values from the Strongswan host not being presented to the remote peer? The port you actually specified (3260) is sent to the remote host (as part of TSr, which is what rightprotoport configures), right? So, what is it you expected to happen differently here? Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] IP range support
Hi Chester, I am using strongswan-4.2.8, I have a question want to check you, does this version have support IP range like 192.168.2.3-192.168.2.233 when set to left|right side? No, we currently don't support arbitrary address ranges. Such ranges are simply mapped to the smallest subnet containing at least all the addresses (192.168.2.0/24 in your case). If not does any one have an idea to implement it? You have to manually split your range into multiple subnets and use these in left|rightsubnet. For your range this would give you a list of 10 subnets: 192.168.2.3/32, 192.168.2.4/30, 192.168.2.8/29, 192.168.2.16/28, 192.168.2.32/27, 192.168.2.64/26, 192.168.2.128/26, 192.168.2.192/27, 192.168.2.224/29, 192.168.2.232/31 I just added a ticket for this [1], so we will probably add support for address ranges in one of our next releases. Regards, Tobias [1] http://wiki.strongswan.org/issues/173 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] NO_PROPOSAL_CHOSEN error when IKEv1 and IKEv2 has closely resemble but not exact suites
Hi Simon,
Is it possible that charon is searching for matches from pluto's
connections? Why should charon have knowledge of
pluto's connections?
Yes, that's exactly what's happening here. By default, charon loads all
connections whether they have keyexchange set to ikev2 or not. But it
uses IKEv1 connections only as responder (the reason for this was
probably to simplify configuration on gateways, as only one config would
be necessary). If you don't want this you could apply the attached patch.
In another attempt to debug the problem, we arranged the order of the
tunnels in ipsec.conf so that IKEv2 conn is ahead of the IKEv1 conn.
Then connection is established. And the IKEv1 which is now second in
/etc/ipsec.conf still works.
Yep, that works too, as charon simply uses the first matching connection.
Regards,
Tobias
From d1d0d878945799a0f528794852c5ed10516d2ebd Mon Sep 17 00:00:00 2001
From: Tobias Brunner tob...@strongswan.org
Date: Wed, 8 Feb 2012 11:31:56 +0100
Subject: [PATCH] Charon ignores IKEv1 connections received via stroke.
---
src/libcharon/plugins/stroke/stroke_socket.c |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/src/libcharon/plugins/stroke/stroke_socket.c b/src/libcharon/plugins/stroke/stroke_socket.c
index 43919b0..7f44070 100644
--- a/src/libcharon/plugins/stroke/stroke_socket.c
+++ b/src/libcharon/plugins/stroke/stroke_socket.c
@@ -216,6 +216,12 @@ static void stroke_add_conn(private_stroke_socket_t *this, stroke_msg_t *msg)
pop_string(msg, msg-add_conn.name);
DBG1(DBG_CFG, received stroke: add connection '%s', msg-add_conn.name);
+ if (!msg-add_conn.ikev2)
+ {
+ DBG1(DBG_CFG, ignoring IKEv1 connection '%s', msg-add_conn.name);
+ return;
+ }
+
DBG2(DBG_CFG, conn %s, msg-add_conn.name);
pop_end(msg, left, msg-add_conn.me);
pop_end(msg, right, msg-add_conn.other);
--
1.7.4.1
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] expected record boundary in key
When I try to add 'leftcert', I can no longer use PSK. Well, what's the point of defining a certificate if you want to use a pre-shared secret for authentication? Most (all) of my connections will eventually use certificates, so the plan was to put that in the %default section, so I don't have to duplicate it in every single conn section... I see. In that case you have to either add a FQDN/RFC822_ADDR as subjectAltName to the certificate, so that this simple ID can then be used as leftid and in ipsec.secrets, or you use the 'also' keyword instead of %default as a means to avoid having to duplicate options in multiple connections. Or... I had a look at the code and it actually is possible to use DNs as ID selectors in ipsec.secrets (the IKEv2 daemon charon already supports this). The problem is that pluto's parser treats any line starting with or ' as PSK secret without selectors (seems to be a very old PSK format used by Free/SWAN). As indicated by the error message you got, it seems that this wasn't even fully supported anymore. I pushed a fix to our repository [1], which completely removes support for this legacy format. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=7efde901 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] kernel upgrades
Hi Alexandre, When running strongswan with the 3.2 kernel here is what i find in the logs: Feb 8 16:56:11 shire charon: 16[KNL] unable to add policy 172.17.2.0/24 === 172.20.0.0/23 out Feb 8 16:56:11 shire charon: 16[KNL] unable to add policy 172.20.0.0/23 === 172.17.2.0/24 in Feb 8 16:56:11 shire charon: 16[KNL] unable to add policy 172.20.0.0/23 === 172.17.2.0/24 fwd Feb 8 16:56:11 shire charon: 16[IKE] unable to install IPsec policies (SPD) in kernel If i check ip xfrm policy I indeed note that the policy vanished, whereas the tunnel seems still up Yes, the errors above are currently ignored by the daemon. They are usually seen if the policies are already installed in the kernel (e.g. because the daemon previously crashed and the policies were not flushed before it got restarted). If anything else were the reason for them you would see additional error messages like received netlink error: ... in the log. But since you say you don't see the policies listed in ip xfrm policy this seems a bit strange... Not sure what happened here but recent versions of strongSwan should run fine on 3.2 kernels, as can be seen by the latest results of our test suite [1], which Andreas recently ran with a 3.2.4 kernel against the 4.6.2 release candidate (if that's also true for 4.4.1, I don't know). Regards, Tobias [1] http://www.strongswan.org/uml-testresults4rc.html ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] cannot use strict mode when right=%any
Hi Simon, From the syslog, it would seem once a possible candidate is picked (by their order in ipsec.conf), the proposal selection would not look at the other conns that are also 192.168.3.193...%any. Is this true? Yes, the current selection algorithm is very simple and based solely on the IP addresses. This leads exactly to the situation you described. If true, any suggestion how I can get tunnels with different ciphers co-exist? Ideally modify the code to go back and pick another my_ip...%any candiate is best for my application. Or perhaps I ban strict mode when right=%any? We could change the code and consider the proposals sent by the client but that would require quite some refactoring. And it wouldn't really improve the situation much. You simply can't enforce an IKE proposal for a specific client other than by its IP address (the IDs are exchange only after the IKE proposal is selected). The config in ipsec.conf might be a bit misleading on that part, as you define IKE_SA and CHILD_SA options in the same conn section, but in reality these are used separately by charon (first only the IKE part is considered and once the IDs are known the proper CHILD config is selected which might not be from the same conn section in ipsec.conf). Therefore, you might want to rethink why you want to use strict mode as responder for road warriors (i.e. with right=%any). If you don't like charon's default proposal you could, of course, define a strict proposal that contains all the proposals you allow for any of the road warriors (e.g. ike=aes128-sha1-modp1536, aes128-md5-modp1536! which could also be written as ike=aes128-sha1-md5-modp1536!). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] 答复: IP range support
Hi Chester, If I want to add a parameter (like leftiprange,rightiprange) in ipsec.conf, and I hope the parameters can be accepted by strongswan, how can I implement it? I'm not sure what you mean by I hope the parameters can be accepted by strongSwan, but if you want to implement all of this yourselves, you can have a look at the following commits which show the individual steps needed to add a new option to ipsec.conf: 1. Add the new option to keywords.txt|h and parse it in starter: http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=2b26a9c3 Depending on the type of keyword you can't assign it to a member of struct starter_conn directly and you may have to parse it in confread.c manually (but note that many options are actually stored as strings in starter_conn and only parsed later by the IKE daemon). 2. Add the option to struct stroke_msg_t which makes it available to the IKEv2 daemon charon: http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=1f83541d In case of strings you also have to use push_string to actually add the string to the message. 3. Read, parse and use the configured values appropriately in the daemon: http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=277fcf9f The above commit is really just an example, it highly depends on the kind of option you added. IP address ranges could, for instance, directly be converted to traffic selectors and then added to the child_cfg_t object. An alternative (and probably easier) solution would be to change how left|rightsubnet is parsed and allow an alternative syntax there (e.g. leftsubnet=192.168.2.6-192.168.2.20). This has currently not a very high priority for us, but if you need a solution soon and don't want to do this yourselves, you might want to consider our commercial development services. Please contact us directly, if that's an option for you. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Restarting ipsec on the left requires restart on the right
Hi Andreas, Issuing an ipsec restart on the left end of the tunnel seems to kill the connection and it won't come back until I issue an ipsec restart on the right end as well. You should check the log on the right to see what the problem is when left tries to re-establish the connection. This is obviously not practical. It seems the right server is not aware that the connection has been interrupted. How do I make it aware? You could configure DPD with dpdaction=restart so that right re-establishes the SA once it detects the old SA is gone. It may also be noteworthy that restarting the *right* server does not result in the same problem. In this case the connection is interrupted only for the time it takes ipsec restart on the right to complete. Is this behaviour because of the different StrongSwan versions used? Could be, yes. The log of the respective remote end should show if there is a difference in their behavior. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] IKEv2 - IKE_AUTH request problem
Hi Gowri, 05[CFG] added configuration 'tahi_ikev2_test' 10[CFG] stroke message = -2036037751 bytes @ 0xfff80ede300 10[CFG] received stroke: route 'tahi_ikev2_test' I'm unable to reproduce this even by forcing the length to a very large value. On what architecture are you running this? 10[KNL] adding policy NUT IP6 === TN IP6 out 10[KNL] sending XFRM_MSG_NEWPOLICY: = 252 bytes @ 0xfff80edda28 10[KNL] unable to add policy NUT IP6 === TN IP6 out 10[CFG] installing trap failed I am suspecting over stroke message which is shown as negative bytes. That output there is strange, but it should not lead to the problem seen above (it even seems that the stroke message was properly received, i.e. the negative value is just a glitch in the debug output). The error unable to add policy ... usually means that the policy is already installed in the kernel (you can check with 'ip xfrm policy'). If that's the case try to flush them, which actually should automatically happen with e.g. ipsec stop. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] strongSwan on a KVM VPS does not work
Hi, the client is a roadwarrior and want get a virtual ip, from the log it seems it got the virtual ip, however the ping from server to client does not work. Does it work in the opposite direction? Please also try to verify whether it is the ICMP request or the response that gets lost. Is the client also running strongSwan? Version, config? Are there any errors logged? 04[NET] sending packet: from 64.62.209.183[4500] to 121.63.63.197[4500] 01[NET] received packet: from 121.63.63.197[4500] to 64.62.209.183[4500] 01[ENC] parsed INFORMATIONAL request 8 [ ] 01[ENC] generating INFORMATIONAL response 8 [ ] The above shows that there are a lot of strange message betweent the server and client. These messages look like DPD packets sent by the client. How is DPD configured there? Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Error compiling 4.6.1 under Debian
Hi Jason, When building under the latest Debian Sid, I get the following error. Is this a known issue? This is due to the --enable-eap-tnc configure option used by the Debian package. Enabling this plugin without enabling any of the tnccs plugins doesn't make sense, and only the latter cause libtnccs to be built. This worked before 4.6.x as the stuff in libtnccs was implemented directly in libcharon (but the plugin was not really usable). Anyway, since you probably don't need the EAP-TNC plugin you can just remove that configure option from the debian/rules file. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Error while building vstr library for ICS
Hi Deepika, I'm trying to build the vstr library for strongswan on ICS.However, when I give this build command, I'm getting the following error: ... ../include/fix.h:23: error: conflicting types for 'prctl' I've updated the patch on the wiki with a fix for this problem [1]. Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/Android ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Site-to-Site StrongSwan with a Cisco device
Hi Mo, Does that mean it cannot be done? Recent kernel versions (= 2.6.33, I think) actually support a variable truncation length. I added support for HMAC_MD5_128 and HMAC_SHA1_160, which are both defined in RFC 4595 (see [1] for the patch). They are not part of charon's default proposal, so you have to manually configure md5_128 and/or sha1_160 with the esp option in ipsec.conf. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=686cfd4e ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] using gcm for ike on Android
Hi Bill, I’ve modified the Strongswan-4.6.1/Android.mk to include gcm in the strongswan_CHARON_PLUGINS list and I’ve also added LOCAL_SRC_FILES += $(call add_plugin, gcm ) To the libstrongswan/Android.mk file. Looks fine so far. A problem could be that the list of plugins to load is a compile-time constant. So if you don't do a make clean first the list of plugins used by the daemon is not updated (an alternative would be to use a load statement in strongswan.conf). Use the following to avoid having to rebuild the whole tree: make clean-libcharon Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] kernel SPD policy not installed until successful IKE negotiation completes
Hi Alex, Is there a way to instruct strongswan to install the security policy right upon starting? Try auto=route. This installs the policies right away and if traffic matches them the daemon will try to setup the appropriate IKE/IPsec SAs. The installpolicy option is intended for MIPv6 where the policies are not managed by the IKE daemon. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] kernel SPD policy not installed until successful IKE negotiation completes
It would be good if auto could have an option to both install the policy and initiate negotiation (both route and start). I guess this is not possible right now, isn't it? No, there is no such option right now. It's usually not needed as auto=route automatically initiates the negotiation if any traffic matches the installed policy. In all other cases ipsec up name does the trick (or using whack directly as you did). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] MOBIKE switching bug in gateway with two external interfaces
Hi Simon, Seems MOBIKE message processing needs to store the message's source IP addr along with the other ADDITIONAL_IPV4_ADDRESS. Use ike_sa to remember this address separately is not safe. It requires code to add it in the additional_addresses list before it is overwritten by N(UPDATE_SA_ADDRESSES). You are right, we should store the peer's current address in this list. I pushed some commits to our repository to fix this (see [1]-[4]). Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=2fe624cc [2] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=94bbc602 [3] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=72b28112 [4] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=cd6b5bf8 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Limiting the cipher suites in remote peer proposal
Hi Alex, I was not aware of the strict flag at all. man ipsec.conf has no info on that. That's true for versions before 4.6.0. In the man page of later versions and on our wiki page about ipsec.conf conn sections [1] this flag is documented. Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/ConnSection/ ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] mixing ipv4 and ipv6 subnets does not work
Hi Niccolò, # bad subnet: leftsubnet=a:b:c:0300::/56,1.2.3.4/28 [non-ipv6 address may not contain `:'] bad argument value in conn 'linode-linuxsystems' ### 1 parsing error (0 fatal) ### while if I add the ipv4 subnet first I get not errors but it doesn't tunnel the traffic toward 1.2.3.4/28 Noone? Well, what did you expect? You provided neither a full configuration file nor any logs to support what you are claiming is true. Now, the first part of what you are saying above *is* correct. There is a bug in starter that makes it parse left|rightsubnet incorrectly in that case. It first checks the whole string for dots to detect the address family and when it parses the first subnet its family doesn't match. Switching the two subnets obviously works around this bug. The other part I can't confirm, as I did a quick test with IKEv2 and it works here. Unless you are using IKEv1 (which I can't know) I see no reason why it shouldn't work for you too. It won't work for IKEv1 because the pluto daemon only supports single subnets for left|rightsubnet (which the man page for ipsec.conf would tell you), you'd have to add separate conn sections for each subnet in that case. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] mixing ipv4 and ipv6 subnets does not work
Hi Niccolò, Thanks for the config. conn A-B ... leftsubnet=::/0 ... rightsubnet=1.2.3.32/28,a:b:c:0300::/56 That's not gonna work, as you have only an IPv6 subnet configured in leftsubnet. Policies in the kernel are installed for the combination of every subnet in leftsubnet with every subnet in rightsubnet (if the responder does no narrowing), but only if the address families of two subnets match. Therefore, try adding 0.0.0.0/0 to leftsubnet. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] charon: [15]CFG trap not found, unable to acquire reqid 0
Hi Vilhelm, config setup crlcheckinterval=180 strictcrlpolicy=no plutostart=no charondebug=asn 4, knl 4,mgr 4,ike 4,chd 4,net 4,enc 4 conn %default auth=esp authby=psk esp=aes128ctr-aesxcbc! ikelifetime=60m keylife=20m keyingtries=1 rekeymargin=3m keyexchange=ikev2 ike=aes128ctr-aesxcbc-ecp192! type=transport Your config file looks incomplete. You have to specify at least one conn section (other than %default) with the auto keyword (auto can be specified in %default, though). Where auto=route might be what you want, as charon will then install policies in the kernel's SPD and an SA will automatically be negotiated upon matching traffic. You also need to specify right and optionally left (the endpoints of the IKE_SA) in that conn section. If you only want specific traffic to be tunneled use the left|rightsubnet and left|rightprotoport keywords (see the example at [1]). Also if you want to configure the policies in the kernel yourself make sure you use a reqid 0 and then specify reqid=reqid and installpolicy=no in the respective conn section. Regards, Tobias [1] http://www.strongswan.org/uml/testresults/ikev2/protoport-route/ ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Header verification failed and NAT mapping changed
Hi Kim,
On our IPSec GW moon we can see following message repeatedly in our log
files:
Mar 19 11:02:45 moon charon: 14[NET] sending packet: from
192.168.2.17[4500] to sun[500]
Very strange. Due to the NAT this packet should actually be sent from
port 4500 to port 4500. The complete log of moon (and sun) would help
to see whether there is something wrong with the NAT detection etc.
Mar 19 11:02:46 moon charon: 01[KNL] NAT mappings of ESP CHILD_SA
with SPI c2aa0995 and reqid {804} changed, queuing update job
This seems strange too as this should not really happen for the host
*behind* the NAT (unless the other end is natted too, of course) - and
only if the actual endpoints have changed. A possible reason could be
that sun sends ESP packets from port 4500 while moon has port 500
configured (if the port used above is any indication).
Moon is running: Linux strongSwan U4.5.0/K2.6.37.6-0.5-desktop
Sun is running: Linux strongSwan U4.2.8/K2.6.27.7-9-pae
Hm, 4.2.8 is quite old not sure if that plays a part in this.
Regards,
Tobias
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Charon hangs after failing to delete Rekeyed IPsec SAs
Hi Anand, conn %default ikelifetime=10m keylife=5m rekeymargin=3m Not sure what exactly the problem is but I suspect it might be related to the times you configured above (at least partially). Please have a look at the wiki page documenting how rekey times are calculated [1]. As you can see, the values 5m for keylife (lifetime) and 3m for rekeymargin (margintime) are problematic - it could even disable rekeying (rekeytime = 5m - random(3m..6m)). Please increase lifetime and see if that fixes the problem (also, updating to a more recent release wouldn't hurt). Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Charon hangs after failing to delete Rekeyed IPsec SAs
Hi Anand, On my environment there is no support for kernel-netlink interface for IPsec, I have to use kernel-pfkey interface only as I have my hooks registered in PFKEY to XFRM for IPsec. I have tried latest versions of strongswan (4.5.1 and 4.5.3) both resulted in kernel panic after running for a while. I think there is not much support for kernel-pfkey plugin in latest strtongswan versions, and since latest versions require kernel-netlink plugin to function properly migrating to newer versions might be not helpful in my case. You actually need both plugins on Linux, even if using kernel-pfkey to install IPsec SAs and policies. The reason for this is that the kernel-netlink plugin also implements the kernel_net_t interface which is used for address and route lookups etc. You can enable both plugins, the kernel-pfkey plugin is then loaded first by default (otherwise make sure it is loaded first), which means that its kernel_ipsec_t implementation is used while the kernel-netlink plugin can still provide the required kernel_net_t implementation. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] charon: [15]CFG trap not found, unable to acquire reqid 0
Hi Vilhelm, It works though if you limit the debugging level and / or the number of debugging options. I've reproduced this several times just to be sure. Why is this? The problem line was (in full): charondebug=asn 3,knl 3,mgr 3,ike 3,chd 3,net 3,enc 3 It works if you change it so (e.g.) charondebug=ike 3 My strongswan version is 4.5.2 as included in Ubuntu 11.10 Well, my guess is that this is because the asn log group was not added until the most recent release (4.6.2). But you should have seen a message regarding this (something like unrecognized option '--debug-asn'). Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Upgrade issue
Hi Peter, With 4.4.0, this works great; here's a relevant snippet from pluto.log (after all the certs have checked out): | XAUTHInitRSA check passed with keyid 08:f4:bf:b9:2d:e8:da:89:48:51:70:dc:1a:e8:a8:93:33:02:a1:3c ... Now when I use the same config on 4.5.2, I get a slightly different and less encouraging result: | XAUTHInitRSA check passed with keyid d3:ab:cf:e0:aa:0d:4d:c3:9c:19:d0:6c:7f:99:9b:a5:04:b4:d1:75 ... The logged keyid is different. Did you also change the certificates? Try adding 'controlmore' to plutodebug, this should give you more information when pluto tries to find a suitable connection. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] local traffic inspection on strongswan endpoint, how?
Hi Andreas, Have a look at the last question in our FAQs [1]. i just learned that the tcpdump -E option can do something like what i want. tcmpdump seems quite limited regarding the supported algorithms. You could try to dump the packets with tcmpdump to a file and then analyze them with wireshark (which supports more algorithms) on another host. Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/FAQ#General-Questions ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Upgrade issue
Hi Peter, I'm attaching the full control+controlmore logs from both versions in case anyone's interested (IP redacted). A diff shows them effectively identical until after the full match lines. Actually, I think that the problem is caused by an earlier difference in the logs: 4.4.0: loading secrets from /etc/ipsec.secrets loaded private key from 'server.key' ... loaded shared key for %any 204.236.190.251 4.5.2: loading secrets from /etc/ipsec.secrets loaded PSK secret for 184.169.244.187 %any That is, 4.5.2 doesn't load the private key. This is then later the cause for pluto to skip the connection even if it is a full match, it's simply not able to authenticate itself. How does your ipsec.secrets file look like? Is there a difference between the two? Check the man page or our wiki [1] to make sure the syntax is valid. Regards, Tobias [1] http://wiki.strongswan.org/projects/strongswan/wiki/IpsecSecrets ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] uniqueids
Hi Peter, I see that both pluto and charon support the uniqueids option, which ensures that each peer ID can only connect from one IP at a time. I have a situation where some peers are generating multiple connections from a single IP and the old ones are left hanging, generally until they eventually get cleaned up by DPD. So is there some deep technical reason for the different-ip constraint on peer uniquing, or is that simply the policy that makes the most sense for most deployments? Have a look at issue #187 [1] which touches on this topic in regards to pluto. In comparison to pluto charon only uses the IDs to decide if an SA is a duplicate. Put another way, what terrible fate would befall me if I were to remove the sameaddr check in a private build and enforce unique IDs regardless? You could probably remove the address comparison in pluto but I'm not entirely sure what the side-effects of this are (it will most likely break if you have more than one Quick Mode SA queued, as that was apparently the reason for the removal of the port comparison in 4.1.7). Regards, Tobias [1] http://wiki.strongswan.org/issues/187 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] ipv6 address parsing from certificate
Hello, # ipsec stroke listcerts List of X.509 End Entity Certificates: altNames: 32.2.0.0 Any suggestion on how to proceed? Yes, either update to at least 4.4.1 or apply the patch at [1]. Regards, Tobias [1] http://git.strongswan.org/?p=strongswan.git;a=commitdiff;h=7a74295e ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] what is the frequency of IKE_SA_INIT request
Hi Sanjay, How is the frequency of IKE_SA_INIT request defined, I see in the logs a request is sent at intervals of 4,8,13,23, 42 seconds. Is this frequency customizable. See, http://wiki.strongswan.org/projects/1/wiki/Retransmission. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] SHA2_256_128
Hi Eric, I have a situation where ESP packets appear to be getting mangled on the remote peer whenever I use SHA2-256-128 for Phase2 (ESP). I can establish the SAs from the Strongswan to the remote peer no problem. However, I get no packets returned after establishing the tunnel. Not sure if this applies here as you didn't mention the kernel versions you are using, but Linux kernels before 2.6.33 incorrectly used a truncation of 96 bit for SHA-256. With strongSwan 4.3.6 we introduced support for the configurable truncation length of newer kernels and the default changed to 128 bit. For compatibility with older kernels we also added a new keyword (sha256_96) to negotiate the incorrect truncation (this uses algorithm identifiers from the private range in IKEv2, so it only works between two strongSwan hosts). In your case the other host might be using the incorrect truncation while the strongSwan host expects a truncation of 128 bit. By the way, Wireshark seems to support both truncations, so you should be able to verify this easily. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Reporting Issue:Old CHILD_SA not getting cleared
Hi Anurag, 1) We are using StrongSwan charon [Linux strongSwan 4.3.1] Just let me tell you that we don't really like to support such old releases. It would great if you could try if this issue is still present in 4.6.2. 3) After around 600 sec. from the start, IKE_SA re-keying starts, but just before that we observe that an INFORMATIONAL message (with Next Payload: Delete) is sent from NODE A to NODE B. Is this expected even before the IKE_SA re-keying starts? Moreover NODE B responds back with an INFORMATIONAL message (with Next Payload: None). This is expected only when IKE_SA re-keying happens and old IKE_SA's delete message is sent. Well, my guess is (without config it's hard to tell) that you have set reauth=yes (which is the default) in your config. Then this is perfectly normal. The previous IKE_SA is deleted and the new one is established from scratch. Setting reauth=no will cause charon to do a regular rekeying. 4) After the IKE_SA re-keying is over and new IKE_SA is created, we observe that 2 new CHILD_SA's are created even though before the re-keying period the IKE_SA had only 1 CHILD_SA. Now both these CHILD_SAs work independently and re-keying independently. So after the end of 1st IKE_SA re-keying we have 2 CHILD_SAs even though we started with 1. The output of setkey -D also confirms the same. This might be a bug with reauthentication in 4.3.1. Try a newer release to verify if that's the case. This issue is not observed when both end of the tunnel, i.e., NODE A and NODE B have StrongSwan charon. We suspect that this could be an interoperability issue. Can you please help us in debugging this issue? That's interesting, but it's hard to tell, without logs, what exactly the differences between both of these cases are. Comparing the logs might give you some clue why it's not an issue between two hosts running charon. Regards, Tobias ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] scepclient and cisco
Hi Germano, I've been trying to get scepclient to work with CISCO (IOS 15) for a week, turned all debugging on and still no success. CISCO fails with unable to open signed data when I request a certificate (get ca cert works). This is what I'm doing: ipsec scepclient --out cert=mycert.der --dn CN=myname -k 1024 --url http://10.1.1.2/cgi-bin/pkiclient.exe --in cacert-enc=CISCO.der --in cacert-sig=CISCO.der The wiki documentation for scepclient is extremely poor. I could improve it with some cisco examples if I get this to work... Are there any special options/compile options? Opinions on what could be wrong? Well, scepclient is quite old. It was written 7 years ago and did not get much attention since then. Development was based on version 10/11 of the SCEP draft [1], which is currently published in version 23. So it's very well possible that there are incompatibilities with more recent implementations (which the one in IOS 15 presumably is). And updating scepclient has not a very hight priority for us at the moment. The question really is what the Cisco box means with unable to open signed data (Was it not able to parse the request? Was it not able to decrypt it? ...). The only thing that might be wrong with your command line is that you don't specify '--out pkcs1', but I don't see how that could cause the above error on the Cisco side. Regards, Tobias [1] http://tools.ietf.org/html/draft-nourse-scep ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
