| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The re-authentication is now handled within the original IKE_SA if it has not
yet been established, so we don't want to destroy it.
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Original patch courtesy of Vyronas Tsingaras.
|
| |
|
| |
|
| |
|
|
|
|
| |
We now prefer MOBIKE tasks over delete tasks then the rest.
|
|
|
|
|
|
|
|
| |
This reverts commit 3293d146289d7c05e6c6089ae1f7cdbcea378e63.
The position of tasks in the queue does not actually determine the order
in which they are activated. Instead this is determined by the
statements in task_manager_v2_t.initiate().
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The MOBIKE task is active during the initial exchanges but we don't want
to treat them as actual MOBIKE exchanges (i.e. there is no path probing).
|
|
|
|
|
|
|
|
|
| |
We don't expect a response with the same MID, but apparently some
devices (e.g. FRITZ!Box) do that for DPDs, while still treating the
response as a new exchange. By storing the last message block as IV
we can't decrypt the first block of such a response.
Fixes #661.
|
| |
|
|
|
|
| |
Fixes #661.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While the examples in RFC 2408 show proposal numbers starting at 1 and
increasing by one for each subsequent proposal this is not mandatory.
Actually, IKEv1 proposals may start at any number, the only requirement
is that the proposal numbers increase monotonically they don't have to
do so consecutively.
Most implementations follow the examples and start numbering at 1 (charon,
racoon, Shrew, Cisco, Windows XP, FRITZ!Box) but pluto was one of the
implementations that started with 0 and there might be others out there.
The previous assumption that implementations always start numbering proposals
at 0 caused problems with clients that start numbering with 1 and whose first
proposal consists of multiple protocols (e.g. ESP+IPComp).
Fixes #661.
|
| |
|
| |
|
|
|
|
| |
Path probing is enabled if the current path is not available anymore.
|
|
|
|
|
| |
We do the same before initiating the task, so we should probably do it
too when we already initiated it, not just time out and destroy the SA.
|
| |
|
|
|
|
|
|
|
| |
This might not be the case if e.g. an address appeared but the old one
is still available but not actually usable. Without this the MOBIKE
task would eventually time out even though we might be able to switch
to a working address.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
In case we have no usable path to the other peer there is no point in
initiating any other tasks (like rekeying).
|
|
|
|
|
| |
This will probably never be more than 1 since we only have one task queued
at a time and we don't migrate running tasks.
|
|
|
|
|
|
|
|
| |
Because we only queue one MOBIKE task at a time, but destroy superfluous
ones only after we already increased the counter for pending MOBIKE updates,
we have to reduce the counter when such tasks are destroyed. Otherwise, the
queued task would assume another task is queued when it is running and
ignore any successful response.
|
|
|
|
|
| |
If ESP proposals are added once with and once without DH groups
duplicates result during IKE_AUTH when DH groups are stripped.
|
| |
|
|
|
|
| |
Fixes #677.
|
|
|
|
| |
References #557.
|
|
|
|
|
|
|
|
| |
Due to how reauthentication works for IKEv1 we could get a second
IKE_SA, which might cause problems, when connectivity problems arise
when the connection is initially established.
Fixes #670.
|
|
|
|
|
|
|
| |
The adopt_children_job_create() function is not available when IKEv1 support
is disabled. Fixes uncommon builds using --enable-ha --disable-ikev1.
Fixes #690.
|
|
|
|
|
|
|
| |
When having the unity plugin enabled and both peers send the Unity Vendor ID,
we proposed 0.0.0.0/0 as traffic selector, even if no Split-Include has been
received on the SA. This can break compatibility with some responders, as
they don't narrow the TS themselves, but expect the configured TS.
|
|
|
|
|
|
| |
Since the narrow hook types reflect the roles in the Quick Mode exchange
the plugin behaved incorrectly if the server initiated the CHILD_SA
rekeying.
|
| |
|
|
|
|
|
|
|
|
| |
When an initiator starts reauthentication on a connection that uses push
mode to assign a virtual IP, we can't execute the Mode Config before releasing
the virtual IP. Otherwise we would request a new and different lease, which
the client probably can't handle. Defer Mode Config execution, so the same IP
gets first released then reassigned during reauthentication.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
If a peer immediately sends DELETE messages when completing Quick Mode rekeying,
the third Quick Mode message and the DELETE are sent simultaneously. This
implies that DELETE messages may arrive before the completing third Quick Mode
message.
Handle this case by ignoring the DELETE INFORMATIONAL in Quick Mode and let
the delete task handle it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To check if a received IKE_SA_INIT request is a new request or a
retransmit, charon maintains hashes of the pending IKE_SA_INIT
exchanges.
However, the hash calculation is not reentrant because a single hasher
is used for the whole IKE SA manager. It leads to bogus calculations
under high load and hence dropped messages on responder
(IkeInInvalidSpi incremented).
Don't share a single hasher in the IKE SA manager, create a transient
one whenever a message must be hashed.
Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
|
|
|
|
|
| |
The old hook is renamed to ike_reestablish_post and is now also called
when the initiation of the new IKE_SA failed.
|
|
|
|
|
|
|
|
|
| |
We sent both a notify using IKEv1 and IKEv2. This is a little more aggressive
than required, RFC 5996 says we "SHOULD send an unauthenticated Notify
message of type INVALID_MAJOR_VERSION containing the highest (closest) version
number it supports".
Fixes #657.
|
|
|
|
| |
Fixes #631.
|
| |
|