| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
This makes handling such IKE_SAs more specifically compared to keeping them
in state IKE_CONNECTING or IKE_ESTABLISHED (which we did when we lost a
collision - even triggering the ike_updown event), or using IKE_REKEYING for
them, which would also be ambiguous.
For instance, we can now reject anything but DELETES for such SAs.
|
|
|
|
|
|
|
|
|
| |
This is the case for the IKE_SA_INIT and the initial IKEv1 messages, which
are pre-generated in tasks as at least parts of it are used to generate
the AUTH payload. The IKE_SA_INIT message will never be fragmented, but
the IKEv1 messages might be, so we can't just call generate_message().
Fixes #1478.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
If the SA got redirected this would otherwise cause a reauthentication with
the original gateway. Reestablishing the SA to the original gateway, if e.g.
the new gateway is not reachable makes sense though.
|
| |
|
|
|
|
|
|
|
| |
We handle this similar to how we do reestablishing IKE_SAs with all CHILD_SAs,
which also includes the one actively queued during IKE_AUTH.
To delete the old SA we use the recently added ike_reauth_complete task.
|
| |
|
| |
|
| |
|
|
|
|
| |
This moves hydra->kernel_interface to charon->kernel.
|
|
|
|
| |
IKE_SA
|
|
|
|
|
|
|
|
| |
If there is no path to the other peer there is no point in trying to
send a NAT keepalive.
If the condition changes back and forth within the keepalive interval there
is a chance that multiple jobs get queued.
|
|
|
|
|
|
| |
When reestablishing the IKE_SA we should still use the original port
when right resolves to %any as some implementations might not like
initial IKE messages on port 4500 (especially for IKEv1).
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
In some situations it might be valid for a host that configures
right=%any to reestablish or reauthenticate an IKE_SA. Using %any would
immediately abort the initiation causing the new SA to fail (which
might already have the existing CHILD_SAs assigned).
Fixes #1027.
|
|
|
|
|
|
|
| |
If static local addresses are configured we should use their address family
as a hint when resolving the remote address.
We don't do this if %any is configured as this might break existing
configurations (%any4 and %any6 are however used as hint).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
We assume that a responder is behind a static NAT (e.g. port forwarding)
and allow remote address updates in such situations.
The problem described in RFC 5996 is only an issue if the NAT mapping
can expire.
|
|
|
|
|
|
|
|
| |
I still think ipsec/l2tp with fragmentation support is a useful
fallback option in case the Windows IKEv2 connection fails because
of fragmentation problems.
Tested with Windows XP, 7 and 8.1.
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
| |
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 old hook is renamed to ike_reestablish_post and is now also called
when the initiation of the new IKE_SA failed.
|
|
|
|
|
|
|
|
|
| |
Similar to assign_vips() used by a peer assigning virtual IPs to the other peer,
the handle_vips() hook gets invoked on a peers after receiving attributes. On
release of the same attributes the hook gets invoked again.
This is useful to inspect handled attributes, as the ike_updown() hook is
invoked after authentication, when attributes have not been handled yet.
|
| |
|
| |
|
|
|
|
|
|
| |
The extensions and conditions apply to the rekeyed IKE_SA as well, so we should
migrate them. Especially when using algorithms from private space, we need
EXT_STRONGSWAN to properly select these algorithms during IKE rekeying.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This avoids a second name resolution attempt just to determine if %any
etc. was configured.
Fixes #440.
|
|
|
|
|
|
| |
Was wrong since 0edce687675df8f10f4026fa12a8fc3b3dd003f5.
Fixes #440.
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
| |
Some peers seem to defer DELETEs a few seconds after rekeying the IKE_SA, which
is perfectly valid. For short(er) DPD delays, this leads to the situation where
we send a DPD request during set_state(), but the IKE_SA has no hosts set yet.
Avoid that DPD by resetting the INBOUND timestamp during set_state().
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
a3854d83 changed cleanup order. But we should remove CHILD_SAs first, as routes
for CHILD_SAs might get deleted while removing virtual IPs, resulting in
an error when a CHILD_SA tries to uninstall its route.
|
| |
|