| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
This way we only have to pass the traffic selectors once.
|
|
|
|
| |
Only install outbound fallback policies.
|
|
|
|
|
| |
This makes sure we use the same set of traffic selectors when installing
the SAs and installing the policies.
|
| |
|
|
|
|
|
| |
Also adds an optional limit to avoid very high retransmission timeouts
with high numbers of retries.
|
| |
|
|
|
|
| |
Makes it potentially easier to add new flags.
|
|
|
|
|
|
|
|
| |
Much like in commit a68454b, we now use a global atomic counter to keep
track of the number of IKE_SAs currently registered. This should improve
scalability for a large number of segments even more.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
| |
|
|
|
|
|
|
|
|
| |
This provides a solution for configs where there is e.g. a catch-all %any
PSK, while more specific PSKs would be found by the identities of configs
that e.g. use FQDNs as local/remote addresses.
Fixes #2223.
|
|
|
|
|
|
|
| |
Memory is allocated with calloc, hence set to zero, thus assigning the
numerical value 0 is not required.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
|
|
| |
The initiator's address was sent back twice previously.
Fixes #2268.
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When multihomed, a setup might prefer to dynamically stay on the cheapest
available path by using MOBIKE migrations. If the cheapest path goes away and
comes back, we currently stay on the more expensive path to reduce noise and
prevent potential migration issues. This is usually just fine for links not
generating real cost.
If we have more expensive links in the setup, it can be desirable to always
migrate to the cheapest link available. By setting charon.prefer_best_path,
charon tries to migrate to the path using the highest priority link, allowing
an external application to update routes to indirectly control MOBIKE behavior.
This option has no effect if MOBIKE is unavailable.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disabling MOBIKE and statically configuring a local address should be
enough indication that the user doesn't want to roam to a different
address. There might not be any routes that indicate we can use the
current address but it might still work (e.g. if the address is on an
interface that is not referenced in any routes and the address itself
is neither). This way we avoid switching to another address for routes
that might be available on the system.
We currently don't make much use of COND_STALE anyway when MOBIKE is not
enabled, e.g. to avoid sending DPDs if the connection is seemingly down.
With MOBIKE enabled we don't exactly check that state but we do don't
send DPDs if there is no route/source address available.
|
|
|
|
|
| |
This will allow us to reuse the names of child configs e.g. when they
are defined in different connections.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The SA ID (src, dst, proto, spi) is unique on ingress.
As such, explicit inbound marking is not needed to match an SA.
On the other hand, requiring inbound SAs to use marks forces the
installation of a mechanism for marking traffic (e.g. iptables) based
on some criteria.
Defining the criteria becomes complicated, for example when required to
support multiple SAs from the same src, especially when traffic is UDP
encapsulated.
This commit removes the assignment of the child_sa mark_in to the inbound SA.
Policies can be arbitrated by existing means - e.g, via netfilter policy
matching or using VTI interfaces - without the need to classify the flows prior
to state matching.
Since the reqid allocator regards the mark value, there is no risk of matching
the wrong policy.
And as explicit marking was required for route-based VPN to work before this
change, it should not cause regressions in existing setups.
Closes strongswan/strongswan#59.
|
|
|
|
|
|
|
|
|
|
| |
If this is the first message by the peer, i.e. we expect MID 0, the
message is not pre-processed in the task manager so we ignore it in the
task.
We also make sure to ignore such messages if the extension is disabled
and the peer already sent us one INFORMATIONAL, e.g. a DPD (we'd otherwise
consider the message with MID 0 as a retransmit).
|
|
|
|
|
|
|
|
| |
If the responder never sent a message the expected MID is 0. While
the sent MID (M1) SHOULD be increased beyond the known value, it's
not necessarily the case.
Since M2 - 1 would then equal UINT_MAX setting that MID would get ignored
and while we'd return 0 in the notify we'd actually expect 1 afterwards.
|
| |
|
|
|
|
|
|
| |
We are very picky to only allow MID 0 for these messages (while we
currently don't support IPSEC_REPLAY_COUNTER_SYNC notifies we accept
them).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This simplifies implementing a custom keymat_v1_t.
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
|
|
| |
Such an identity won't equal an actual peer's identity resulting in
sending an INITIAL_CONTACT notify even if there might be an existing
IKE_SA.
|
| |
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
|
|
|
| |
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")
|
|
|
|
| |
Fixes #2051.
|
|
|
|
|
|
|
|
|
|
| |
If a responder is natted it will usually be a static NAT (unless it's a
mediated connection) in which case adding these notifies makes not much
sense (if the initiator's NAT mapping had changed the responder wouldn't
be able to reach it anyway). It's also problematic as some clients refuse
to respond to DPDs if they contain such notifies.
Fixes #2126.
|
|
|
|
| |
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.
|
|
|
|
|
|
| |
If we silently delete the IKE_SA the other peer might still use it even
if only to send DPDs. If we don't answer to DPDs that might result in the
deletion of the new IKE_SA too.
|
|
|
|
|
|
| |
This is the minimum size an IPv6 implementation must support. This makes
it the default for IPv4 too, which presumably is also generally routable
(otherwise, setting this to 0 falls back to the minimum of 576 for IPv4).
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
They are only required if drop policies would otherwise prevent
forwarding traffic. This reduces the number of policies and avoids
conflicts e.g. with SPD hash thresholds.
|
| |
|
|
|
|
|
|
|
|
|
| |
Some tasks might get removed immediately once the IKE_SA_INIT response has
been handled even if there were notifies that require a restart of the
IKE_SA (e.g. COOKIE or INVALID_KE_PAYLOAD). Such a task is ike_vendor,
which caused vendor IDs not to get sent in a retry. This change ensures
all required tasks are queued after the reset, which some callers did
already anyway.
|
|
|
|
| |
This might be useful for custom implementations of keymat_t.
|
|
|
|
|
|
|
|
|
| |
These seem to indicate the major and minor version of the protocol, like
e.g. for the DPD vendor ID. Some implementations seem to send versions
other than 1.0 so we just ignore these for now when checking for known
vendor IDs.
Fixes #2088.
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
| |
Depending on the lifetimes a CHILD_SA we rekeyed as responder might
expire shortly afterwards. We don't want to rekey it again.
When retrying due to an INVALID_KE_PAYLOAD notify the expected state
is CHILD_REKEYING if it is anything else (e.g. due to a collision) we
ignore it.
We also abort the exchange properly if we don't find the CHILD_SA, no
need for an empty INFORMATIONAL exchange anymore.
|
|
|
|
|
|
|
| |
If a passive rekeying fails due to an INVALID_KE_PAYLOAD we don't want
to consider this task later when resolving collisions. This previously
might have caused the wrong SA to get deleted/installed based on the nonces
in the unsuccessful exchange.
|