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