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.
A temporary DROP policy is added to avoid traffic leak
while the SA is being updated. It is added with
manual_prio set but when the temporary policy is removed
it is removed with manual_prio parameter set to 0.
The call to del_policies_outbound does not match the original
policy and we end up with an ever increasing refcount.
If we try to manually remove the policy, it is not removed
due to the positive refcount. Then new SA requests fail with
"unable to install policy out for reqid 1618,
the same policy for reqid 1528 exists"
Fixes: 35ef1b032d ("child-sa: Install drop policies while updating IPsec SAs and policies")
Closesstrongswan/strongswan#129.
For inbound processing, it can be rather useful to apply the mark to the
packet in the SA, so the associated policy with that mark implicitly matches.
When using %unique as match mark, we don't know the mark beforehand, so
we most likely want to set the mark we match against.
The options control whether the DF and ECN header bits/fields are copied
from the unencrypted packets to the encrypted packets in tunnel mode (DF only
for IPv4), and for ECN whether the same is done for inbound packets.
Note: This implementation only works with Linux/Netlink/XFRM.
Based on a patch by Markus Sattler.
Although being already logged on level 2, these messages are usually just
confusing if they pop up randomly in the log when e.g. querying the configs
or installing traps. So after this the log messages will only be logged when
actually proposing or selecting traffic selectors during IKE.
Until now the configuration available to user for HW offload were:
hw_offload = no
hw_offload = yes
With this commit users will be able to configure auto mode using:
hw_offload = auto
Signed-off-by: Adi Nissim <adin@mellanox.com>
Reviewed-by: Aviv Heller <avivh@mellanox.com>
After a rekeying we keep the inbound SA and policies installed for a
while, but the outbound SA and policies are already removed. Attempting
to update them could get the refcount in the kernel interface out of sync
as the additional policy won't be removed when the CHILD_SA object is
eventually destroyed.
When initiating a trap policy we explicitly pass the reqid along. I guess
the lookup was useful to get the same reqid if a trapped CHILD_SA is manually
initiated. However, we now get the same reqid anyway if there is no
narrowing. And if the traffic selectors do get narrowed the reqid will be
different but that shouldn't be a problem as that doesn't cause an issue with
any temporary SAs in the kernel (this is why we pass the reqid to the
triggered CHILD_SA, otherwise, no new acquire would get triggered for
traffic that doesn't match the wider trap policy).
If we have to remove and reinstall SAs for address updates (as with the
Linux kernel) there is a short time where there is no SA installed. If
we keep the policies installed they (or any traps) might cause acquires
and temporary kernel states that could prevent the updated SA from
getting installed again.
This replaces the previous workaround to avoid plaintext traffic leaks
during policy updates, which used low-priority drop policies.
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.
Closesstrongswan/strongswan#78.
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.
Using install() for the inbound SA and register_outbound() for the
outbound SA followed by install_policies(), will delay the installation of
the outbound SA as well as the installation of the outbound policies
in the kernel until install_outbound() is called later.
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.
Closesstrongswan/strongswan#59.
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.
If two CHILD_SAs with mark=%unique are created concurrently they could
otherwise end up with either the same mark or different marks in both
directions.
This provides a fix if symmetrically overlapping policies are
installed as e.g. the case in the ikev2/ip-two-pools-db scenario:
carol 10.3.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
alice 10.4.0.1/32 ----- 10.3.0.0/16, 10.4.0.0/16 moon
Among others, the following FWD policies are installed on moon:
src 10.3.0.1/32 dst 10.4.0.0/16
...
tmpl ...
src 10.4.0.0/16 dst 10.3.0.1/32
...
src 10.4.0.1/32 dst 10.3.0.0/16
...
tmpl ...
src 10.3.0.0/16 dst 10.4.0.1/32
...
Because the network prefixes are the same for all of these they all have the
same priority. Due to that it depends on the install order which policy gets
used. For instance, a packet from 10.3.0.1 to 10.4.0.1 will match the
first as well as the last policy. However, when handling the inbound
packet we have to use the first one as the packet will otherwise be
dropped due to a template mismatch. And we can't install templates with
the "outbound" FWD policies as that would prevent using different
IPsec modes or e.g. IPComp on only one of multiple SAs.
Instead we install the "outbound" FWD policies with a lower priority
than the "inbound" FWD policies so the latter are preferred. But we use
a higher priority than default drop policies would use (in case they'd
be defined with the same subnets).
If there is a DROP shunt that matches outbound forwarded traffic it
would get dropped as the FWD policy we install only matches decrypted
inbound traffic. That's because the Linux kernel first checks the FWD
policies before looking up the OUT policy and SA to encrypt the packets.
Josh Soref