| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
If we find a redundant CHILD_SA (the peer probably rekeyed the SA before
us) we might not want to delete the old SA because the peer might still
use it (same applies to old CHILD_SAs after rekeyings). So only delete
them if configured to do so.
Fixes #2358.
|
| |
|
|
|
|
|
| |
Also adds an optional limit to avoid very high retransmission timeouts
with high numbers of retries.
|
|
|
|
|
|
|
|
|
| |
Some devices always use the oldest IKE_SA to send DPDs and will delete
all IKE_SAs when there is no response. If uniqueness is not enforced
rekeyed IKE_SAs might not get deleted until they expire so we should
respond to DPDs.
References #2090.
|
| |
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
|
|
|
|
| |
one retransmit
The counter is already increased when sending the original message.
Fixes: bd71ba0ffb03 ("task-manager: Add retransmit cleared alert")
|
|
|
|
| |
It does not have any CHILD_SAs attached at that point.
|
|
|
|
|
| |
After the ISAKMP_DELETE task has been executed the IKE_SA is destroyed
so we wouldn't be able to send deletes for the Quick Mode SAs.
|
|
|
|
|
|
|
|
|
|
|
| |
By aborting the active task we don't have to wait for potential
retransmits if the other peer does not respond to the current task.
Since IKEv1 has no sequential message IDs and INFORMATIONALs are no real
exchanges this should not be a problem.
Fixes #1537
References #429, #1410
Closes strongswan/strongswan#48
|
|
|
|
|
|
|
|
|
|
|
| |
Such a task is not initiated unless a certain time has passed. This
allows delaying certain tasks but avoids problems if we'd do this
via a scheduled job (e.g. if the IKE_SA is rekeyed in the meantime).
If the IKE_SA is rekeyed the delay of such tasks is reset when the
tasks are adopted i.e. they get executed immediately on the new IKE_SA.
This hasn't been implemented for IKEv1 yet.
|
| |
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
|
|
|
|
|
|
| |
Some peers send an INITIAL_CONTACT notify after they received our XAuth
username. The XAuth task waiting for the third XAuth message handles
this incorrectly and closes the IKE_SA as no configuration payloads are
contained in the message. We queue the INFORMATIONAL until the XAuth
exchange is complete to avoid this issue.
Fixes #1434.
|
|
|
|
| |
Fixes #1410.
|
|
|
|
| |
Fixes #1421.
|
| |
|
|
|
|
|
| |
A DPD timeout job is queued whenever a DPD is sent, i.e. after the
DPD delay already has elapsed, so we have to compensate for that.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
message
|
|
|
|
|
|
|
|
|
|
|
|
| |
are handled delayed
If we haven't received the third QM message for multiple exchanges the
return value of NEED_MORE for passive tasks that are not responsible for
a specific exchange would trigger a fourth empty QM message.
Fixes: 4de361d92c54 ("ikev1: Fix handling of overlapping Quick Mode exchanges")
References #1076.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases the third message of a Quick Mode exchange might arrive
after the first message of a subsequent Quick Mode exchange. Previously
these messages were handled incorrectly and the second Quick Mode
exchange failed.
Some implementations might even try to establish multiple Quick Modes
simultaneously, which is explicitly allowed in RFC 2409. We don't fully
support that, though, in particular in case of retransmits.
Fixes #1076.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
As we now use the same reqid for multiple CHILD_SAs with the same selectors,
having marks based on the reqid makes not that much sense anymore. Instead we
use unique marks that use a custom identifier. This identifier is reused during
rekeying, keeping the marks constant for any rule relying on it (for example
installed by updown).
This also simplifies handling of reqid allocation, as we do not have to query
the marks that is not yet assigned for an unknown reqid.
|
| |
|
|
|
|
|
|
|
|
|
| |
The message() hook on bus_t is now called exactly once before (plain) and
once after fragmenting (!plain), not twice for the complete message and again
for each individual fragment, as was the case in earlier iterations.
For inbound messages the hook is called once for each fragment (!plain)
and twice for the reassembled message.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
At the time we reset an IKE_SA (e.g. when re-authenticating a not yet
established SA due to a roaming event) such tasks might already be queued
by one of the phase 1 tasks. If the SA is initiated again another task will
get queued by the phase 1 task. This results in e.g. multiple mode config
requests, which most gateways will have problems with.
|
|
|
|
|
| |
The old identifiers did not use a proper namespace and often clashed with
other defines.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This patch exports the task manager's flush to allow flushing of all
queues with one function call from ike_sa->destroy. It allows the
access of intact children during task destructoin (see git-commit
e44ebdcf) and allows the access of the task manager in
child_state_change hook.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
| |
Fixes CVE-2013-6076.
|
|
|
|
| |
Fixes #411.
|
| |
|
|
|
|
| |
The old code resulted in too few fragments in some cases.
|
|
|
|
|
| |
This is same same logic used by sender and might apply in some cases (e.g.
when initiating to port 4500).
|
| |
|
|
|
|
|
| |
Not directly returning a linked list allows us to change the internals of
the CHILD_SA transparently.
|
| |
|
| |
|
|
|
|
| |
Initial patch by Paul Stewart, fixes #289.
|
|
|
|
|
|
|
| |
When the last request message of the initial tunnel setup is retransmitted,
we must retransmit the response instead of ignoring the request.
Fixes #295.
|
|
|
|
| |
This applies for error notifies.
|
| |
|
| |
|