| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Mainly for reauthentication with third party implementations, we allowed to
reuse an online lease, but only for the same peer identity and when it
explicitly requested the same address.
This has always been problematic, because it changes the reqid of the CHILD_SA
with the same traffic selectors, breaking the old tunnel. As we now reject
such policy overwrites, this usually lets the installation of the new policies
fail. We therefore disable reassignment of online leases by default.
|
|
|
|
| |
This saves two lists per connected peer identity, up to 0.4KB.
|
|
|
|
|
|
|
| |
When we reassign an online lease for the same peer, we have to refcount it.
Otherwise we would set it offline if one of the tunnels goes down, but it is
actually still in use by a the second tunnel. This can finally lead in
assigning the same virtual IP to different peers.
|
| |
|
|
|
|
| |
Partially based on an old patch by Adrian-Ken Rueegsegger.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
INCLUDES are now deprecated and throw warnings when using automake 1.13.
We now also differentiate AM_CPPFLAGS and AM_CFLAGS, where includes and
defines are passed to AM_CPPFLAGS only.
|
| |
|
|
|
|
|
| |
The ifa_msghdr and rt_msghdr structs are not compatible (at least not on
FreeBSD).
|
| |
|
|
|
|
|
| |
As the virtual flag is set after the address has been added to the map,
we make sure we ignore virtual IPs when doing lookups.
|
|
|
|
|
|
|
| |
It seems we sometimes get the virtual IP as source (with
rightsubnet=0.0.0.0/0) even if the exclude route is already
installed. Might be a timing issue because shortly afterwards the
lookup seems to succeed.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
One second might be too short for IPs to appear/disappear, especially on
virtualized hosts.
|
|
|
|
|
| |
The known source address might be gone resulting in an error, making
learning a new source address impossible.
|
|
|
|
|
|
|
|
|
|
|
| |
If IPsec SAs are rekeyed due to an address change (e.g. because
update_sa is not supported) the exact same policy with the same reqid
will be installed, but with different addresses. After the rekeying the
old SA and its policies are removed, using the first matching mapping
breaks the mapping between the policies and the new SA (at least on
FreeBSD, the Linux kernel might only use the reqid for this). Using the
oldest matching SA is still an approximation but it solves the above
issue.
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Multiple additional search paths can be added with the add_path()
method.
|
|
|
|
| |
It is not required to use the kernel-net part of the plugin.
|
|
|
|
| |
The daemon as such does not require this capability.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
This was noticed on Mac OS X where, if the default route is returned,
RTA_NETMASK has sa_len set to 0, but skipping zero bytes to read the
next address makes no sense, of course. Using 0 for sa_len seems
a bit strange, in particular, because struct sockaddr has by definition
a minimum length of 16 bytes. But it seems FreeBSD actually does the
same.
|
|
|
|
| |
Kernels don't provide the same information for all routes.
|
| |
|
| |
|
|
|
|
| |
These are created as cache/clone on Mac OS X.
|
| |
|
| |
|
|
|
|
|
| |
On FreeBSD, for some reason, we don't learn the interface is up
otherwise. Even though ifconfig lists it as up at the same time.
|
|
|
|
| |
virtual IPs
|
|
|
|
| |
TUN device
|
| |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|