| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Shunt policies don't have a reqid set, so we allow unequal reqids in
this particular case (i.e. if one of the reqids is 0).
|
|
|
|
| |
entry
|
|
|
|
|
|
|
| |
add_policy()
The additional data can be helpful to identify the exact policy to
delete.
|
|
|
|
| |
This was used with pluto, which had its own policy tracking.
|
|
|
|
|
|
|
|
|
|
|
|
| |
side
If only one traffic selector had a port (type/code) the other side had
the port mask set to 0, which canceled out the applied type/code.
It also fixes the installation of ICMP type/code on big-endian hosts.
Fixes #1091.
References #595.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This may be the case when SAs are reestablished after a crash of the
IKE daemon.
We could actually always do updates. The kernel doesn't care, the only
difference is the possible EEXIST if XFRM_MSG_NEWPOLICY is used. The
advantage of not doing this, though, is that we get a warning in the log
if a policy already exists, as that should usually not be the case.
|
| |
|
| |
|
|
|
|
|
| |
get_replay_state() always returns a replay_state_len when returning a
replay state, but GCC doesn't know about that.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is needed to fix usage stats sent via RADIUS Accounting if clients
use MOBIKE or e.g. the kernel notifies us about a changed NAT mapping.
The upper layers won't expect the stats to get reset if only the IPs have
changed (and some kernel interface might actually allow such updates
without reset).
It also fixes traffic based lifetimes in such situations.
Fixes #799.
|
|
|
|
|
|
|
|
|
|
|
| |
The current "inbound" flag is used for two purposes: To define the actual
direction of the SA, but also to determine the operation used for SA
installation. If an SPI has been allocated, an update operation is required
instead of an add.
While the inbound flag normally defines the kind of operation required, this
is not necessarily true in all cases. On the HA passive node, we install inbound
SAs without prior SPI allocation.
|
| |
|
| |
|
|
|
|
|
|
| |
While we can handle the first selector only in BEET mode in kernel-netlink,
passing the full list gives the backend more flexibility how to handle this
information.
|
|
|
|
|
|
|
|
|
|
| |
The reqid is not strictly required, as we set the reqid with the update
call when installing the negotiated SA.
If we don't need a reqid at this stage, we can later allocate the reqid in
the kernel backend once the SA parameters have been fully negotaited. This
allows us to assign the same reqid for the same selectors to avoid conflicts
on backends this is necessary.
|
| |
|
| |
|
|
|
|
|
| |
getsockopt(SO_PROTOCOL) is not supported before 2.6.32. Default to UDP if
either the SO_PROTOCOL define is missing or the syscall fails.
|
|
|
|
|
|
| |
The socket based IKE bypass policies are usually superior, but not supported
on all networking stacks. The port based variant uses global policies for the
UDP ports we have IKE sockets for.
|
|
|
|
|
|
| |
As under vanilla Linux the kernel can't handle parallel dump queries and returns
EBUSY, it makes not much sense to use them. Disable parallel queries by default
to basically restore original behavior, improving performance.
|
|
|
|
|
| |
This avoid the hard dependency on enum names, and makes kernel_netlink_shared
independent of kernel_netlink_ipsec.
|
|
|
|
| |
There is really no need for doing so, and it makes the code just unreadable.
|
|
|
|
|
| |
This allows us to streamline the netlink buffers, and avoid extensive
casting.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Even if the XFRM identifier was named cast128 in the kernel before 2.6.31, it
actually never worked, because there is no such crypto algorithm.
The identifier has been changed to cast5 in
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=245acb87
to make it work, so we should use that.
Fixes #633.
|
| |
|
|
|
|
|
| |
This allows to determine the next hop to reach a subnet, for instance, when
installing routes for shunt policies.
|
| |
|
|
|
|
|
|
| |
Trying to disable replay windows using the ESN attribute fails with EINVAL.
Use non-ESN legacy format to disable replay windows, even if ESN has been
negotiated over IKE.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Don't add a selector to tunnel mode SAs, these might serve multiple
traffic selectors but with only one selector on the SA only the traffic
matching the first one would actually get tunneled.
|
|
|
|
|
|
|
| |
The kernel does not allow them for transport mode SAs or IPComp SAs (and
of course not for AH SAs).
Fixes #446.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using auto=route, current xfrm_acq_expires default value
implies that tunnel can be down for up to 165 seconds, if
other peer rejected first IKE request with an AUTH_FAILED or
NO_PROPOSAL_CHOSEN error message. These error messages are
completely normal in setups where another application
pushes configuration to both strongSwans without waiting
for acknowledgment that they have updated their configurations.
This patch allows strongswan to override xfrm_acq_expires default
value by setting charon.plugins.kernel-netlink.xfrm_acq_expires in
strongswan.conf.
Signed-off-by: Ansis Atteka <aatteka@nicira.com>
|
|
|
|
|
| |
While bmp_len stores the number of u_int32_t the allocated bitmap
actually consists of those integers.
|
| |
|
|
|
|
|
|
|
|
| |
proto/port
If a transport/BEET SA has different selectors for different proto/ports,
installing just the proto/port of the first SA would break any additional
selector.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we silently replaced an existing policy with a new one if the
reqid changed for the same selectors. This will break an old policy in the
favour of the new one (for example if two clients behind the same NAT use
transport mode).
With this change any new policy gets rejected if the reqid differs. This will
make sure we break no existing policy. For rekeying and acquires we still can
have overlapping policies (as we use the same reqid), but for unrelated
connections this is not true anymore (it wasn't actually before, we just
silently broke the existing policy).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This new flag gives the kernel-interface a hint how it should priorize the
use of newly installed SAs during rekeying.
Consider the following rekey procedure in IKEv2:
Initiator --- Responder
I1 -------CREATE-------> R1
I2 <------CREATE--------
-------DELETE-------> R2
I3 <------DELETE--------
SAs are always handled as pairs, the following happens at the SA level:
* Initiator starts the exchange at I1
* Responder installs new SA pair at R1
* Initiator installs new SA pair at I2
* Responder removes old SA pair at R2
* Initiator removes old SA pair at I3
This makes sure SAs get installed/removed overlapping during rekeying. However,
to avoid any packet loss, it is crucial that the new outbound SA gets
activated at the correct position:
* as exchange initiator, in I2
* as exchange responder, in R2
This should guarantee that we don't use the new outbound SA before the peer
could install its corresponding inbound SA.
The new parameter allows the kernel backend to install the new SA with
appropriate priorities, i.e. it should:
* as exchange inititator, have the new outbound SA installed with higher
priority than the old SA
* as exchange responder, have the new outbound SA installed with lower
priority than the old SA
While we could split up the SA installation at the responder, this approach
has another advantage: it allows the kernel backend to switch SAs based on
other criteria, for example when receiving traffic on the new inbound SA.
|
| |
|
| |
|
| |
|