[strongSwan] Identifying IPSEC user sessions
Andrew Foss
afoss at actmobile.com
Sun Apr 26 15:17:51 CEST 2015
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
> <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
> <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
> <https://lists.strongswan.org/mailman/listinfo/users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20150426/47e36993/attachment.html>
More information about the Users
mailing list