If the provider has access to the full pool list, it can enumerate
them twice, for example to search for existing leases first, and
only search for new leases in a second step.
Fixes lease enumeration in attr-sql using multiple pools.
With uniqueids=no the daemon still deletes any existing IKE_SA with the
same peer if an INITIAL_CONTACT notify is received. With this new option
it also ignores these notifies.
This allows listeners to migrate to the new IKE_SA with the
ike_reestablish event without having to worry about an ike_updown event
for the old IKE_SA.
Brings support for multiple virtual IPs and multiple pools in
left/rigthsourceip definitions. Also introduces the new left/rightdns
options to configure requested DNS server address family and respond
with multiple connection specific servers.
This brings support for EAP-Nak payloads on the client (to select a
specific or supported method), and the server (via the eap-dynamic
plugin which selects a method supported/requested by the client).
Using the register_constructor function enables custom keymat_t
implementations per IKE version. If no constructor is registered the
default behavior is preserved.
This branch introduces a userland IPsec implementation (libipsec) and an
Android App which targets the VpnService API that is provided by Android 4+.
The implementation is based on the bachelor thesis 'Userland IPsec for
Android 4' by Giuliano Grassi and Ralf Sager.
This branch comes with some preliminary changes for the user-land IPsec
implementation and the Android App.
One important change is that the UDP ports used by the socket-default plugin
were made configurable (either via ./configure or strongswan.conf).
Also, the plugin does randomly allocate a port if it is configured to 0,
which is useful for client implementations. A consequence of these
changes is that the local UDP port used when creating ike_cfg_t objects has
to be fetched from the socket.
If two initiators use the same SPI and also use the same SA proposal the
hash for the initial message would be exactly the same. For IKEv2 and
Aggressive Mode that's not a problem as these messages include random
data (Ni, KEi payloads).
As we only can negotiate a single TS in IKEv1, don't prepend the
triggering packet TS, as we do in IKEv2. Otherwise we don't establish
the TS of the configuration, but only that of the triggering packet.
Fixes#207.
If additional authentication constraints, such as group membership,
is not fulfilled by an XAuth backend, we search for another
peer configuration that fulfills all constraints, including those
from phase1.
Martin Willi