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