<div dir="ltr">We have discussed session-related parameters like e.g. start and stop time of connection, bytes transferred, etc. and how to store them.<div>Session is considered from user connection to user disconnection; in scope of one session many IKE_SA's might get established and expired.<br><div>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 <a href="https://wiki.strongswan.org/projects/strongswan/wiki/RadAttrPlugin">wiki</a>.</div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Miroslav Svoboda | +420 608 224 486</div></div></div></div></div>
<br><div class="gmail_quote">On 27 April 2015 at 04:03, Andrew Foss <span dir="ltr"><<a href="mailto:afoss@actmobile.com" target="_blank">afoss@actmobile.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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...<span class="HOEnZb"><font color="#888888"><br>
<br>
andrew</font></span><div><div class="h5"><br>
<br>
<div>On 4/26/15 1:55 PM, Miroslav Svoboda
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">If I needed information who is *really* online, I
would focus on DPD.
<div>I like the idea of saving battery by stopping unnecessary
services. Unfortunatelly, I miss the point what you are doing
/ trying to achieve.</div>
<div>In my understanding, either computer is online, sending
encrypted traffic, or sleeping/off, then sending nothing.</div>
<div><br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">On 26 April 2015 at 15:17, Andrew
Foss <span dir="ltr"><<a href="mailto:afoss@actmobile.com" target="_blank">afoss@actmobile.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> 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.<br>
<br>
<div>On 4/25/15 11:58 PM, Miroslav Svoboda wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,
<div><br>
</div>
<div>Having a unique identifier of a session with
lifespan of the whole session would help me as
well.</div>
<div><br>
</div>
<div>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.</div>
<div>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.</div>
<div>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.</div>
<div><br>
</div>
<div>My approach is based on presumptions that:</div>
<div>- IKE_SA does not change between authorization
and assignment of virtual IP</div>
<div>- Virtual IP does not change during one session
and is unique per session</div>
<div>- connection is considered established upon
assignment of VIP and disconnected upon revocation
of VIP</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Counting number of bytes transferred is not
required on my project now, but I like Andrew's
idea of using updown script for it.</div>
<div><br>
</div>
<div>Regards,</div>
<div>Miroslav</div>
<div><br>
On Sunday, April 26, 2015 at 6:50:28 AM UTC+2,
Jiri Horky wrote:
<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Andrew, <br>
<br>
thanks for the response. We too have separate
certificate per client, <br>
but do not use xauth (MAC issues). The problem
with certs is that they <br>
do not provide unique session ids per multiple
sessions from the same <br>
user. So in case you lose down event, you will
have troubles matching <br>
the right events together (this could be done by
analyzing the stream of <br>
events - e.g. if you receive start event again
without proper stop of <br>
the previous session, you would have to account
it as stop event of <br>
previous session as well). But we wanted to
avoid this... <br>
<br>
Cheers <br>
Jirka H. <br>
<br>
On 04/26/2015 01:35 AM, Andrew Foss wrote: <br>
> Jiri, <br>
> <br>
> I just wrestled with this in an attempt to
get some byte counters in <br>
> my updown scripts. <br>
> <br>
> I ended up doing a patch. I have tried two
ways, we use a custom cert <br>
> for each ipsec client and an XAuthName, so
they are available in the <br>
> updown as $PLUTO_XAUTH_ID and
$PLUTO_PEER_ID <br>
> <br>
> you might check those two vars in your
updown and see if they provide <br>
> the id you are looking for... <br>
> <br>
> andrew <br>
> <br>
> On 4/25/15 2:37 PM, Jiri Horky wrote: <br>
>> Hi list, <br>
>> <br>
>> I am sure somebody solved the same
problem in the past as well. We would <br>
>> like to have a fixed session identifier
throughout the lifetime of an <br>
>> IPSec tunnel (clients connection) even
when rekeying happens on IKE <br>
>> SA/CHILD SA. This is to ensure that we
can match the up/down events, <br>
>> that we catch in a custom handler.
Also, this identifier should be <br>
>> globally unique per servers/multiple
user sessions, i.e. if an user from <br>
>> the same IP goes to the same server, we
should have a new session <br>
>> identifier. <br>
>> <br>
>> I was thinking of generating an UUID
field when the session up event <br>
>> happens, and assigning it to some
struct which strongswan must have for <br>
>> the IPSEC connection (I guess there is
such a thing). Then to pass this <br>
>> information to the handler when session
down happens. <br>
>> <br>
>> Is there a better/easier way how to
achieve this? If not, and I am not <br>
>> completely wrong, could you please
point me to the right place where I <br>
>> should add the field (i.e. which struct
should hold the connection <br>
>> throughout its entire lifetime). <br>
>> <br>
>> Thank you! <br>
>> Jiri Horky <br>
>>
_______________________________________________
<br>
>> Users mailing list <br>
>> <a href="mailto:Users@lists.strongswan.org" rel="nofollow" target="_blank">Users@lists.strongswan.org</a>
<br>
>> <a href="https://lists.strongswan.org/mailman/listinfo/users" rel="nofollow" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a>
<br>
> <br>
>
_______________________________________________
<br>
> Users mailing list <br>
> <a href="mailto:Users@lists.strongswan.org" rel="nofollow" target="_blank">Users@lists.strongswan.org</a>
<br>
> <a href="https://lists.strongswan.org/mailman/listinfo/users" rel="nofollow" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a>
<br>
<br>
_______________________________________________
<br>
Users mailing list <br>
<a href="mailto:Users@lists.strongswan.org" rel="nofollow" target="_blank">Users@lists.strongswan.org</a>
<br>
<a href="https://lists.strongswan.org/mailman/listinfo/users" rel="nofollow" target="_blank">https://lists.strongswan.org/mailman/listinfo/users</a>
<br>
</blockquote>
</div>
</div>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>