<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

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

> 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

> 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

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

>> throughout its entire lifetime).

<br>>>

<br>>> Thank you!

<br>>> Jiri Horky

<br>>> ______________________________<wbr>_________________

<br>>> Users mailing list

<br>>> <a href="mailto:Users@lists.strongswan.org" target="_blank" rel="nofollow" onmousedown="this.href='mailto:Users@lists.strongswan.org';return true;" onclick="this.href='mailto:Users@lists.strongswan.org';return true;">Users@lists.strongswan.org</a>

<br>>> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Flists.strongswan.org%2Fmailman%2Flistinfo%2Fusers\46sa\75D\46sntz\0751\46usg\75AFQjCNHpb2EWexg7wtvkBUUWojs4DgFnHQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Flists.strongswan.org%2Fmailman%2Flistinfo%2Fusers\46sa\75D\46sntz\0751\46usg\75AFQjCNHpb2EWexg7wtvkBUUWojs4DgFnHQ';return true;">https://lists.strongswan.org/<wbr>mailman/listinfo/users</a>

<br>>

<br>> ______________________________<wbr>_________________

<br>> Users mailing list

<br>> <a href="mailto:Users@lists.strongswan.org" target="_blank" rel="nofollow" onmousedown="this.href='mailto:Users@lists.strongswan.org';return true;" onclick="this.href='mailto:Users@lists.strongswan.org';return true;">Users@lists.strongswan.org</a>

<br>> <a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Flists.strongswan.org%2Fmailman%2Flistinfo%2Fusers\46sa\75D\46sntz\0751\46usg\75AFQjCNHpb2EWexg7wtvkBUUWojs4DgFnHQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Flists.strongswan.org%2Fmailman%2Flistinfo%2Fusers\46sa\75D\46sntz\0751\46usg\75AFQjCNHpb2EWexg7wtvkBUUWojs4DgFnHQ';return true;">https://lists.strongswan.org/<wbr>mailman/listinfo/users</a>

<br>

<br>______________________________<wbr>_________________

<br>Users mailing list

<br><a href="mailto:Users@lists.strongswan.org" target="_blank" rel="nofollow" onmousedown="this.href='mailto:Users@lists.strongswan.org';return true;" onclick="this.href='mailto:Users@lists.strongswan.org';return true;">Users@lists.strongswan.org</a>

<br><a href="https://lists.strongswan.org/mailman/listinfo/users" target="_blank" rel="nofollow" onmousedown="this.href='https://www.google.com/url?q\75https%3A%2F%2Flists.strongswan.org%2Fmailman%2Flistinfo%2Fusers\46sa\75D\46sntz\0751\46usg\75AFQjCNHpb2EWexg7wtvkBUUWojs4DgFnHQ';return true;" onclick="this.href='https://www.google.com/url?q\75https%3A%2F%2Flists.strongswan.org%2Fmailman%2Flistinfo%2Fusers\46sa\75D\46sntz\0751\46usg\75AFQjCNHpb2EWexg7wtvkBUUWojs4DgFnHQ';return true;">https://lists.strongswan.org/<wbr>mailman/listinfo/users</a>

<br></blockquote></div></div>