[strongSwan] Identifying IPSEC user sessions

Mon Apr 27 20:55:30 CEST 2015

We have discussed session-related parameters like e.g. start and stop time
of connection, bytes transferred, etc. and how to store them.
Session is considered from user connection to user disconnection; in scope
of one session many IKE_SA's might get established and expired.
I believe some of the session-related information is somehow present in the
StrongSwan already, as Radius AAA plugin should be able to use them for
authentication and accounting. More details in wiki
<https://wiki.strongswan.org/projects/strongswan/wiki/RadAttrPlugin>.

Miroslav Svoboda | +420 608 224 486

On 27 April 2015 at 04:03, Andrew Foss <afoss at actmobile.com> wrote:

>  Yeah, I thought so to, it is a minor one, but apparently they can power
> down the radios while running, w/o actually downing the iface in the
> kernel, a mobile driven thing? It is actually kind of nice, but they can
> power up the radios and be on a different network...
>
> andrew
>
>
> On 4/26/15 1:55 PM, Miroslav Svoboda wrote:
>
> 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/20150427/78e354d0/attachment.html>