If a client does Mode Config during reauthentication the assign_vips()
event might be triggered twice, we should not send another Start message
in that case.
Fixes#937.
Some clients won't do Mode Config or XAuth during reauthentication.
Because Start messages previously were triggered by TRANSACTION exchanges
none were sent for new SAs of such clients, while Stop messages were still
sent for the old SAs when they were destroyed. This resulted in an
incorrect state on the RADIUS server.
Since 31be582399 the assign_vips() event is also triggered during
reauthentication if the client does not do a Mode Config exchange.
So instead of waiting for a TRANSACTION exchange we trigger the Start
message when a virtual IP is assigned to a client.
With this the charon.plugins.eap-radius.accounting_requires_vip option
would not have any effect for IKEv1 anymore. However, it previously also
only worked if the client did an XAuth exchange, which is probably
rarely used without virtual IPs, so this might not be much of a
regression.
Fixes#937.
There are several situations that the previous code didn't handle that
well, for example, interim updates during rekeying (until the rekeyed SA
was deleted the numbers were too high, then suddenly dropped afterwards),
or rekeying for IKEv1 in general because rekeyed IPsec SAs stay installed
until they expire (so if they were still around when the IKE_SA was
terminated, the reported numbers in the Stop message were too high).
If intermediate updates are not used the cache entries for rekeyed
CHILD_SA will accumulate, we can't clean them up as we don't get
child_updown() events for them.
As the startup timestamp needs 10 characters, we only have left 4 characters
for the IKE_SA unique identifier. This is insufficient when having 10000 IKE_SAs
or more established, resulting in non-unique session identifiers.
Fixes#889.
Any interval returned by the RADIUS server in the Access-Accept message
overrides the configured interval. But it might be useful if RADIUS is
only used for accounting.
Handling the result for enum_from_name() is difficult, as checking for
negative return values requires a cast if the enum type is unsigned. The new
signature clearly differentiates lookup result from lookup value.
Further, this actually allows to convert real -1 enum values, which could not
be distinguished from "not-found" and the -1 return value.
This also fixes several clang warnings where enums are unsigned.
Depending on the value of the CVPN3000-IPSec-Split-Tunneling-Policy(55)
radius attribute, the subnets in the CVPN3000-IPSec-Split-Tunnel-List(27)
attribute are sent in either a UNITY_SPLIT_INCLUDE (if the value is 1)
or a UNITY_LOCAL_LAN (if the value is 2).
So if the following attributes would be configured for a RADIUS user
CVPN3000-IPSec-Split-Tunnel-List := "10.0.1.0/255.255.255.0,10.0.2.0/255.255.255.0"
CVPN3000-IPSec-Split-Tunneling-Policy := 1
A UNITY_SPLIT_INCLUDE configuration payload containing these two subnets
would be sent to the client during the ModeCfg exchange.
The contents of the CVPN3000-IPSec-Default-Domain(28) and
CVPN3000-IPSec-Split-DNS-Names(29) radius attributes are forwarded in
the corresponding Unity configuration attributes.
The configuration string is appended to the XAuth backend name, separated by
a colon. The configuration string is passed untouched to the backend, where
it can change the behavior of the XAuth module.
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.
Tobias Brunner