<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    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...<br>
    <br>
    andrew<br>
    <br>
    <div class="moz-cite-prefix">On 4/26/15 1:55 PM, Miroslav Svoboda
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAD6VQRJ8vntDEjMdy-uAnaa9QJD7u58-un_MPrSH0trm9D2x0Q@mail.gmail.com"
      type="cite">
      <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 moz-do-not-send="true"
                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 moz-do-not-send="true"
                          href="mailto:Users@lists.strongswan.org"
                          rel="nofollow" target="_blank">Users@lists.strongswan.org</a>
                        <br>
                        >> <a moz-do-not-send="true"
                          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 moz-do-not-send="true"
                          href="mailto:Users@lists.strongswan.org"
                          rel="nofollow" target="_blank">Users@lists.strongswan.org</a>
                        <br>
                        > <a moz-do-not-send="true"
                          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 moz-do-not-send="true"
                          href="mailto:Users@lists.strongswan.org"
                          rel="nofollow" target="_blank">Users@lists.strongswan.org</a>
                        <br>
                        <a moz-do-not-send="true"
                          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>
    </blockquote>
    <br>
  </body>
</html>