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