[strongSwan] Identifying IPSEC user sessions

Andrew Foss afoss at actmobile.com
Mon Apr 27 04:03:45 CEST 2015

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...


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 
> <mailto: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
>>         <mailto:Users at lists.strongswan.org>
>>         >> https://lists.strongswan.org/mailman/listinfo/users
>>         >
>>         > _______________________________________________
>>         > Users mailing list
>>         > Users at lists.strongswan.org <mailto:Users at lists.strongswan.org>
>>         > https://lists.strongswan.org/mailman/listinfo/users
>>         _______________________________________________
>>         Users mailing list
>>         Users at lists.strongswan.org <mailto: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/d4bd55dd/attachment.html>

More information about the Users mailing list