This improves the behavior during CREATE_CHILD_SA exchanges if the peer
sends an INVALID_KE_PAYLOAD with a DH group we didn't request or continues
to return the same notify even if we use the requested group.
Fixes#2536.
If we receive an INVALID_KE_PAYLOAD notify we should not just retry
with the requested DH group without checking first if we actually propose
the group (or any at all).
After a rekeying we keep the inbound SA and policies installed for a
while, but the outbound SA and policies are already removed. Attempting
to update them could get the refcount in the kernel interface out of sync
as the additional policy won't be removed when the CHILD_SA object is
eventually destroyed.
This changes how trap policies are deleted in order to avoid conflicts if a
trap policy with changed peer config is concurrently removed and reinstalled
under a different name (the reqid will be the same, so the wrong policy
could have been deleted by the old code).
When initiating a trap policy we explicitly pass the reqid along. I guess
the lookup was useful to get the same reqid if a trapped CHILD_SA is manually
initiated. However, we now get the same reqid anyway if there is no
narrowing. And if the traffic selectors do get narrowed the reqid will be
different but that shouldn't be a problem as that doesn't cause an issue with
any temporary SAs in the kernel (this is why we pass the reqid to the
triggered CHILD_SA, otherwise, no new acquire would get triggered for
traffic that doesn't match the wider trap policy).
Reqids for the same traffic selectors are now stable so we don't have to
pass reqids of previously installed CHILD_SAs. Likewise, we don't need
to know the reqid of the newly installed trap policy as we now uninstall
by name.
The timed wait functions tested in the threading unit tests often but
randomly trigger a bit early on AppVeyor Windows containers. We allow this
if it is not earlier than 5ms.
g_variant_builder_add() creates a new GVariant using g_variant_new() and
then adds it to the builder. Passing a GVariant probably adds the
pointer to the array, not the value. I think an alternative fix would
be to use "@u" as type string for the g_variant_builder_add() call, then
the already allocated GVariant is adopted.
Fixes: 9a71b7219c ("charon-nm: Port to libnm")
With IKEv1 we transmit both public DH factors (used to derive the initial
IV) besides the shared secret. So these messages could get significantly
larger than 1024 bytes, depending on the DH group (modp2048 just about
fits into it). The new default of 2048 bytes should be fine up to modp4096
and for larger groups the buffer size may be increased (an error is
logged should this happen).
The Trusty image used by Travis was updated in December and now has Clang
5.0.0 installed. So this workaround is not necessary anymore.
This reverts commit f4bd467641.
Since version 5.5.1, different keys can be put together in
/etc/swanctl/private.
See:
* tobiasbrunner@7caba2eb5524be6b51943bcc3d2cb0e4c5ecc09a
swanctl: Add 'private' directory/section to load any type of private key
Signed-off-by: Liu Qun (liuqun) <qunliu@zyhx-group.com>
These changes improve MOBIKE task queuing. In particular we don't
want to ignore the response to an update (with NAT-D payloads) if only
an address list update or DPD is queued as that could prevent use from
updating the UDP encapsulation in the kernel.
A new optional roam trigger is added to the kernel-netlink plugin based
on routing rule changes. This only works properly, though, if the kernel
based route lookup is used as the kernel-netlink plugin does currently
not consider routing rules for its own route lookup.
Another change prevents acquires during address updates if we have to
update IPsec SAs by deleting and readding them. Because the outbound policy
is still installed an acquire and temporary SA might get triggered in
the short time no IPsec SA is installed, which could subsequently prevent the
reinstallation of the SA. To this end we install drop policies before
updating the policies and SAs. These also replace the fallback drop policies
we previously used to prevent plaintext leaks during policy updates (which
reduces the overhead in cases where addresses never or rarely change as
additional policies will only have to be tracked during address updates).
Fixes#2518.
This is really only needed for other exchanges like DPDs not when we
just updated the addresses. The NAT-D payloads are only used here to
detect whether UDP encapsulation has to be enabled/disabled.
If we have to remove and reinstall SAs for address updates (as with the
Linux kernel) there is a short time where there is no SA installed. If
we keep the policies installed they (or any traps) might cause acquires
and temporary kernel states that could prevent the updated SA from
getting installed again.
This replaces the previous workaround to avoid plaintext traffic leaks
during policy updates, which used low-priority drop policies.
This can be useful if routing rules (instead of e.g. route metrics) are used
to switch from one to another interface (i.e. from one to another
routing table). Since we currently don't evaluate routing rules when
doing the route lookup this is only useful if the kernel-based route
lookup is used.
Resolvesstrongswan/strongswan#88.
The counter does not tell us what task is actually queued, so we might
ignore the response to an update (with NAT-D payloads) if only an address
update is queued.
Instead of destroying the new task and keeping the existing one we
update any already queued task, so we don't loose any work (e.g. if a
DPD task is active and address update is queued and we'd actually like
to queue a roam task).
Tobias Brunner