A new global option enables sending this vendor ID to prevent Cisco
devices from narrowing the initiator's local traffic selector to the
requested virtual IP, so e.g. 0.0.0.0/0 can be used instead.
This has been tested with a "tunnel mode ipsec ipv4" Cisco template but
should also work for GRE encapsulation.
Closesstrongswan/strongswan#180.
This way we only have one reference for each CA certificate, whether it
is loaded in an authority section, a connection or via load-certs() command.
It also avoids enumerating CA certificates multiple times if they are
loaded in different ways.
With the previous approach, CA certificates that were not re-loaded via
load-cert() (e.g. from tokens or via absolute paths) would not be available
anymore after the clear-creds() command was used. This avoids this
issue, but can cause duplicate CA certificates to get stored and enumerated,
so there might be a scaling factor.
The main intention here is that we can change the hashtable_t
implementation without being impeded by the special requirements imposed
by get_match() and sorting the keys/items in buckets.
They are not marked as temporary addresses so make sure we always return
them whether temporary addresses are preferred as source addresses or not
as we need to enumerate them when searching for addresses in traffic selectors
to install routes.
Fixes: 9f12b8a61c ("kernel-netlink: Enumerate temporary IPv6 addresses according to config")
If a MOBIKE task is deferred, the retransmission counter is reset to 0
when reinitiating. So if there were retransmits before, this alert would
not be triggered if a response is received now without retransmits.
We usually have a local IP already via ike_sa_t::resolve_hosts() before
build_i() is called but if that's not the case, it's more likely we have
one after we processed the first response (it might also have changed).
There is a potential chance we still don't have one if the socket API
doesn't provide us with the destination address of received messages,
but that seems not very likely nowadays.
We need the PSK/identity already when deriving the keys in process_i().
Fixes: 1665a4e050 ("ikev1: Use actual local identity as initiator or aggressive mode responder")
Retransmission jobs for old requests for which we already received a
response previously left the impression that messages were sent more
recently than was actually the case.
task_manager_t always defined INVALID_STATE as possible return value if
no retransmit was sent, this just was never actually returned.
I guess we could further differentiate between actual invalid states
(e.g. if we already received the response) and when we don't send a
retransmit for other reasons e.g. because the IKE_SA became stale.
This is useful on Android where the app might not be able to send
keep-alives if the device is asleep for a while. If the NAT mapping
has been deleted in the mean time, the NAT-D payloads allow detecting
this and connectivity can be restored by doing a MOBIKE update or
recreating the SA if the peer already deleted it because the client
wasn't reachable.
If we fail connecting to the host we got redirected to, we should restart
with the original host where we might get redirected to a different host.
We must not reset this when retrying due to INVALID_KE_PAYLOAD or COOKIE
notifies. Since we keep the initiator SPI in those cases, we use that
flag as indicator.
Since we don't store the original remote_host value, we can't restore
that. So there is a potential conflict with MIPv6.
Closesstrongswan/strongswan#171.
Due to the exponential backoff a high number of retransmits only
makes sense if retransmit_limit is set. However, even with that there
was a problem.
We first calculated the timeout for the next retransmit and only then
compared that to the configured limit. Depending on the configured
base and timeout the calculation overflowed the range of uint32_t after
a relatively low number of retransmits (with the default values after 23)
causing the timeout to first get lower (on a high level) before constantly
resulting in 0 (with the default settings after 60 retransmits).
Since that's obviously lower than any configured limit, all remaining
retransmits were then sent without any delay, causing a lot of concurrent
messages if the number of retransmits was high.
This change determines the maximum number of retransmits until an
overflow occurs based on the configuration and defaults to UINT32_MAX
if that value is exceeded. Note that since the timeout is in milliseconds
UINT32_MAX equals nearly 50 days.
The calculation in task_manager_total_retransmit_timeout() uses a double
variable and the result is in seconds so the maximum number would be higher
there (with the default settings 1205). However, we want its result to
be based on the actual IKE retransmission behavior.
Some peers apparently don't send the notify and still expect to
authenticate with EAP-only authentication. This option allows forcing
the configured use of EAP-only authentication in that scenario.
If such a task was active while reestablishing it will get queued on the
new IKE_SA. If the DH group is already set, the DH groups won't be
stripped from the proposals and a KE payload will be sent, which is invalid
during IKE_AUTH. We don't want to reset the group if the task is part of a
child-rekey task.
Otherwise, the output is buffered when e.g. piping the output to another
command (or file). And it avoids having to call fflush() in the
interactive mode.
Fixes#3404.
The file is usually opened/created by root, however, if user/group IDs
are configured and the configuration is reloaded, the file will be reopened
as configured user. Like with UNIX sockets we only attempt to change
the user if we have CAP_CHOWN allowing a start as regular user.
We don't have chown() on Windows, so check for it.
Enables us to ignore any future kernel features for routes unless
we actually need to consider them for the source IP routes.
Also enables us to actually really skip IPsec processing for those networks
(because even the routes don't touch those packets). It's more what
users expect.
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
This is mainly an issue on FreeBSD where the current kernel still only
allows the daemon to use reqids < IPSEC_MANUAL_REQID_MAX (0x3fff = 16383).
Fixes#2315.
Charon refuses to make use of algorithms IDs from the private space
for unknown peer implementations [1]. If you chose to ignore and violate
that section of the RFC since you *know* your peers *must* support those
private IDs, there's no way to disable that behavior.
With this commit a strongswan.conf option is introduced which allows to
deliberately ignore parts of section 3.12 from the standard.
[1] http://tools.ietf.org/html/rfc7296#section-3.12
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Previously, we simply used the lifetimes of the first
proposal/transform, which is not correct if the initiator uses different
lifetimes in its proposals/transforms.
If an IKE_SA is terminated while a task is active, the delete task is
simply queued (unless the deletion is forced). If the active task times
out before any optional timeout associated with the termination hits, the
IKE_SA previously was reestablished without considering the termination
request.
Fixes#3335.
This is the recommended location and import config as it allows running the
tests against installed versions of the package. And while the test file
itself is automatically included in the source distribution this way, the
__init__.py file is not, so we still have to update MANIFEST.in.
RFC 7296, section 2.21.3:
If a peer parsing a request notices that it is badly formatted (after
it has passed the message authentication code checks and window
checks) and it returns an INVALID_SYNTAX notification, then this
error notification is considered fatal in both peers, meaning that
the IKE SA is deleted without needing an explicit Delete payload.
RFC 7296, section 2.21.3:
If a peer parsing a request notices that it is badly formatted (after
it has passed the message authentication code checks and window
checks) and it returns an INVALID_SYNTAX notification, then this
error notification is considered fatal in both peers, meaning that
the IKE SA is deleted without needing an explicit Delete payload.
This happened when installing a duplicate bypass policy for a locally
connected subnet. The destructor and the kernel-net part already
handle this correctly.
This avoids having to register certificates with authority/ca backends
beforehand, which is tricky for intermediate CA certificates loaded
themselves via authority/ca sections. On the other hand, the form of
these URLs can't be determined by config backends anymore (not an issue
for the two current implementations, no idea if custom implementations
ever made use of that possibility). If that became necessary, we could
perhaps pass the certificate to the CDP enumerator or add a new method
to the credential_set_t interface.
Don't define structs for macOS as we don't need them (that's true for
most of the others too, though) and at least one is defined inside an extra
ifdef.
If a CHILD_SA is terminated, the updown event is triggered after the
CHILD_SA is set to state CHILD_DELETED, so no usage stats or detail
information like SPIs were reported. However, when an IKEv2 SA is
terminated, the updown event for its children is triggered without
changing the state first, that is, they usually remain in state
INSTALLED and detailed data was reported in the event. IKEv1
CHILD_SAs are always terminated individually, i.e. with state
change and no extra data so far.
With this change usage stats are also returned for individually deleted
CHILD_SAs as long as the SA has not yet expired.
Fixes#3198.
Many of the messages sent by the kernel, including confirmations to our
requests, are sent as broadcasts to all PF_KEY sockets. So if an
external tool is used to manage SAs/policies (e.g. unrelated to IPsec)
the receive buffer might be filled, resulting in errors like these:
error sending to PF_KEY socket: No buffer space available
To avoid this, just clear the buffer before sending any message.
Fixes#3225.
This avoids having to call strip_dh() in child_cfg_t::get_proposals().
It also inverts the ALLOW_PRIVATE flag (i.e. makes it SKIP_PRIVATE) so
nothing has to be supplied to clone complete proposals.
During proposal selection with ike/child_cfgs a couple of boolean
variables can be set (e.g. private, prefer_self, strip_dh). To simplify
the addition of new parameters, these functions now use a set of flags
instead of indiviual boolean values.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
There seem to be servers around that, upon receiving a delete from the
client, instead of responding with an empty INFORMATIONAL, send a delete
themselves.
This patch adds passing the ESN flag to the kernel if ESN was negotiated
and the appropriate flag is present in the kernel headers, which will
be the case in future FreeBSD releases.
Signed-off-by: Patryk Duda <pdk@semihalf.com>
Closesstrongswan/strongswan#155.
The unique names were introduced for the list-sas command in commit
04c0219e55. However, the child-updown
event wasn't updated to match. Even though the documentation suggests
that the section name of the CHILD_SAs are the same in both messages.
The original name is already being returned in the "name" attribute,
so it'll still be available.
Example:
>>> import vici, json
>>> s = vici.Session()
# First, for comparison, the list-sas command:
>>> print(json.dumps(list(s.list_sas()), sort_keys=True, indent=4, separators=(',', ': ')))
[
{
"vti0": {
"child-sas": {
"vti0-1": {
...
# A child-updown event before the change:
>>> for x in s.listen(["child-updown"]): print(json.dumps(x, sort_keys=True, indent=4, separators=(',', ': ')))
[
"child-updown",
{
"vti0": {
"child-sas": {
"vti0": { # <-- wrong: inconsistent with list-sas
...
# A child-updown event after the change:
>>> s = vici.Session()
>>> for x in s.listen(["child-updown"]): print(json.dumps(x, sort_keys=True, indent=4, separators=(',', ': ')))
[
"child-updown",
{
"vti0": {
"child-sas": {
"vti0-1": { # <-- fixed
Closesstrongswan/strongswan#153.
As specified by RFC 7296, section 2.6, the data associated with COOKIE
notifications MUST be between 1 and 64 octets in length (inclusive).
Fixes#3160.
This allows using the certificate, which is technically a CA cert, as
end-entity certificate again after the RFC4945-related changes added
with 5.6.3.
Fixes#3139.
Tobias Brunner