strongSwan: Issues 2015-10-19T21:59:23Z strongSwan Redmine strongSwan - Issue #1165 (New): StrongSwan Virtual Ip problem 2015-10-19T21:59:23Z abdullah sevincer <p>Hi,</p> <p>I am trying to set up windows port with a linux server that has setup as supporting road-warrior clients (assigning virtual ips to clients). I have read below information from the wiki and understood this scenario is not supported for windows and installing virtual ip is failing on windows:</p> <p><strong>Beside some other limitations, the kernel-iph networking backend currently does not support the installation of virtual IP addresses. Such addresses are usually assigned to road-warrior clients, making the strongSwan Windows port not usable as client for this particular scenario.</strong></p> <p>My question is: Is there a way to work around this scenario? lets say I dont need a virtual ip on windows and I can use a psychical nic ip to set the tunnel. However, if I do this lets say configure the windows as a normal client the negotiation with the road warrior server fails and policy is not installed because it expects a virtual ip from the windows client.</p> <p>is there a configuration option to let windows side to work without the virtual ip even though the ipsec server side is configured to support road warrior clients?</p> <p>Thanks.</p> strongSwan - Feature #960 (Feedback): Raise ALERT_PROPOSAL_MISMATCH_IKE in IKE V1 2015-05-20T06:16:47Z Avinoam Meir <p>In IKE V2 StrongSwan raise ALERT_PROPOSAL_MISMATCH_IKE</p> <p>We currently don't raise such an alert for IKEv1 , and it would make sense to do so.</p> <p>patch attached.</p> strongSwan - Bug #456 (Feedback): StrongSwan client for OS X crashes 2013-11-22T15:24:28Z D B <p>When starting a connection on OS X (10.8.5 on an Intel Core i7, x86_64) from the StrongSwan client (v5.1.1-2), I get the following trace in the log window (even before the password query window appears):</p> <pre> dumping 9 stack frame addresses: /usr/lib/system/libsystem_c.dylib @ 0x00007fff942d3000 (_sigtramp+0x1a) [0x00007fff942d590a] -&gt; _sigtramp (in libsystem_c.dylib) + 26 1 ??? 0x0000000000000000 0x0 + 0 /Library/PrivilegedHelperTools/org.strongswan.charon-xpc @ 0x000000010959a000 (ike_sa_create+0x2393) [0x00000001095f9863] -&gt; 0x000000010005f863 (in org.strongswan.charon-xpc) + 291 /Library/PrivilegedHelperTools/org.strongswan.charon-xpc @ 0x000000010959a000 (ike_sa_create+0x3286) [0x00000001095fa756] -&gt; 0x0000000100060756 (in org.strongswan.charon-xpc) + 86 /Library/PrivilegedHelperTools/org.strongswan.charon-xpc @ 0x000000010959a000 (controller_create+0xd2f) [0x00000001095e11ff] -&gt; 0x00000001000471ff (in org.strongswan.charon-xpc) + 159 /Library/PrivilegedHelperTools/org.strongswan.charon-xpc @ 0x000000010959a000 (processor_create+0x647) [0x00000001095b6877] -&gt; 0x000000010001c877 (in org.strongswan.charon-xpc) + 359 /Library/PrivilegedHelperTools/org.strongswan.charon-xpc @ 0x000000010959a000 (strongswan_thread_create+0x1e5) [0x00000001095ba345] -&gt; 0x0000000100020345 (in org.strongswan.charon-xpc) + 117 /usr/lib/system/libsystem_c.dylib @ 0x00007fff942d3000 (_pthread_start+0x147) [0x00007fff942e7772] -&gt; _pthread_start (in libsystem_c.dylib) + 327 /usr/lib/system/libsystem_c.dylib @ 0x00007fff942d3000 (thread_start+0xd) [0x00007fff942d41a1] -&gt; thread_start (in libsystem_c.dylib) + 13 killing ourself, received critical signal </pre> strongSwan - Issue #354 (Assigned): TLS certificcate CRL is not validated with strictcrlpolicy=yes 2013-06-24T06:20:50Z tn6Rsnnugz0KEI7WktcN t54DkwcNDM0oTKkIX24p <p>When connecting with EAP-TLS the TLS certificate CRL is not enforced when strictcrlpolicy=yes is defined.</p> <p>So for example, if a user connects with a certificate that is revoked, and the CRL server is offline and the configuration strictcrlpolicy=yes is set, the connection still continues even though the CRL validation fails!</p> <p>I have only tested this in 5.0.4</p> strongSwan - Feature #129 (Assigned): Relations between ike/child/peer_cfg 2011-05-13T07:46:06Z Martin Willi <p>The relations between child_cfg/peer_cfg are too strict:</p> <p>Reloading configurations through <em>ipsec reload</em> deletes child_cfg attached to peer_cfgs, even if in use by an IKE_SA. This prevents a CHILD_SA from rekeying, as no child_cfg is available anymore for the peer_cfg refcounted by the IKE_SA. We either have to store a reference for the child_cfg too, or even better look up the connections during rekeying globally.</p> <p>A different issue concerns the relation between peer_cfg/ike_cfg:</p> <p>The relation is not strict enough: As responder, it is currently not possible to enforce a ike_cfg for a peer_cfg selected later during authentication. Limiting peer_cfgs to the addresses specified in the associated ike_cfg is not possible, either.</p>