Bug #1152

Updated by Tobias Brunner almost 5 years ago

Relates to bug #937.

We have noticed that when a new IKE_SA session starts before an old session has closed for that client, the RADIUS accounting START message for the new session contains the virtual IP address of the old session. This means that accounting data for the new session is not provided. This is happening typically 7000 times a day across 1500 users, and results in uses failing to access our services until a new session is started.

The following log extract illustrates the issue. There are two sessions: 1836264 starts at 19:49:40, which is replaced by session 1836399 at 19:55:05. The client is the Apple/Cisco iOS IPsec client (IKEv1).

2015-10-06 19:49:40 87[IKE] <1836264> is initiating a Main Mode IKE_SA
2015-10-06 19:49:40 401[IKE] <COUNTRY_GB_MULTI_Apple|1836264> IKE_SA COUNTRY_GB_MULTI_Apple[1836264] established
(19:49:40 RADIUS START received for
2015-10-06 19:49:41 61[IKE] <COUNTRY_GB_MULTI_Apple|1836264> CHILD_SA COUNTRY_GB_MULTI_Apple{1683582} established with SPIs cb764735_i 03f14ed6_o and TS ===

2015-10-06 19:55:05 07[IKE] <1836399> is initiating a Main Mode IKE_SA
2015-10-06 19:55:06 24[IKE] <COUNTRY_GB_MULTI_Apple|1836399> IKE_SA COUNTRY_GB_MULTI_Apple[1836399] established
(19:55:06 RADIUS START received for *This is the wrong IP address; it should be*)
2015-10-06 19:55:06 137[IKE] <COUNTRY_GB_MULTI_Apple|1836399> CHILD_SA COUNTRY_GB_MULTI_Apple{1683709} established with SPIs c669f89b_i 0ae0219d_o and TS ===

(No closing CHILD_SA message in log for session 1836264. I don't know if that's relevant / important?)
2015-10-06 19:55:16 480[IKE] <COUNTRY_GB_MULTI_Apple|1836264> deleting IKE_SA
(No RADIUS stop received at this time. That really messes up our accounting too.)

We are using v5.3.2