1. 30 Sep, 2018 3 commits
  2. 27 Sep, 2018 1 commit
  3. 22 Sep, 2018 1 commit
  4. 21 Sep, 2018 6 commits
  5. 17 Sep, 2018 1 commit
  6. 08 Sep, 2018 1 commit
  7. 02 Sep, 2018 1 commit
  8. 15 Aug, 2018 2 commits
  9. 09 Aug, 2018 9 commits
  10. 06 Aug, 2018 3 commits
  11. 05 Aug, 2018 5 commits
  12. 04 Aug, 2018 1 commit
    • Daniel Lenski's avatar
      include computer name in the GP cookie · 2f270d25
      Daniel Lenski authored
      The GlobalProtect "cookie" is an overstuffed monstrosity, due to the
      requirement to retain a few random, non-secret values in order to logout
      successfully (see gpst_bye):
      
          authcookie=d41d8cd98f00b204e9800998ecf8427e&portal=Gateway-X&user=user.name&domain=big-corp
      
      Until now, I've avoided including the computer field in this cookie, on the assumption that it
      can reproduced at any time using vpninfo->localname. However, it appears that this value can't always
      be reproduced correctly when running under NetworkManager:
      
          https://github.com/dlenski/network-manager-openconnect/issues/7
      
      In order to be more robust, this patch therefore also includes the local hostname in the cookie:
      
          authcookie=d41d8cd98f00b204e9800998ecf8427e&portal=Gateway-X&user=user.name&domain=big-corp&computer=hostname
      2f270d25
  13. 02 Aug, 2018 6 commits
    • Daniel Lenski's avatar
      Remove first oNCP negotiation request (only second is necessary) · 62c60bad
      Daniel Lenski authored
      The current oNCP (Juniper) protocol support issues two separate
      oNCP negotiation requests.
      
      1) POST /dana/js?prot=1&svc=1 HTTP/1.1
         <ignore response body>
         <teardown and restart TLS connection>
      
      2) POST /dana/js?prot=1&svc=4 HTTP/1.1
         <continue using open TLS connection for oNCP tunnel>
      
      The first of these two requests appears to be totally unnecessary, based on
      testing with two different Juniper gateways, one of which returns
      "NCP-Version: 2" and one which returns "NCP-Version: 3" in response to the
      oNCP negotiation requests.
      
      Removing the first request saves an additional TLS negotiation (2-3
      roundtrips with TLS 1.0) and allows the connection to start faster.
      62c60bad
    • Daniel Lenski's avatar
      Reduce unnecessary connection-rebuilding for Juniper · 46de5eee
      Daniel Lenski authored
      The current oNCP (Juniper) protocol support sets "Connection: close" in all
      HTTP requests.  This is not ideal because it requires many TLS handshakes
      and round-trips, making the connection very slow to start when the latency
      of the connection to the gateway is high, especially if the number of
      authentication forms and redirects is large.
      
      Simply removing the "Connection: close" header causes the oNCP connection
      to fail; the server doesn't interpret the first packet sent over the oNCP
      tunnel correctly (the vestigial authentication packet).
      
      However, it appears that the "Connection: close" header *only* needs to be
      specified for this final HTTP request, and not for any of the prior ones.
      The presence of this header seems to signal to the gateway that it should
      stop treating this as an HTTP connection, and start treating it as an
      oNCP tunnel.
      
      Tested on two different Juniper gateways, one which returns
      "NCP-Version: 2" and one which returns "NCP-Version: 3" in response to
      the oNCP negotiation requests.
      46de5eee
    • Daniel Lenski's avatar
      Fill in a few missing references to GlobalProtect, TNCC, and DTLS support in the docs · ffebb560
      Daniel Lenski authored
      Also clarifies the command-line options regarding compression
      Signed-off-by: default avatarDaniel Lenski <dlenski@gmail.com>
      ffebb560
    • Daniel Lenski's avatar
      Clarify protocol description in connection message · a8ab34e1
      Daniel Lenski authored
      - Include both the TCP- and UDP-based protocols' compression details
      - The UDP-based protocol really can't be connected by the time this
        prints, since the mainloop hasn't had enough time to receive the
        connection confirmation packets; show it as "in progress"
      
      Before (with default verbosity):
      
          Connected as 10.0.0.3 + dead::be:ef, using SSL + deflate
          Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(RSA)-(AES-128-GCM).
      
      After:
      
          Connected as 10.0.0.3 + dead::be:ef, using SSL + Deflate, with DTLS + LZS in progress
          Established DTLS connection (using GnuTLS). Ciphersuite (DTLS1.2)-(RSA)-(AES-128-GCM).
      Signed-off-by: default avatarDaniel Lenski <dlenski@gmail.com>
      a8ab34e1
    • Daniel Lenski's avatar
      a4b9d85d
    • Daniel Lenski's avatar
      Align naming and commenting of mechanism for receiving oversize packets across protocols · 0281a8e1
      Daniel Lenski authored
      We've now implemented mechanisms to tolerate larger-than-expected packets for:
      
        - Uncompressed CSTP packets ("Fixed regression with CSTP MTU handling"
          patch in July 2016)
      
        - Uncompressed oNCP packets ("Do not drop vpn connection if packet arrived
          is larger than MTU" patch in May 2017)
      
        - Uncompressed GPST packets (in original merge from March 2018; this is a
          virtual necessity for GlobalProtect because it has no functional
          mechanism for negotiating the MTU)
      
        - Uncompressed ESP packets ("check for oversize ESP packets, with 256
          bytes of headroom above calculated" in March 2018; GlobalProtect requires
          this for the aforementioned reason)
      
        - Compressed CSTP packets (preceding patch in this series)
      
      Since this is a requiring issue across protocols, it's useful to align the
      naming, commenting, and packet sizing-tolerance across the source files.
      
        1) Use receive_mtu everywhere as the name for the maximum tolerated size of an
           incoming packet.
        2) Insert similar comments explaining its purpose everywhere it's used.
        3) Use receive_mtu = MAX(16384, vpninfo->ip_info.mtu) for all TLS-based
           tunnels, because 16384 is the maximum TLS record size.
        4) Use receive_mtu = MAX(2048, vpninfo->vpninfo->ip_info.mtu + 256) for
           all UDP-based tunnels, because the MTU of IP datagrams on the public
           internet is effectively ~1500.
      Signed-off-by: default avatarDaniel Lenski <dlenski@gmail.com>
      0281a8e1