The arguments of openconnect_set_mobile_info() have been strdup'ed:
- prior to passing them to openconnect_set_mobile_info(),
- inside openconnect_set_mobile_info().
We don't need both. I have chosen to keep the strdup() call inside
openconnect_set_mobile_info(), and discard the strdup() of the arguments
just before calling openconnect_set_mobile_info().
fake-cisco-server.py:205: DeprecationWarning: ssl.SSLContext() without protocol argument is deprecated.
fake-cisco-server.py:205: DeprecationWarning: ssl.PROTOCOL_TLS is deprecated
All ssl.PROTOCOL_TLS* constants have been added in Python 3.6, and
the default PROTOCOL_TLS has been deprecated since Python 3.10.
David Woodhouse [Tue, 7 Jan 2025 13:20:13 +0000 (13:20 +0000)]
tests: set SOCKET_WRAPPER_DIR_ALLOW_ORIG
This allows the sockwrap library to use the original relative path of its
directory, instead of failing when realpath() gives an absolute pathname
which is too long. This was causing the COPR builds to fail on newer
versions of Fedora (with newer sockwrap).
Closes: #770 Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Tue, 7 Jan 2025 13:06:54 +0000 (13:06 +0000)]
tests: Don't recreate sockdir after cleanup()
Ever since commit bba8db3e922d ("modify tests/common.sh so that
launch_simple_sr_server() → test → cleanup() can be used repeatedly in a
single script") the cleanup() function has left an empty socket wrapper
directory behind.
Instead of recreating it in cleanup(), do so in launch_simple_sr_server()
launch_simple_pppd().
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
David Woodhouse [Fri, 5 Apr 2024 16:23:22 +0000 (17:23 +0100)]
Allow tests to run over IPv6 as well as Legacy IP
When run in an environment with no Legacy IP addresses, or no IPv6 addresses,
AI_ADDRCONFIG will cause getaddrinfo() not to return addresses of that type.
So when running in an IPv6-only environment, ocserv doesn't listen on Legacy
IP. And thus the tests fail. Fix this by using a hostname 'sockwrap' for the
test connections, and providing '--resolve' arguments for both the Legacy IP
and IPv6 addresses handled by libsocket_wrapper.
Some of the python test servers which don't use AI_ADDRCONFIG do still work
on Legacy IP, so leave those alone for now.
We recently added '-4' to the socat invocation for the nullppp tests, for
similar reasons (becaose socat started listening on IPv6 by default). We
can remove that now too.
Closes #721
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Stefan Bühler [Wed, 19 Jun 2024 14:01:10 +0000 (16:01 +0200)]
Don't default form action to '/' in AnyConnect/OpenConnect XML form handling (fixes #737)
Still require action to be non-empty if present.
Form action "redirect" handling code in auth.c already works with
action==NULL (as in not building a new URL). (It'd do weird things
with an empty action though.)
Signed-off-by: Stefan Bühler <source@stbuehler.de>
Marios Paouris [Sat, 12 Oct 2024 14:56:34 +0000 (17:56 +0300)]
Improved adapter name generation when no adapter name is specified.
Try to find an adapter name that is not already used in the system by
appending a monotonically increasing integer to the hostname that is
used as a default name.
This works around wintun's weird behaviour of renaming existing adapters
without preventing two or more instances of openconnect to connect to
the same VPN host (without explicity specifying an interface name), or
otherwise messing with user's network adapters.
Marios Paouris [Mon, 7 Oct 2024 05:53:35 +0000 (08:53 +0300)]
Use hostname as Wintun ifname (if ifname not specified), v2
The intention for the commit 48bd28aa was a bit different
from what was actually implemented.
Although it states that "Instead, we should use the VPN server's hostname
as a sane default interface name with Wintun, and only attempt to use
TAP-Windows as a fallback in the case where Wintun can't be initialized.",
it first tries with an empty interface name, which uses the first available
interface found, whether it is tap or tun, and if that fails then creates
the same default with the server name, which will prioritize wintun over
tap.
Instead, implement the following flow:
If the user did specify an interface name:
- Try to find an adapter with the specified name (whether it's tun
or tap) and use it.
- If no adapter found, try to create a wintun adapter. If wintun is
not available then bail out.
If the user did not specify an interface name:
- Generate a default interface name based on the server URL.
- If the generated interface already exists don't try to use it
and fallback to using the first available adapter.
- If the generated interface doesn't exist, try to create a wintun
adapter. If wintun in not available then fallback to using the first
available adapter.
See https://gitlab.com/openconnect/openconnect-gui/-/issues/357#note_1758999655
and https://gitlab.com/openconnect/openconnect/-/issues/699#note_1762029017
Enumerate adapters to a list to decouple searching from enumerating.
Add adapters with of not interested types to the list, to facilitate name
collision detection, if needed.
Get Wintun adapter guid by calling APIs instead of searching again.
Daniel Lenski [Sun, 28 Jul 2024 00:38:01 +0000 (17:38 -0700)]
Update changelog
This also addresses the closely-related issue described in
https://gitlab.com/openconnect/openconnect/-/merge_requests/500, where
OpenConnect would prefer a GP server's IPv6 magic ping adress over its
Legacy IP magic ping address, even if `--disable-ipv6` is specified:
> Previous logic always preferred the ipv6 gateway address and magic for ESP
> even if ipv6 was explicitly disabled. A VPN I use currently will only
> negotiate an ESP connection over ipv4 despite advertising a v6 gateway.
This similarly results in non-functional ESP:
> The result was that with ipv6 enabled, ESP pings were sent but would not
> renegotiate, with it disabled openconnect would erroneously report that
> the response did not contain a matching gateway and keys.
Daniel Lenski [Sat, 27 Jul 2024 22:04:58 +0000 (15:04 -0700)]
Add a fake IPSEC/ESP configuration to fake-gp-server.py
This allows testing for correct interpretation of the ESP configuration, as in
https://lists.infradead.org/pipermail/openconnect-devel/2024-July/005447.html
Also needed to fix a mistake in the logout handler of fake-gp-server.py
("POST not GET"), and an oversight in how GP propagated errors when falling
back to TLS tunnel from ESP.
Daniel Lenski [Sat, 27 Jul 2024 17:58:28 +0000 (10:58 -0700)]
GP server may send only a Legacy IP client address, but both Legacy and IPv6 magic addresses for ESP
In this corner case, we need to use the Legacy IP magic address. The
inverse corner case would be if the server sends ESP ping magic addresses of
both types, but only sends an IPv6 client address; we were already handling
that one correctly, because we had observed that GlobalProtect servers
require the client to use the IPv6 magic ping address if they want to send
both IPv6 and Legacy IP traffic.
The easiest and most straightforward way to handle all these cases robustly
is simply to save both versions of the ESP magic address, just as we save
both versions of the client address, until after we have parsed the whole
config. At that point we decide which ESP magic address should be used.
See logs attached to
https://lists.infradead.org/pipermail/openconnect-devel/2024-July/005447.html
for an example of this:
POST https://vpnhost.example.com/ssl-vpn/getconfig.esp
…
< <gw-address>REDACTEDIPV4ADDRESS7</gw-address>
< <gw-address-v6>REDACTEDIPV6ADDRESS7</gw-address-v6>
< <ipv6-connection>no</ipv6-connection>
< <ip-address>REDACTEDIPV4ADDRESS0</ip-address>
< <netmask>255.255.255.255</netmask>
…
< <ipsec>…</ipsec>
Did not receive ESP keys and matching gateway in GlobalProtect config; tunnel will be TLS only.
Nikos Mavrogiannopoulos [Fri, 10 May 2024 18:29:44 +0000 (20:29 +0200)]
.gitlab-ci.yml: use saas-linux-small-amd64 as tag
The linux and shared tags are deprecated:
https://docs.gitlab.com/ee/update/deprecations.html?removal_milestone=17.0#removal-of-tags-from-small-saas-runners-on-linux
Dimitri Papadopoulos [Wed, 28 Feb 2024 06:31:00 +0000 (07:31 +0100)]
Search wintun.dll in the application directory only
Now that wintun.dll is installed in the application directory by
both openconnect and openconnect-gui packages, we can get rid of
LOAD_LIBRARY_SEARCH_SYSTEM32.
Wade Cline [Wed, 28 Feb 2024 03:19:00 +0000 (19:19 -0800)]
Fix logging of rekey / trojan invocation delay
Closes #677
The rekey / trojan invocation is supposed to happen in the future.
Therefore subtract current time from expected time of rekey / invocation,
not the reverse.
Marios Paouris [Thu, 22 Feb 2024 10:03:01 +0000 (12:03 +0200)]
MinGW build improvements
- Decoupled wintun and vpnc-script-win.js from building installer.
- Added required dependencies for downloading wintun and vpnc-script-win.js.
- Install wintun, vpnc-script-win.js and list-system-keys by default.
- Added configure option to disable building installer (doesn't work in
msys/mingw builds, can also speedup build when no installer required).
Nikos Mavrogiannopoulos [Wed, 21 Feb 2024 21:24:56 +0000 (22:24 +0100)]
openssl-dtls: use DTLS 1.2 for PSK-NEGOTIATE
Avoid reducing the security level for PSK-NEGOTIATE by
setting DTLS 1.2. This works well because all PSK-NEGOTIATE
ocserv servers are using gnutls that supports DTLS 1.2.
This addresses a previously undetermined issue with DTLS on centos7.
The openconnect client disables DTLS if it fails to
connect. Openconnect-gui couldn't do that because of
the restrictions of openconnect_disable_dtls(). This
MR removes those restrictions and allows disabling DTLS
even if we attempted connection before.
Daniel Lenski [Fri, 29 Sep 2023 20:51:07 +0000 (13:51 -0700)]
Modify `fake-gp-server.py` to add regionalized priority-rules to the gateway list
The fake GP server will now assign the connecting user to a random planet in
its portal prelogin response, then randomly and haphazardly prioritize the
gateways by planet.
For example, start fake-gp-server.py, then configure it with 3 gateways:
$ curl -k https://localhost:8080/CONFIGURE -d gateways=Red,Orange,Yellow
$ curl -k https://localhost:8080/CONFIGURE
Current configuration of fake GP server configuration:
TestConfiguration(gateways=['Red', 'Orange', 'Yellow'], ...)
Then attempt to connect to it:
$ openconnect --protocol=gp --dump-http-traffic localhost:8080
...
Greetings, user from MERCURY. Please login to this fake GP VPN portal
Username: bar
Password:
POST https://localhost:8080/global-protect/getconfig.esp
...
< <?xml version="1.0" encoding="UTF-8" ?>
< <policy><version> 6.7.8-9 </version><gateways><external><list>
< <entry name="localhost:8080">
< <description>Red</description>
< <priority-rule>
< <entry name="VENUS"><priority>1</priority></entry>
< <entry name="Any"><priority>99</priority></entry>
< </priority-rule>
< </entry>
< <entry name="localhost:8080">
< <description>Orange</description>
< <priority-rule>
< <entry name="JUPITER"><priority>2</priority></entry>
< <entry name="MARS"><priority>1</priority></entry>
< </priority-rule>
< </entry>
< <entry name="localhost:8080">
< <description>Yellow</description>
< <priority-rule>
< <entry name="MERCURY"><priority>1</priority></entry>
< <entry name="EARTH"><priority>2</priority></entry>
< </priority-rule>
< </entry></list>
< </external></gateways>
< <hip-collection><hip-report-interval>600</hip-report-interval></hip-collection>
< </policy>
Portal reports GlobalProtect version 6.7.8-9; we will report the same client version.
Portal set HIP report interval to 10 minutes).
5 gateway servers available:
Red (localhost:8080) [priority 99]
Orange (localhost:8080) [unprioritized]
Yellow (localhost:8080) [priority 1]
Please select GlobalProtect gateway.
GATEWAY: [Yellow|Red|Orange]:
Note that the gateways are now presented to the user in the priority order
for the user's "region" of MERCURY.
Starting from version 8.0, PAN GlobalProtect portal servers are able to send
a priority rule list for each gateway. Per
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClSsCAK,
the gateways can be prioritized by geographic region.
The gateways should then be presented to the user in order of geographic
priority, rather than just in their order of appearance in
policy/gateways/external/list (from the portal config XML).
How does the client know which geographic region it is in?
1. The client itself may have some way to figure out which region it is
connecting from (e.g. geolocation, not implemented yet for OpenConnect).
2. The client may have an option to explicitly specifiy the desired region
(not implemented yet in OpenConnect).
3. The *server* tells the client which region it thinks the client is
connecting from, in the portal *prelogin* response, and the client
follows that (implemented here).
Fixes: https://gitlab.com/openconnect/openconnect/-/issues/663
[DRL fixed a small mistake in qsort usage, and tweaked code structure,
comments, and log messages.]
Signed-off-by: Jan-Michael Brummer <jan-michael.brummer1@volkswagen.de> Signed-off-by: Daniel Lenski <dlenski@gmail.com>
Daniel Lenski [Tue, 20 Feb 2024 06:12:20 +0000 (22:12 -0800)]
Update changelog
This bug in GlobalProtect IPv6 split-include handling was introduced in
https://gitlab.com/openconnect/openconnect/-/commit/a2b8134edf8e5f8e942dedf105e2813a0824b919;
see also
https://gitlab.com/openconnect/openconnect/-/merge_requests/367#note_1780223796.
Daniel Loxtermann [Tue, 20 Feb 2024 01:59:47 +0000 (17:59 -0800)]
Fix GlobalProtect config-parsing bug that misidentified IPv6 split-include routes as split-exclude
As reported on the mailing list at
https://lists.infradead.org/pipermail/openconnect-devel/2024-January/005386.html,
the relevant code wasn't handling the IPv6 case correctly.
Daniel Lenski [Mon, 25 Sep 2023 14:14:37 +0000 (07:14 -0700)]
Send 'cas-support=yes' in GlobalProtect prelogin request
Per https://gitlab.com/openconnect/openconnect/-/issues/651, some newer GP
servers are responding to prelogin.esp requests with an error:
CAS is not supported by the client. Minimum client version is 6.0
It appears that CAS ("Central Authentication Server";
https://apereo.github.io/cas/index.html) is a standardized single-sign-on
protocol requiring an external browser.
Per https://gitlab.com/openconnect/openconnect/-/issues/651#note_1576596243,
the field 'cas-support=yes' needs to be sent in the POST *body* of the
prelogin request, in order to avoid this error message; the error message's
claim that a specific client software version is necessary isn't very
helpful.
Daniel Lenski [Tue, 26 Sep 2023 19:08:45 +0000 (12:08 -0700)]
Real GlobalProtect SAML authentication forms won't work without JavaScript
This adds a 'saml_needs_js' option to fake-gp-server.py. If set, the fake
SAML login form that it generates won't work correctly without JavaScript
execution, just like a "real" GlobalProtect SAML server.
Jon DeVree [Sat, 3 Feb 2024 17:09:58 +0000 (12:09 -0500)]
Force final newline in xmlstarlet
By default xmlstarlet does not include a final newline on the output.
Because POSIX says that all lines must end in a newline, this causes the
final line of output to be skipped by the 'while read ...' loop in bash.
Adding a '-n' after the '-v ...' causes xmlstarlet to include a final
newline at the end of its output.
projects / users / dwmw2 / openconnect.git / log