[strongSwan] Identifying IPSEC user sessions

[Miroslav Svoboda]

If I needed information who is *really* online, I would focus on DPD.
I like the idea of saving battery by stopping unnecessary services.
Unfortunatelly, I miss the point what you are doing / trying to achieve.
In my understanding, either computer is online, sending encrypted traffic,
or sleeping/off, then sending nothing.

On 26 April 2015 at 15:17, Andrew Foss <afoss at actmobile.com> wrote:

>  Agreed, ipsec status all doesn't show us all the users/sessions, who's
> laptop closed, went to slept, idled or moved out of network coverage while
> they were connected. We aggregate the updown scripts, to see whether the
> user's session is still active, we let ipsec disconnect quickly on no
> traffic to give the battery a break, but the user's session is still
> "active", logically they are still connected even when ipsec has
> disconnected, they are just idle, not using the network at the moment. It
> is tough to get a truly accurate picture and we can't really tell the
> difference between a hard disconnect, ie user turned off the vpn vs a soft
> disconnect machine went to sleep, but will reconnect as soon as it starts
> sending traffic.
>
> On 4/25/15 11:58 PM, Miroslav Svoboda wrote:
>
> Hi,
>
>  Having a unique identifier of a session with lifespan of the whole
> session would help me as well.
>
>  I need to record start and stop of each session into database. Same as
> you, users might have multiple sessions and I need to log each of them
> separately.
> At the moment I am extending SQL plugin by one listener, which listens on
> internal StrongSwan's bus for IKE_SA authorization events,
> exploiting IKE_SA authorization hook. It will let me record start of the
> session into SQL database, together with information about the user.
> Furthemore, it will register hook for assign_vips and handle_vips events,
> record all of them into database. Then, the records will be aggregated in
> the database using IKE_SA for as a common key for correlation between
> authorize and assign_vips events and using the assigned VIP as a common key
> for correlation between assign_vips events and handle_vips events.
>
>  My approach is based on presumptions that:
> - IKE_SA does not change between authorization and assignment of virtual IP
> - Virtual IP does not change during one session and is unique per session
> - connection is considered established upon assignment of VIP and
> disconnected upon revocation of VIP
> However, I am afraid it might be overcomplicated. Also maintenance of my
> own inhouse patch of StrongSwan is not really compelling to me from
> operations point of view.
>
>  As a second option, I will look at Radius AAA plugin, as AAA is more
> suitable for this purpose. If it works well, I will create records in the
> database from Radius.
>
>  Counting number of bytes transferred is not required on my project now,
> but I like Andrew's idea of using updown script for it.
>
>  Regards,
> Miroslav
>
> On Sunday, April 26, 2015 at 6:50:28 AM UTC+2, Jiri Horky wrote:
>>
>> Hi Andrew,
>>
>> 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...
>>
>> Cheers
>> Jirka H.
>>
>> On 04/26/2015 01:35 AM, Andrew Foss wrote:
>> > Jiri,
>> >
>> > 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...
>> >
>> > andrew
>> >
>> > 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
>> >> identifier.
>> >>
>> >> 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
>> >> https://lists.strongswan.org/mailman/listinfo/users
>> >
>> > _______________________________________________
>> > Users mailing list
>> > Users at lists.strongswan.org
>> > https://lists.strongswan.org/mailman/listinfo/users
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150426/623544ff/attachment.html>