| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This introduces support for specifying optional IKE SA specific
source and remote address for child sa initiation. This allows
to initiate wildcard connection for known address via vici.
In addition this allows impler implementation of trap-any patches
and is a prerequisite for dmvpn support.
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
|
|
|
|
|
| |
This makes sure we delete the right SA in case the addresses got updated
in the mean time.
|
| |
|
|
|
|
|
|
|
|
|
| |
This way updates to the mediation config are respected and the order in
which configs are configured/loaded does not matter.
The SQL plugin currently maintains the strong relationship between
mediated and mediation connection (we could theoretically change that to a
string too).
|
|
|
|
|
| |
The same goes for the start-action-job. When unrouting, we search for
the first policy with a matching child-cfg.
|
|
|
|
|
| |
This will allow us to reuse the names of child configs e.g. when they
are defined in different connections.
|
| |
|
| |
|
|
|
|
| |
This moves hydra->kernel_interface to charon->kernel.
|
|
|
|
| |
IKE_SA
|
|
|
|
|
|
|
|
|
| |
If the job gets queued for a newly created IKE_SA it might not yet be
checked in when the job is running, reschedule the job in that case.
This should fix the two p2pnat test scenarios, which occasionally
failed because one of the peers did not initiate the connection to
the mediation server.
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of just implicitly destroying the old SA we properly delete it to
notify the other peer (if the other peer keeps the SA up after the
reauthentication and sends DPDs it might consider us dead even though the
new SA is up, that seems to be the case with racoon). We delay the DELETE
a bit to give the other peer time to get the new SA fully established.
Since DELETE messages are not retransmitted it is still possible that
the other peer misses that we deleted the SA.
|
| |
|
|
|
|
|
|
| |
This is needed to handle DELETEs properly, which was previously done via
CHILD_REKEYING, which we don't use anymore since 5c6a62ceb6 as it prevents
reauthentication.
|
|
|
|
|
|
|
|
|
|
|
| |
Some clients like iOS/Mac OS X don't do a mode config exchange on the
new SA during re-authentication. If we don't adopt the previous virtual
IP Quick Mode rekeying will later fail.
If a client does do Mode Config we directly reassign the VIPs we migrated
from the old SA, without querying the attributes framework.
Fixes #807, #810.
|
|
|
|
|
|
| |
If additional tasks get queued before/while rekeying an IKE_SA, these get
migrated to the new IKE_SA. We previously did not trigger initiation of these
tasks, though, leaving the task unexecuted until a new task gets queued.
|
|
|
|
|
|
| |
While a passively installed IKE_SA does not queue a DPD timeout job, one that
switches from active to passive might execute it. Ignore such a queued job if
the IKE_SA is in passive state.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The old identifiers did not use a proper namespace and often clashed with
other defines.
|
|
|
|
|
| |
If any other IKE or CHILD_SA operation takes places, we should not start
initiating reauthentication to avoid any potential races.
|
|
|
|
|
|
|
|
|
|
|
|
| |
When doing a rekey for a CHILD_SA, the use counters get reset. An inactivity
job is queued for a time unrelated to the rekey time, so it might happen
that the inactivity job gets executed just after rekeying. If this happens,
inactivity is detected even if we had traffic on the rekeyed CHILD_SA just
before rekeying.
This change implies that inactivity checks can't handle inactivity timeouts
for rekeyed CHILD_SAs, and therefore requires that inactivity timeout is shorter
than the rekey time to have any effect.
|
|
|
|
|
| |
When a replace unique policy is in place, the children get adopted during
the uniqueness check. In this case the message is just misleading.
|
| |
|
|
|
|
| |
certain time frame
|
| |
|
|
|
|
| |
packets
|
| |
|
| |
|
|
|
|
| |
Fixes missing RADIUS Accounting Stop, #257.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
configurable.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This avoids race conditions between calls to cancel() and jobs that like
to be rescheduled. If jobs were able to reschedule themselves it would
theoretically be possible that two worker threads have the same job
assigned (the one currently executing the job and the one executing the
same but rescheduled job if it already is time to execute it), this means
that cancel() could be called twice for that job.
Creating a new job based on the current one and reschedule that is also
OK, but rescheduling itself is more efficient for jobs that need to be
executed often.
|
|
|
|
|
|
|
|
|
|
|
| |
Jobs are now destroyed by the processor, but they are allowed to
reschedule themselves. That is, parts of the reschedule functionality
already provided by callback_job_t is moved to the processor. Not yet
fully supported is JOB_REQUEUE_DIRECT and canceling jobs.
Note: job_t.destroy() is now called not only for queued jobs but also
after execution or cancellation of jobs. job_t.status can be used to
decide what to do in said method.
|
| |
|
| |
|
| |
|
| |
|
| |
|