[strongSwan] Identifying IPSEC user sessions

[Miroslav Svoboda]

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