This project is mirrored from git://git.infradead.org/users/dwmw2/openconnect.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts. It can be resumed by a project maintainer.
Last successful update . This branch has diverged from upstream.
  1. 09 Dec, 2021 1 commit
    • Dimitri Papadopoulos Orfanos's avatar
      Load wintun.dll from the application directory only · 59d3e370
      Dimitri Papadopoulos Orfanos authored and Daniel Lenski's avatar Daniel Lenski committed
      
      
      Do not attempt to load it from the System32 directory.
      
      Different versions of `wintun.dll` or `wintun.sys` float around in system
      directories. In my case, a `C:\Windows\System32\wintun.sys` had been left
      behind for some reason, and was being loaded at startup, taking precedence
      over the `wintun.dll` bundled with OpenConnect. Unfortunately, different
      versions are not compatible, at least not entirely, while OpenConnect is
      being tested with the bundled `wintun.dll` only.
      
      To avoid this DLL hell, we shall load exclusively the bundled version of
      `wintun.dll` from the application directory, and disregard any `wintun.dll`
      or `wintun.sys` installed in system directories by other software.
      Signed-off-by: Dimitri Papadopoulos Orfanos's avatarDimitri Papadopoulos <3350651-DimitriPapadopoulos@users.noreply.gitlab.com>
      59d3e370
  2. 07 Dec, 2021 5 commits
  3. 03 Dec, 2021 3 commits
  4. 24 Nov, 2021 1 commit
  5. 23 Nov, 2021 2 commits
  6. 20 Nov, 2021 2 commits
    • Daniel Lenski's avatar
      Merge branch 'fix_F5_plain_auth_form' into 'master' · 2fb5b8f6
      Daniel Lenski authored
      Bugfix F5 'plain' login form
      
      Closes #351
      
      See merge request !304
      2fb5b8f6
    • Daniel Lenski's avatar
      Refuse to handle forms without ->auth_id (but do it in the right place, and noisily) · 386a6edb
      Daniel Lenski authored
      In 0b47ea18 ("Refuse to handle forms without
      ->auth_id"), the process_auth_form_cb for the OpenConnect CLI was modified
      to silently reject forms with auth_id unset.
      
      Issues with this:
      
      1. If a form doesn't have its auth_id set, it'll fail *silently*, which
         makes it confusingly difficult to identify the root cause. (See #351
      
      .)
      2. As that commit message says, GUIs/front-ends need the auth_id to be set,
         but it didn't do anything to enforce it other than for the CLI.
      
      The solution is to reject forms with auth_id unset in process_auth_form()
      itself, rather than expecting the front-ends’ callback functions to check
      this, and to do so with an error message explaining that this is a bug in
      OpenConnect.
      Signed-off-by: Daniel Lenski's avatarDaniel Lenski <dlenski@gmail.com>
      386a6edb
  7. 19 Nov, 2021 1 commit
    • Daniel Lenski's avatar
      Bugfix F5 'plain' login form · 7f4e2d0a
      Daniel Lenski authored
      Fixes #351.
      
      It turns out that the "plain auth form" for F5 has been broken since
      0b47ea18.  (This form is used as a stand-in
      when the server fails to provide a real HTML login form, and only gives a
      JavaScript mess that dynamically creates a form.)
      
      DW probably didn't notice this when making that commit, because
      a07bbbcd
      
       had previously fixed the other
      places where a form with no `auth_id` could be created.
      
      This ensures that the "plain auth form" has its `auth_id` set, and adds test
      coverage of this form to `f5-auth-and-config`.
      Signed-off-by: Daniel Lenski's avatarDaniel Lenski <dlenski@gmail.com>
      7f4e2d0a
  8. 18 Nov, 2021 2 commits
  9. 16 Nov, 2021 1 commit
  10. 15 Nov, 2021 3 commits
    • Daniel Lenski's avatar
      The option '--force-dpd' should be followed even if the server specifies a lesser DPD interval · 89c5cc74
      Daniel Lenski authored
      The `openconnect_set_dpd()` API function, and the command-line option
      `--force-dpd=SEC`, specify an exact DPD (Dead Peer Detection) interval for
      the client, which is intended to override the server-specified value.
      
      However, several protocols
      would simply *ignore* the specified interval, and accept the
      server's interval, if the server's interval was *less* than the one
      specified via API or command-line.
      
      - AnyConnect/ocserv has behaved this way since the `--force-dpd` option was
        first added in 2012 (see 54784bef)
      - ESP support, added for oNCP/Pulse, copied this behavior
      - Fortinet copied this behavior
      - Array copied this behavior
      
      This behavior can cause problems for protocols where DPD, or reconnection in
      general, is broken, and where a user wishes to specify a long interval (e.g.
      `--force-dpd=99999`) to effectively disable DPD.  Specifically, Fortinet is
      affected by this; see
      #334 (comment 732774445)
      
      .
      
      The straightforward solution here is just to make the `--force-dpd` option
      do what it says, and set the client's DPD interval unconditionally.
      Signed-off-by: Daniel Lenski's avatarDaniel Lenski <dlenski@gmail.com>
      89c5cc74
    • Daniel Lenski's avatar
      Add changelog entry · d7d220ef
      Daniel Lenski authored
      
      Signed-off-by: Daniel Lenski's avatarDaniel Lenski <dlenski@gmail.com>
      d7d220ef
    • Daniel Lenski's avatar
      Juniper/NC ESP rekey fix · 3d1ec6e0
      Daniel Lenski authored
      This should fix #322.
      This was an immensely tricky issue to identify and solve.  Many thanks to
      @john508 for his patient logging, testing, and bisecting.
      
      This came down to a subtle combination of 2 problems, described further in
      #322 (comment 702122197).
      
      First, a bug:
      
        The code for Juniper/Pulse 'dontsend' added in
        b4f50f8b
        caused IPv6 packets to get sent over the Juniper oNCP/TLS channel in a
        completely mangled form, thereby confusing the server and making it not
        respond to subsequent ESP rekey packets sent over the oNCP/TLS channel.
      
        The fix is to use this code path *only* for the Pulse protocol, not for the
        Juniper protocol. Juniper cannot do ESP-over-IPv6 at all, and cannot send
        tunneled IPv6 packets at all (neither via ESP-over-IPv4, nor via oNCP/TLS).
      
      Second, we introduced a subtle regression against a Juniper server behavior
      which we weren't previously aware of:
      
        Juniper servers apparently don't always resend the IP address in a
        configuration packet, if that configuration packet is for
        rekey/reconnection only.
      
        To address this, we need to add a special case for Juniper to the
        install_vpn_opts() function, which was added in
        3d845bc9
      
      .
      Signed-off-by: Daniel Lenski's avatarDaniel Lenski <dlenski@gmail.com>
      3d1ec6e0
  11. 14 Nov, 2021 3 commits
  12. 13 Nov, 2021 1 commit
  13. 12 Nov, 2021 1 commit
  14. 03 Nov, 2021 1 commit
  15. 01 Nov, 2021 1 commit
  16. 22 Oct, 2021 2 commits
  17. 21 Oct, 2021 4 commits
  18. 20 Oct, 2021 3 commits
  19. 17 Oct, 2021 2 commits
  20. 14 Oct, 2021 1 commit