~mamarley/openconnect/+git/gitlab-main:queue_saturation_stats

Last commit made on 2023-03-18
Get this branch:
git clone -b queue_saturation_stats https://git.launchpad.net/~mamarley/openconnect/+git/gitlab-main

Branch merges

Branch information

Name:
queue_saturation_stats
Repository:
lp:~mamarley/openconnect/+git/gitlab-main

Recent commits

3e373b8... by Dan Lenski

Statistics on queue saturation

Our default maximum packet queue length (max_qlen) of 10 appears to be too
low on many modern systems.

FIXME/WHY??? Testing by dwmw2 in 2021 suggested queue length of 10 was
sufficient to saturate GbE:
https://gitlab.com/openconnect/openconnect/-/commit/c6ef1196934ad8ef71d9e6006ec4f4d969673901#733811436f39dfa8a597e73756d842a7f0cbf2a2

Add trace-level logging messages for when we hit the outgoing and incoming
queue limits ("Saturated {TX,RX} queue"), and report number of times we've
done this in stats.

Signed-off-by: Daniel Lenski <email address hidden>

f11eada... by Dan Lenski

Stop accepting ESP packets when the queue is full

We have been doing this for Cisco DTLS since 2021
(e1564bfc174fc7a5f5a48aedf8cbde160ab53caf "Stop accepting DTLS packets when
the queue is full") but have been ignoring it for all other protocols and
transports.

See https://gitlab.com/openconnect/openconnect/-/issues/581.

Fixing this in the ESP mainloop (used by Juniper, Pulse, GlobalProtect) is
very low-hanging fruit.

Signed-off-by: Daniel Lenski <email address hidden>

682553e... by Dan Lenski

Fix mixed line endings

Signed-off-by: Daniel Lenski <email address hidden>

e965b82... by Dan Lenski

Bugfix Y2038 for F5 authentication timestamp

This good recent article on Y2038
(https://www.thkukuk.de/blog/Y2038_glibc_utmp_64bit) reminded me to look for
Unix-epoch integer timestamps that are <64 bits in OpenConnect.

This is the only one I found.

Signed-off-by: Daniel Lenski <email address hidden>

58797b7... by Dan Lenski

Tell Apple users not to use '-i tunX', but '-i utunX' instead.

Per discussion in https://gitlab.com/openconnect/openconnect/-/issues/18#note_953145553,
the BSD "tun" devices have been obsolete for a long time on Mac OS; "utun"
needs to be used instead on modern versions.

However, many users still find suggestions to use `--interface tunX`
floating around the web, and try them. The resulting error message from
OpenConnect is somewhat confusing:

    Cannot open '/dev/tunX': Invalid argument
    Set up tun device failed

Perhaps we could improve the logic to precisely detect whether or not the OS
wants us to use "tun" or "utun", but that would require a contribution by
someone who understands and cares about Mac OS. In the absence of that, we
can simply add a warning to Mac OS users who attempt to use "tun", telling them
that it's probably wrong.

Signed-off-by: Daniel Lenski <email address hidden>

02d7ce7... by Dan Lenski

Update docs related to vpnc-script, platform, Trojans

We've long since had "native/emulated" CSD, but we still need Windows
support.

References to vpnc, and its bundled vpnc-script, are quite obsolete.

Add a wee little plug for vpn-slice as an alternative vpnc-script (😬).

Signed-off-by: Daniel Lenski <email address hidden>

f24634c... by Dan Lenski

Small additions to changelog before release

Signed-off-by: Daniel Lenski <email address hidden>

ec4b1df... by Dan Lenski

Merge branch 'Pulse_unstupid_ESP' into 'master'

IPv6-related improvements for Pulse

See merge request openconnect/openconnect!414

9ba9726... by Dan Lenski

Document the potential need for an EAP-TLS-within-EAP-TTLS workaround for Pulse

See https://gitlab.com/openconnect/openconnect/-/merge_requests/414#note_1149887354
for a more thorough description of this problem by dwmw.

He commented about it in the source code very early on in the development of
the Pulse protocol support, specifically in
https://gitlab.com/openconnect/openconnect/commit/3fb7645608e49c875c20f55352990c7c883bbf96.

Signed-off-by: Daniel Lenski <email address hidden>

9779f57... by Dan Lenski

Pulse needs an 'official' version string in IF/T-T establishment to support IPv6

According to end-user testing in
https://gitlab.com/openconnect/openconnect/-/issues/506#note_1145946165 and
https://gitlab.com/openconnect/openconnect/-/issues/506#note_1146848739,
recent Pulse servers will not send correct IPv6 settings, or simply will not
enable IPv6 traffic, unless the client version string sent in the IF/T
session establishment begins with "Pulse-Secure/" followed by a digit >=8.

From Ivanti/Pulse documentation at
https://help.ivanti.com/ps/help/en_US/PCS/9.1R14/ag/network_n_host_admin.htm#network_and_host_administration_1399867268_681155:

> Only the Pulse client supports IPv6.

> Ivanti Connect Secure release 8.0 and later supports Pulse client access
> to the IPv6 corporate network using VPN Tunneling Connection Profile
> features.

In order to enable IPv6 support, while not misinforming the server about its
identity to an unnecessary disagree, OpenConnect should therefore include an
official-looking prefix ("Pulse-Secure/9.0.3.1667 " for now) in front of its
default user-agent string.

Signed-off-by: Daniel Lenski <email address hidden>