[strongSwan] Identifying IPSEC user sessions
jiri.horky at gmail.com
Sun Apr 26 06:50:20 CEST 2015
thanks for the response. We too have separate certificate per client,
but do not use xauth (MAC issues). The problem with certs is that they
do not provide unique session ids per multiple sessions from the same
user. So in case you lose down event, you will have troubles matching
the right events together (this could be done by analyzing the stream of
events - e.g. if you receive start event again without proper stop of
the previous session, you would have to account it as stop event of
previous session as well). But we wanted to avoid this...
On 04/26/2015 01:35 AM, Andrew Foss wrote:
> I just wrestled with this in an attempt to get some byte counters in
> my updown scripts.
> I ended up doing a patch. I have tried two ways, we use a custom cert
> for each ipsec client and an XAuthName, so they are available in the
> updown as $PLUTO_XAUTH_ID and $PLUTO_PEER_ID
> you might check those two vars in your updown and see if they provide
> the id you are looking for...
> On 4/25/15 2:37 PM, Jiri Horky wrote:
>> Hi list,
>> I am sure somebody solved the same problem in the past as well. We would
>> like to have a fixed session identifier throughout the lifetime of an
>> IPSec tunnel (clients connection) even when rekeying happens on IKE
>> SA/CHILD SA. This is to ensure that we can match the up/down events,
>> that we catch in a custom handler. Also, this identifier should be
>> globally unique per servers/multiple user sessions, i.e. if an user from
>> the same IP goes to the same server, we should have a new session
>> I was thinking of generating an UUID field when the session up event
>> happens, and assigning it to some struct which strongswan must have for
>> the IPSEC connection (I guess there is such a thing). Then to pass this
>> information to the handler when session down happens.
>> Is there a better/easier way how to achieve this? If not, and I am not
>> completely wrong, could you please point me to the right place where I
>> should add the field (i.e. which struct should hold the connection
>> throughout its entire lifetime).
>> Thank you!
>> Jiri Horky
>> Users mailing list
>> Users at lists.strongswan.org
> Users mailing list
> Users at lists.strongswan.org
More information about the Users