| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this implements gre key negotiation in ikev1 similarly to the
ipsec-tools patch in alpine.
the from/to port pair is internally used as gre key for gre
protocol traffic selectors. since from/to pairs 0/0xffff and
0xffff/0 have special meaning, the gre keys 0xffff and 0xffff0000
will not work.
this is not standard compliant, and should probably not be upstreamed
or used widely, but it is applied for interoperability with alpine
racoon for the time being.
|
|
|
|
|
|
|
|
|
|
|
| |
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 prevents new SAs from getting created if we hit the global IKE_SA
limit (we still allow checkout_new(), which is used for rekeying).
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Due to circular references the hasher_from_signature_scheme() helper
does not take a signature_params_t object.
|
|
|
|
|
| |
This also required some include restructuring (avoid including library.h
in headers) to avoid unresolvable circular dependencies.
|
| |
|
| |
|
|
|
|
|
|
| |
RFC 8247 demoted it to MUST NOT.
References #2427.
|
| |
|
|
|
|
| |
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
|
| |
|
|
|
|
|
|
|
| |
We do something similar in reestablish() for break-before-make reauth.
If we don't abort we'd be sending an IKE_AUTH without any TS payloads.
References #2430.
|
| |
|
|
|
|
|
|
|
| |
This causes problems e.g. on Android where we handle the alert (and
reestablish the IKE_SA) even though it usually is no problem if the
peer retries with the requested group. We don't consider it as a
failure on the initiator either.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In case we send retransmits for an IKE_SA_INIT where we propose a DH
group the responder will reject we might later receive delayed responses
that either contain INVALID_KE_PAYLOAD notifies with the group we already
use or, if we retransmitted an IKE_SA_INIT with the requested group but
then had to restart again, a KE payload with a group different from the
one we proposed. So far we didn't change the initiator SPI when
restarting the connection, i.e. these delayed responses were processed
and might have caused fatal errors due to a failed DH negotiation or
because of the internal retry counter in the ike-init task. Changing
the initiator SPI avoids that as we won't process the delayed responses
anymore that caused this confusion.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When requiring unique flags for CHILD_SAs, allow the configuration to
request different marks for each direction by using the %unique-dir keyword.
This is useful when different marks are desired for each direction but the
number of peers is not predefined.
An example use case is when implementing a site-to-site route-based VPN
without VTI devices.
A use of 0.0.0.0/0 - 0.0.0.0/0 traffic selectors with identical in/out marks
results in outbound traffic being wrongfully matched against the 'fwd'
policy - for which the underlay 'template' does not match - and dropped.
Using different marks for each direction avoids this issue as the 'fwd' policy
uses the 'in' mark will not match outbound traffic.
Closes strongswan/strongswan#78.
|
|
|
|
|
|
|
|
| |
Initiation might later fail, of course, but we don't really
require an IP address when installing, that is, unless the remote
traffic selector is dynamic. As that would result in installing a
0.0.0.0/0 remote TS which is not ideal when a single IP is expected as
remote.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
This splits the SA installation also on the initiator, so we can avoid
installing the outbound SA if we lost a rekey collision, which might
have caused traffic loss depending on the timing of the DELETEs that are
sent in both directions.
|
| |
|
| |
|
|
|
|
| |
References #2377.
|
|
|
|
|
|
|
|
| |
This way we get the log message in stroke and swanctl as last message
when establishing a connection. It's already like this for the IKE_SA
where IKE_ESTABLISHED is set after the corresponding log message.
Fixes #2364.
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
This avoids the unportable five pointer hack.
|
|
|
|
| |
This avoids the unportable five pointer hack.
|
|
|
|
|
| |
This avoids the unportable 5 pointer hack, but requires enumerating in
the callback.
|
| |
|
|
|
|
|
|
|
|
| |
The correct truncation is 128-bit but some implementations insist on
using 96-bit truncation. With strongSwan this can be negotiated using
an algorithm identifier from a private range. But this doesn't work
with third-party implementations. This adds an option to use 96-bit
truncation even if the official identifier is used.
|
|
|
|
|
|
|
|
| |
After deleting a rekeyed CHILD_SA we uninstall the outbound SA but don't
destroy the CHILD_SA (and the inbound SA) immediately. We delay it
a few seconds or until the SA expires to allow delayed packets to get
processed. The CHILD_SA remains in state CHILD_DELETING until it finally
gets destroyed.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The responder has all the information needed to install both SAs before
the initiator does. So if the responder immediately installs the outbound
SA it might send packets using the new SA which the initiator is not yet
able to process. This can be avoided by delaying the installation of the
outbound SA until the replaced SA is deleted.
|
| |
|