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.
Bring some extensions to eap-radius, namely a virtual IP address provider based
on received Framed-IPs, forwarding of Cisco Unity banners, Interim Accounting
updates and the reporting of sent/received packets.
Installs bypass policies for the physical address if a virtual address is
assigned, and installs a proper source route to actually use the physical
address for bypassed destinations.
Conflicts:
src/libcharon/plugins/unity/unity_handler.c
If we install a virtual IP, its source route would render the shunt policy
useless, as locally generated traffic wouldn't match. Having a route for each
shunt policy with higher priority chooses the correct source address for
bypassed destinations.
During IKEv1 reauthentication, the virtual IP gets removed, then reinstalled.
The CHILD_SAs get migrated, but any associated route gets removed from the
kernel. Reinstall routes after adding the virtual IP again.
When using load-tester, we can install tunnel outer addresses on
demand. As these are installed as "virtual", we have to consider
virtual IPs in the get_interface() lookup to install "real" virtual
IPs to these dynamic external addresses.
Martin Willi