Every reqid is allocated once, we don't store the same reqid with e.g.
different marks or interface IDs that would make it necessary to make
them part of the key in that table (that's different in the other table).
To preserve the current behavior, that is, allocating a new reqid if e.g.
the marks are different, the additional selector values (which will
result in an additional policy in the Linux kernel) are compared after
the initial lookup.
Since the referenced commit, the state switch to IKE_ESTABLISHED doesn't
happen immediately after completing the authentication but only after
the remaining tasks have finished. Due to that redirects during IKE_AUTH
were treated like those during IKE_SA_INIT causing the IKE_SA and task
manager to get reset. However, unlike the ike-init task, the ike-auth
task returned SUCCESS and, therefore, got destroyed, while a different
task was removed from the array that was modified during the reset.
This later caused a dereference of the freed ike-auth task and a crash.
Fixes: 5ce1c91b58 ("ikev2: Trigger ike_updown() event after all IKE-specific tasks ran")
This works around an issue that occurs when recreating an IKE_SA with
multiple CHILD_SAs that use dynamically allocated reqids.
We currently try to preserve the reqid when reestablishing, so the
create-child task gets the reqid of the previous CHILD_SA and will try
to reallocate that once the CHILD_SA is installed. Before that, the old
CHILD_SA is destroyed and the reqid is released and added to the array
of reqids to get reused. However, because of the reverse order used here,
the first reqid in the array is the one of the last CHILD_SA.
So it can happen that a newly created CHILD_SA gets a reqid reassigned
that a later CHILD_SA will then also claim for itself and get assigned
because an entry with that reqid exists. So multiple CHILD_SAs with
different traffic selectors could then share the same reqid.
References strongswan/strongswan#1855
Fixes a problem installing policies with source traffic selectors that do
not contain/match any of the local addresses.
When installing a route for a source TS that does contain one or more
local addresses, a preferred source address should be set in the route
(analogous to the `src` option in `ip route add`). This address is used
when the host itself sends traffic via that route (in contrast to
forwarding it).
When the source TS does not encompass any of the local addresses, the
host is not allowed to send traffic via this route and does not need to
set the preferred source address. However, the code would just return a
failure because it could not find a matching local address. This commit
changes this so routes without preferred source IP are installed to
allow non-local traffic to get forwarded via TUN device.
Closesstrongswan/strongswan#1766
socket.connect() takes a single argument with the address that depends
on the address family, for TCP it's a tuple with IP and port.
Fixes: 00a75e332f ("vici: Create default TCP socket on Windows in Python bindings")
Closesstrongswan/strongswan#1874
When adding a virtual IP on a TUN interface, the interface might get
activated (in terms of receiving the event) after we've already set the
virtual flag for the added address. As the activation repopulates the
addresses on the interface, this cleared the flag and the address would
no longer be treated as virtual IP when installing routes for CHILD_SAs
that reference it in their local traffic selectors.
Closesstrongswan/strongswan#1807
Also simplify how we try to exceed the system-wide maximum. We basically
just try to force the value and simply fall back to the regular call.
The kernel actually won't let the latter fail if the value is too big,
it just caps it at the internal maximum.
We track all IKE_SA_INIT requests as half-open IKE_SAs but didn't
correctly untrack them if their message ID or responder SPI was non-zero.
References strongswan/strongswan#1775
Fixes: b866ee88bf ("ike: Track unprocessed initial IKE messages like half-open IKE_SAs")
As specified in RFC 7296, section 2.25:
The SA that the initiator attempted to rekey is indicated by the SPI
field in the Notify payload, which is copied from the SPI field in
the REKEY_SA notification.
So we copy that and the protocol verbatim.
The get_spi_data() method is currently not used, so that has been
simplified so it can be used for any protocol type and any SPI length.
Same for set_spi_data(), which is currently used for IKEv1 to encode
two SPIs.
Since 17fd304e60 ("resolve: Don't install individual servers via
resolvconf"), DNS servers were sorted if getting installed via resolvconf.
In some setups the order might be important (even though relying on it
isn't a good idea in general as stub resolvers are free to use all of
the servers as they please).
This is currently only supported on Linux and with the appropriate
permissions.
Since it's experimental, it's disabled by default.
The log messages for each sent and received ESP message are logged in NET
like the ones in the socket-default plugin for UDP-encapsulated messages.
The calculation of the timeout is also shared now and the total
timeout in seconds is corrected in case retransmit_base is <= 1.
This could make it easier in the future to apply different retransmission
settings to messages/exchanges.
When we reset the initiator SPI, we have to migrate the adopted children
again so the correct IKE_SA can later be checked out.
Closesstrongswan/strongswan#1663
Tobias Brunner