From joe.elusive at protonmail.com  Thu Jun  1 06:54:09 2023
From: joe.elusive at protonmail.com (joe.elusive)
Date: Thu, 01 Jun 2023 13:54:09 +0000
Subject: Testing of openconnect on  "real" firewalls
Message-ID: <_A0LqFAr3cKKJOe43PnNujaTAr9U3xsU14QjolCOgaczZQTv2mieDpYg3vGnDQjJbZULqs5ESB-NZanJb-F4k4M9FVOO11jLG13F_yTrg4Y=@protonmail.com>

Hey everyone!

I noticed that openconnect project relies on?

1. Maintainers having access to real hardware
2. Issue reporter providing a lot of log files/dumps for maintainers to work on

While (1) is not ideal because not every maintainer has access to firewalls in question, (2) is limited too because sometimes it's really hard to get enough info, and not every bug reporter can even give exact firewall software version info, not to mention a relevant configuration of firewall.

Here comes my suggestion/question:

Would you accept a pull request with some kind of local firewall deployment automation, for developers to experiment on (if they have time, of course)?

I imagine the following artifacts:

1. Shell scripts/Vagrant Box to bring VM up
2. Ansible playbooks (maybe triggered from vagrant itself) for idempotent configuration of VPN in question

So in best case scenario, to reproduce some case, developer should:

get a .qcow2 file of virtual firewall in question (the hardest part),
cd to

    integration/anyconnect/asav-x.y.z-some-test-case

and execute 
   
    vagrant up

, then get a preferred beverage while vagrant and ansible prepares a test environment for them, and start hacking!

The other variant is to utilize GNS3, or even EVE-NG for creating and sharing topologies, but i think that:
a) Vagrant and ansible are more usable in other day-to-day tasks for developer enthusiast, and more transferable as skills to use on other projects, making them more interesting/rewarding
b) I want a workflow to be as pain-free as possible, because getting images to work on is a pain already, and executing single command seems simple enough
c) We don't need "a topology", we need one firewall with "public" and "private" interface, without outbound internet access, and a SSL-VPN daemon to interact with, nothing more, so a single VM seems good enough
d) Some advanced cases might require other VMs/Containers, i.e. radius server, SSO server and so one, and GNS3 and friends are not really the tools to deploy and maintain that.

There are some conceptual questions though:

1. Vagrant is not that portable, and cisco, for example, targets KVM, ESXi and HyperV only, leaving VirtualBox users and whatever macOS has as hypervisor for themselves 
2. Ansible is also "best served" on linux
3. I don't have anything other that linux to test and support this on, so basically i hope that developers are linux users themselves
4. Getting a proper OS image would most certainly require some kind of support contract, and while checksums of images are mostly accessible from vendor websites, and there are a lot of images lying on some nice http/ftp servers around the web, some people might not even bother downloading and checking them, due to legality concerns and their limited free time

So, before i started hacking in this direction (which might even fail due to some Vagrant issues), would maintainers of openconnect even be interested in this?

And hey, thanks for giving me an opportunity to work on my favorite OS for years, without tainting my machine with some proprietary cr.. i mean, software.

With best regards,
Joe
    




From michael.herzhauser at innovate-gmbh.de  Tue Jun  6 01:09:20 2023
From: michael.herzhauser at innovate-gmbh.de (Michael Herzhauser)
Date: Tue, 6 Jun 2023 10:09:20 +0200
Subject: Split Tunneling based on domain name possible?
Message-ID: <000401d9984e$32a75b40$97f611c0$@innovate-gmbh.de>

Hello, 

I've setup Ocserv in my corporate network with split tunneling and it's
working good so far.
However some of my colleagues in home office need to connect to some cloud
servers of 
our customers, which implement IP whitelisting to our company's public IP. 
Due to split tunneling, requests to these cloud servers are not routed via
VPN but the normal
internet connection and the connection gets blocked.

Therefore I'd like to add a route based on the domain name of these servers 
(public IPs of these servers are dynamically assigned and change
frequently), but didn't find 
any information about that. All the examples in the config file only use IP
addresses.

Is it even possible? And if so, any info on syntax (e.g wildcards for
subdomains) would be great to have.
Otherwise I'd have to convert to "tunnel all", which I'm trying to avoid.

Thanks in advance
Michael Herzhauser



From dwmw2 at infradead.org  Tue Jun  6 01:14:48 2023
From: dwmw2 at infradead.org (David Woodhouse)
Date: Tue, 06 Jun 2023 09:14:48 +0100
Subject: Split Tunneling based on domain name possible?
In-Reply-To: <000401d9984e$32a75b40$97f611c0$@innovate-gmbh.de>
References: <000401d9984e$32a75b40$97f611c0$@innovate-gmbh.de>
Message-ID: <7050a6f7cd545370cd40dd8df956f0dd581fedca.camel@infradead.org>

On Tue, 2023-06-06 at 10:09 +0200, Michael Herzhauser wrote:
> Hello, 
> 
> I've setup Ocserv in my corporate network with split tunneling and it's
> working good so far.
> However some of my colleagues in home office need to connect to some cloud
> servers of 
> our customers, which implement IP whitelisting to our company's public IP. 
> Due to split tunneling, requests to these cloud servers are not routed via
> VPN but the normal
> internet connection and the connection gets blocked.
> 
> Therefore I'd like to add a route based on the domain name of these servers 
> (public IPs of these servers are dynamically assigned and change
> frequently), but didn't find 
> any information about that. All the examples in the config file only use IP
> addresses.
> 
> Is it even possible? And if so, any info on syntax (e.g wildcards for
> subdomains) would be great to have.
> Otherwise I'd have to convert to "tunnel all", which I'm trying to avoid.

I think we did have something like this implemented on the client side
in ConnMan once. It would monitor the DNS lookups and automatically add
routes to the target IP address.

Probably easier to do it with a proxy PAC file though, and set the
relevant domains to use a proxy within your corporate network.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5965 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20230606/59b61536/attachment.p7s>

From dlenski at gmail.com  Tue Jun  6 13:13:43 2023
From: dlenski at gmail.com (Daniel Lenski)
Date: Tue, 6 Jun 2023 13:13:43 -0700
Subject: Send --authgroup as <group-select> in initial POST request
In-Reply-To: <FR2P281MB3342517D046A54C877AA0C03F0489@FR2P281MB3342.DEUP281.PROD.OUTLOOK.COM>
References: <FR2P281MB3342517D046A54C877AA0C03F0489@FR2P281MB3342.DEUP281.PROD.OUTLOOK.COM>
Message-ID: <CAOw_LSEADF4PZ0WXn1_HnvGfEbHyNT=DOD++Hrg6BKiEvO8A7Q@mail.gmail.com>

On Wed, May 31, 2023 at 3:48?AM Popp, Thomas <Thomas.Popp at akquinet.de> wrote:
> The Cisco VPN server I try to connect to expects the correct authgroup to be send as <group-select> in the initial POST request, like:
>
> <config-auth client="vpn" type="auth-request" aggregate-auth-version="2">
>   ...
>   <group-select>correct-auth-group</group-select>
>   ...
> </config-auth>
>

<snip>

> I also failed to manipulate the initial POST request form with the --form-entry parameter, like
> --form-entry main:group-select=correct-auth-group
> or
> --form-entry init:group-select=correct-auth-group
>
> I came to realize, that openconnect is designated to send the <group-select> node,  as can be seen in the code of auth.c in line 929:
> https://gitlab.com/openconnect/openconnect/-/blob/master/auth.c#L929
>
> However, it doesn't and I can't tell why. Any idea how to fix the problem?

The way this works is a bit subtle.

Providing `--authgroup Foo` on the command-line does not directly set
`vpninfo->authgroup`, which means that the `<group-select>` node never
gets set in the *initial* XML POST request (root tag is `<config-auth
type="init">`).

Rather, OpenConnect expects that the *response* to the initial POST
will include a list of *allowed* groups. Something like this:

    <form>?<select name="group_list"
label="GROUP:"><option>Foobar</option><option>Baz</option>?</select></form>

After receiving that list, OpenConnect attempts to match the
`--authgroup Foo` from the command line to the allowed list
(https://gitlab.com/openconnect/openconnect/-/blob/master/main.c#L2762-2776),
and assuming a successful match it will send the `<group-select>` in
its *subsequent* XML POST (root tags will be either `<config-auth
type="init">` or `type="auth-reply"`).

I have never seen a Cisco server that actually requires the
`<group-select>` to appear in the *initial* POST request, and am
skeptical that this is what your VPN actually requires That would not
allow the client to discover the allowed groups on initial connection,
because the allowed groups won't be known to a client until it has
connected and retrieved the list at least onece.

> Otherwise the server will send a wrong <sso-v2-login> path in the reponse.
>
> However, openconnect v9.12-0+3.1 seems to ignore the --authgroup parameter for that purpose.

Assuming that this worked without issue on older versions of
OpenConnect, I suspect that the problem you are encountering is
actually the same as in
https://gitlab.com/openconnect/openconnect/-/issues/620#note_1415467462,
namely that the server is confused by OpenConnect v9.12 offering newer
SSO-based auth modes, or *STRAP* HTTP headers.

Try adding `--no-external-auth` to the command-line and see if that
makes a difference?


From u-dash at u-dash.hu  Wed Jun  7 06:26:28 2023
From: u-dash at u-dash.hu (Laszlo Fekete)
Date: Wed, 7 Jun 2023 15:26:28 +0200
Subject: yubikey as 2nd factor
Message-ID: <48d969c3-5233-fc73-2282-bb11e281545f@u-dash.hu>

dear development team,

I'm using openconnect from command line to connect to AnyConnect 
protocol if I need to. Until now I was using okta app to generate a 6 
digit secondary password, which was working just fine, however I try to 
avoid using iOS/Android based applications as my own device contains 
none of them, and only used workaround to be able to run the apk version 
of Okta.

My yubikey is registered through okta and working just fine in every 
places I previously used the 6 digit okta based password but the 
openconnect CLI ( cisco's own GUI vpn tool also doesn't accept the 
yubikey generated characters as a 2nd password )

can you please help me with this?


thanks in advance


regards


Laszlo Fekete



From traxtopel at gmail.com  Thu Jun  8 02:29:39 2023
From: traxtopel at gmail.com (Grant Williamson)
Date: Thu, 8 Jun 2023 11:29:39 +0200
Subject: NetworkManager-openconnect /etc/nm-openconnect/openconnect.ini
Message-ID: <CACNAWW9MBbuTigQNbodCwuaxy9D3esNAvUFNzn6gGY3dRpXaEw@mail.gmail.com>

The following patch allows for the addition of arguments through a
system file. The patch looks for a file named "openconnect.ini" in the
"/etc/nm-openconnect/" directory. If the file exists, it reads its
contents and searches for a line that starts with "ARGS=". If such a
line is found, it extracts the arguments and adds them to the
/usr/sbin/openconnect that is spawn during connecting.

This patch probably needs need some tlc.

diff -ur NetworkManager-openconnect-1.2.10.orig/src/nm-openconnect-service.c
NetworkManager-openconnect-1.2.10/src/nm-openconnect-service.c
--- NetworkManager-openconnect-1.2.10.orig/src/nm-openconnect-service.c
2023-05-10 12:10:35.000000000 +0200
+++ NetworkManager-openconnect-1.2.10/src/nm-openconnect-service.c
2023-06-08 11:06:26.306545502 +0200
@@ -41,6 +41,7 @@
 #include <pwd.h>
 #include <grp.h>
 #include <locale.h>
+#include <glib.h>

 #include "nm-utils/nm-shared-utils.h"
 #include "nm-utils/nm-vpn-plugin-macros.h"
@@ -581,6 +582,37 @@
  g_ptr_array_add (openconnect_argv, (gpointer) "--verbose");
  }

+  // Allow for arguments to be added via a system file
+  char systemCommand[MAX_ARGS_LENGTH];
+  FILE *file = fopen("/etc/nm-openconnect/openconnect.ini", "r");
+  if (file != NULL) {
+    char args[MAX_ARGS_LENGTH];
+    while (fgets(args, sizeof(args), file)) {
+      if (strncmp(args, "ARGS=", 5) == 0) {
+        memmove(args, args + 5, strlen(args) - 5 + 1);
+        break;
+      }
+    }
+    fclose(file);
+    if (strlen(args) > 0) {
+      char *quoteStart = strchr(args, '\"');
+      if (quoteStart != NULL) {
+        char *quoteEnd = strchr(quoteStart + 1, '\"');
+        if (quoteEnd != NULL) {
+            memmove(quoteStart, quoteStart + 1, quoteEnd - quoteStart);
+            quoteEnd[-1] = '\0';
+        }
+      }
+      char *token;  // Declaration of 'token'
+      char *delimiter = " ";  // Delimiter for strtok
+      token = strtok(args, delimiter);
+      while (token != NULL) {
+        g_ptr_array_add (openconnect_argv, token);
+        token = strtok(NULL, delimiter);
+      }
+    }
+  }
+
  g_ptr_array_add (openconnect_argv, NULL);

  if (!g_spawn_async_with_pipes (NULL, (char **) openconnect_argv->pdata, NULL,
diff -ur NetworkManager-openconnect-1.2.10.orig/src/nm-openconnect-service.h
NetworkManager-openconnect-1.2.10/src/nm-openconnect-service.h
--- NetworkManager-openconnect-1.2.10.orig/src/nm-openconnect-service.h
2019-08-06 13:34:19.000000000 +0200
+++ NetworkManager-openconnect-1.2.10/src/nm-openconnect-service.h
2023-06-08 11:05:33.871183932 +0200
@@ -31,6 +31,7 @@
 #define NM_IS_OPENCONNECT_PLUGIN(obj)
(G_TYPE_CHECK_INSTANCE_TYPE ((obj), NM_TYPE_OPENCONNECT_PLUGIN))
 #define NM_IS_OPENCONNECT_PLUGIN_CLASS(klass)
(G_TYPE_CHECK_CLASS_TYPE ((klass), NM_TYPE_OPENCONNECT_PLUGIN))
 #define NM_OPENCONNECT_PLUGIN_GET_CLASS(obj)
(G_TYPE_INSTANCE_GET_CLASS ((obj), NM_TYPE_OPENCONNECT_PLUGIN,
NMOpenconnectPluginClass))
+#define MAX_ARGS_LENGTH 1024

 typedef struct {
  NMVpnServicePlugin parent;


From dlenski at gmail.com  Sun Jun 11 21:40:32 2023
From: dlenski at gmail.com (Daniel Lenski)
Date: Sun, 11 Jun 2023 21:40:32 -0700
Subject: yubikey as 2nd factor
In-Reply-To: <48d969c3-5233-fc73-2282-bb11e281545f@u-dash.hu>
References: <48d969c3-5233-fc73-2282-bb11e281545f@u-dash.hu>
Message-ID: <CAOw_LSH78sM0KE5tz02Q8zPHRnbgswBQOPO8H2Rc7GfRNGurUg@mail.gmail.com>

On Wed, Jun 7, 2023 at 7:03?AM Laszlo Fekete <u-dash at u-dash.hu> wrote:
> cisco's own GUI vpn tool also doesn't accept the
> yubikey generated characters as a 2nd password

This strongly suggests that the *server* doesn't accept the Yubikey
OTP as a 2nd factor. ?????

> can you please help me with this?

It's extremely unlikely that OpenConnect, or any other *client*
software, can do anything about a *server* not being configured to
accept a specific 2nd factor for your account.

You'd need to talk to your VPN's administrators, and ask them to
configure the server to accept the Yubikey 2nd factor, in order to
change this situation.

Daniel


From Thomas.Popp at akquinet.de  Mon Jun 12 00:37:12 2023
From: Thomas.Popp at akquinet.de (Popp, Thomas)
Date: Mon, 12 Jun 2023 07:37:12 +0000
Subject: AW: Send --authgroup as <group-select> in initial POST request
In-Reply-To: <CAOw_LSEADF4PZ0WXn1_HnvGfEbHyNT=DOD++Hrg6BKiEvO8A7Q@mail.gmail.com>
References: <FR2P281MB3342517D046A54C877AA0C03F0489@FR2P281MB3342.DEUP281.PROD.OUTLOOK.COM>
 <CAOw_LSEADF4PZ0WXn1_HnvGfEbHyNT=DOD++Hrg6BKiEvO8A7Q@mail.gmail.com>
Message-ID: <FR2P281MB3342C5414DEAEE3809823909F054A@FR2P281MB3342.DEUP281.PROD.OUTLOOK.COM>

Thank you for your answer.

> Rather, OpenConnect expects that the *response* to the initial POST will include a list of *allowed* groups. Something like this:
>??? <form>?<select name="group_list" label="GROUP:"><option>Foobar</option><option>Baz</option>?</select></form>
> After receiving that list, OpenConnect attempts to match the `--authgroup Foo` from the command line to the allowed list (https://gitlab.com/openconnect/openconnect/-/blob/master/main.c#L2762-2776), and assuming a successful match it will send the `<group-select>` in its *subsequent* XML POST (root tags will be either `<config-auth type="init">` or `type="auth-reply"`).

Thanks, I was assuming this. So apparently I have the problem, that Openconnect does not do this subsequent POST request.

What's happening is, that the server does send a list of groups in the select form. Openconnect recognizes those, by prompting me to type in my selection if I do not use the `--authgroup`-parameter. It does recognize the `--authgroup`-parameter by skipping this prompt.
However, after the prompt (or skipping it) Openconnect does not do any further requests to the VPN server (at least `--dump-http-traffic` does not print any) but instead picks the url from the `<sso-v2-login>` from the first response and tries to open a browser with it. In this url however there is the wrong authgroup coded in (since it is from before selecting anything).

What could be the reason for Openconnect not to do the subsequent request? Is there something missing from the server response? Does Openconnect maybe pass on sending a second request if the server already send a `<sso-v2-login>`-field in the first request?

> Assuming that this worked without issue on older versions of OpenConnect, I suspect that the problem you are encountering is actually the same as in
https://gitlab.com/openconnect/openconnect/-/issues/620#note_1415467462, namely that the server is confused by OpenConnect v9.12 offering newer
SSO-based auth modes, or *STRAP* HTTP headers.
> Try adding `--no-external-auth` to the command-line and see if that makes a difference?

It does not work with older clients and `--no-external-auth` unfortunately does not help.


Von: Daniel Lenski <dlenski at gmail.com>
Gesendet: Dienstag, 6. Juni 2023 22:13
An: Popp, Thomas <Thomas.Popp at akquinet.de>
Cc: openconnect-devel at lists.infradead.org <openconnect-devel at lists.infradead.org>
Betreff: Re: Send --authgroup as <group-select> in initial POST request 
?
On Wed, May 31, 2023 at 3:48?AM Popp, Thomas <Thomas.Popp at akquinet.de> wrote:
> The Cisco VPN server I try to connect to expects the correct authgroup to be send as <group-select> in the initial POST request, like:
>
> <config-auth client="vpn" type="auth-request" aggregate-auth-version="2">
>?? ...
>?? <group-select>correct-auth-group</group-select>
>?? ...
> </config-auth>
>

<snip>

> I also failed to manipulate the initial POST request form with the --form-entry parameter, like
> --form-entry main:group-select=correct-auth-group
> or
> --form-entry init:group-select=correct-auth-group
>
> I came to realize, that openconnect is designated to send the <group-select> node,? as can be seen in the code of auth.c in line 929:
> https://gitlab.com/openconnect/openconnect/-/blob/master/auth.c#L929
>
> However, it doesn't and I can't tell why. Any idea how to fix the problem?

The way this works is a bit subtle.

Providing `--authgroup Foo` on the command-line does not directly set
`vpninfo->authgroup`, which means that the `<group-select>` node never
gets set in the *initial* XML POST request (root tag is `<config-auth
type="init">`).

Rather, OpenConnect expects that the *response* to the initial POST
will include a list of *allowed* groups. Something like this:

??? <form>?<select name="group_list"
label="GROUP:"><option>Foobar</option><option>Baz</option>?</select></form>

After receiving that list, OpenConnect attempts to match the
`--authgroup Foo` from the command line to the allowed list
(https://gitlab.com/openconnect/openconnect/-/blob/master/main.c#L2762-2776),
and assuming a successful match it will send the `<group-select>` in
its *subsequent* XML POST (root tags will be either `<config-auth
type="init">` or `type="auth-reply"`).

I have never seen a Cisco server that actually requires the
`<group-select>` to appear in the *initial* POST request, and am
skeptical that this is what your VPN actually requires That would not
allow the client to discover the allowed groups on initial connection,
because the allowed groups won't be known to a client until it has
connected and retrieved the list at least onece.

> Otherwise the server will send a wrong <sso-v2-login> path in the reponse.
>
> However, openconnect v9.12-0+3.1 seems to ignore the --authgroup parameter for that purpose.

Assuming that this worked without issue on older versions of
OpenConnect, I suspect that the problem you are encountering is
actually the same as in
https://gitlab.com/openconnect/openconnect/-/issues/620#note_1415467462,
namely that the server is confused by OpenConnect v9.12 offering newer
SSO-based auth modes, or *STRAP* HTTP headers.

Try adding `--no-external-auth` to the command-line and see if that
makes a difference?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7746 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/openconnect-devel/attachments/20230612/da1c9ccd/attachment-0001.p7s>

From lixo at geeksmith.net  Wed Jun 21 20:02:07 2023
From: lixo at geeksmith.net (Aaron Smith)
Date: Wed, 21 Jun 2023 20:02:07 -0700
Subject: DNS server list has strange separator
Message-ID: <e9c81bed-4562-ee99-39ea-86296c547bf6@geeksmith.net>

Running on Ubuntu 23.04 and connecting to a system Fortinet running version
4.71.113.194.

After successful connection, the VPN routes and DNS server settings are 
applied
to my system. The DNS server list is correct, but the servers are 
separate by
'059' instead of a space character, as displayed by 'resolvectl' below

~/ resolvectl status
Link 2 (enxe04f439490d4) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR
-mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 172.22.11.1 DNS
Servers: 172.22.11.1 DNS Domain: redacted.net

Link 3 (wlp0s20f3) Current Scopes: none Protocols: -DefaultRoute +LLMNR 
-mDNS
-DNSOverTLS DNSSEC=no/unsupported

Link 4 (vpn00449b7858) Current Scopes: none Protocols: -DefaultRoute +LLMNR
-mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (vpn00fa8f88cb) Current Scopes: none Protocols: -DefaultRoute +LLMNR
-mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 6 (tun0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS
-DNSOverTLS DNSSEC=no/unsupported

Link 22 (tun1) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS
-DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.0.60.2 DNS Servers:
10.0.60.2 10.0.60.3 DNS Domain: ns1.redacted.com\059ns2.redacted.com

~/ openconnect --version OpenConnect version v9.01-3 Using GnuTLS 3.7.8.
Features present: TPMv2, PKCS#11, RSA software token, HOTP software 
token, TOTP
software token, Yubikey OATH, System keys, DTLS, ESP Supported protocols:
anyconnect (default), nc, gp, pulse, f5, fortinet, array Default vpnc-script
(override with --script): /usr/share/vpnc-scripts/vpnc-script
Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported resolv.conf
mode: stub DNS Domain redacted.com private.net


From dimitri.papadopoulos at cea.fr  Thu Jun 22 07:21:32 2023
From: dimitri.papadopoulos at cea.fr (Dimitri Papadopoulos)
Date: Thu, 22 Jun 2023 16:21:32 +0200
Subject: DNS server list has strange separator
In-Reply-To: <e9c81bed-4562-ee99-39ea-86296c547bf6@geeksmith.net>
References: <e9c81bed-4562-ee99-39ea-86296c547bf6@geeksmith.net>
Message-ID: <df721d8f-a229-6e79-4554-cb938937b9ec@cea.fr>

Hi,

Note that 59 is the decimal ASCII encoding for ";".

Also, 59 cannot is not an octal number, making the "\059" notation even 
more awkward.

Therefore I suspect this is a problem with the Fortigate configuration. 
Using my own corporate VPN, I do not see such a character:

At some point openconnect reports:

Got search domain 
intra.xxxx.xxx;extra.xxxx.xxx;saclay.xxxx.xxx;partenaires.xxxx.xxx;xxxx.xxx

And after connecting, resolvectl reports:

$ resolvectl
Global
        Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub

Link 2 (enp0s31f6)
     Current Scopes: DNS
          Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS 
DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
        DNS Servers: 8.8.8.8 192.168.0.254

Link 3 (tun0)
     Current Scopes: DNS
          Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS 
DNSSEC=no/unsupported
Current DNS Server: xxx.xxx.xxx.7
        DNS Servers: xxx.xxx.xxx.7 xxx.xxx.xxx.6
         DNS Domain: xxxx.xxx extra.xxxx.xxx intra.xxxx.xxx 
partenaires.xxxx.xxx saclay.xxxx.xxx



We could work around this peculiar separator, but human imagination has 
no limits, so where should we stop? More importantly, how do we know the 
separator is "\059" and not "\"? I haven't read recent DNS RFCs, but I 
suspect that "059ns2.redacted.com" is as legit as "ns2.redacted.com" 
nowadays.

Let's try a different angle: Does FortiCLient handle this in a better way?

Dimitri

Le 22/06/2023 ? 05:02, Aaron Smith a ?crit?:
> Running on Ubuntu 23.04 and connecting to a system Fortinet running version
> 4.71.113.194.
> 
> After successful connection, the VPN routes and DNS server settings are 
> applied
> to my system. The DNS server list is correct, but the servers are 
> separate by
> '059' instead of a space character, as displayed by 'resolvectl' below
> 
> ~/ resolvectl status
> Link 2 (enxe04f439490d4) Current Scopes: DNS Protocols: +DefaultRoute 
> +LLMNR
> -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 172.22.11.1 DNS
> Servers: 172.22.11.1 DNS Domain: redacted.net
> 
> Link 3 (wlp0s20f3) Current Scopes: none Protocols: -DefaultRoute +LLMNR 
> -mDNS
> -DNSOverTLS DNSSEC=no/unsupported
> 
> Link 4 (vpn00449b7858) Current Scopes: none Protocols: -DefaultRoute +LLMNR
> -mDNS -DNSOverTLS DNSSEC=no/unsupported
> 
> Link 5 (vpn00fa8f88cb) Current Scopes: none Protocols: -DefaultRoute +LLMNR
> -mDNS -DNSOverTLS DNSSEC=no/unsupported
> 
> Link 6 (tun0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS
> -DNSOverTLS DNSSEC=no/unsupported
> 
> Link 22 (tun1) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS
> -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.0.60.2 DNS 
> Servers:
> 10.0.60.2 10.0.60.3 DNS Domain: ns1.redacted.com\059ns2.redacted.com
> 
> ~/ openconnect --version OpenConnect version v9.01-3 Using GnuTLS 3.7.8.
> Features present: TPMv2, PKCS#11, RSA software token, HOTP software 
> token, TOTP
> software token, Yubikey OATH, System keys, DTLS, ESP Supported protocols:
> anyconnect (default), nc, gp, pulse, f5, fortinet, array Default 
> vpnc-script
> (override with --script): /usr/share/vpnc-scripts/vpnc-script
> Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported 
> resolv.conf
> mode: stub DNS Domain redacted.com private.net
> 
> _______________________________________________
> openconnect-devel mailing list
> openconnect-devel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/openconnect-devel

-- 
Dimitri Papadopoulos
Universit? Paris-Saclay, CEA, NeuroSpin
91191 Gif-sur-Yvette
France
+33 (0)1 69 08 79 12


From dimitri.papadopoulos at cea.fr  Thu Jun 22 08:04:25 2023
From: dimitri.papadopoulos at cea.fr (Dimitri Papadopoulos)
Date: Thu, 22 Jun 2023 17:04:25 +0200
Subject: DNS server list has strange separator
In-Reply-To: <df721d8f-a229-6e79-4554-cb938937b9ec@cea.fr>
References: <e9c81bed-4562-ee99-39ea-86296c547bf6@geeksmith.net>
 <df721d8f-a229-6e79-4554-cb938937b9ec@cea.fr>
Message-ID: <01ad80e1-9e80-5054-965a-1077047b564a@cea.fr>

By the way, FortiOS 4.71.113.194 seems utterly old and unmaintained, not 
to mention vulnerable. Are you sure about it?

Also, I was under the impression that FortiOS 4.* sends the VPN 
configuration in a legacy (HTML?) format OpenCOnnect does not parse, not 
the current XML format.

Dimitri

Le 22/06/2023 ? 16:21, Dimitri Papadopoulos a ?crit?:
> Hi,
> 
> Note that 59 is the decimal ASCII encoding for ";".
> 
> Also, 59 cannot is not an octal number, making the "\059" notation even 
> more awkward.
> 
> Therefore I suspect this is a problem with the Fortigate configuration. 
> Using my own corporate VPN, I do not see such a character:
> 
> At some point openconnect reports:
> 
> Got search domain 
> intra.xxxx.xxx;extra.xxxx.xxx;saclay.xxxx.xxx;partenaires.xxxx.xxx;xxxx.xxx
> 
> And after connecting, resolvectl reports:
> 
> $ resolvectl
> Global
>  ?????? Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
> resolv.conf mode: stub
> 
> Link 2 (enp0s31f6)
>  ??? Current Scopes: DNS
>  ???????? Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS 
> DNSSEC=no/unsupported
> Current DNS Server: 8.8.8.8
>  ?????? DNS Servers: 8.8.8.8 192.168.0.254
> 
> Link 3 (tun0)
>  ??? Current Scopes: DNS
>  ???????? Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS 
> DNSSEC=no/unsupported
> Current DNS Server: xxx.xxx.xxx.7
>  ?????? DNS Servers: xxx.xxx.xxx.7 xxx.xxx.xxx.6
>  ??????? DNS Domain: xxxx.xxx extra.xxxx.xxx intra.xxxx.xxx 
> partenaires.xxxx.xxx saclay.xxxx.xxx
> 
> 
> 
> We could work around this peculiar separator, but human imagination has 
> no limits, so where should we stop? More importantly, how do we know the 
> separator is "\059" and not "\"? I haven't read recent DNS RFCs, but I 
> suspect that "059ns2.redacted.com" is as legit as "ns2.redacted.com" 
> nowadays.
> 
> Let's try a different angle: Does FortiCLient handle this in a better way?
> 
> Dimitri
> 
> Le 22/06/2023 ? 05:02, Aaron Smith a ?crit?:
>> Running on Ubuntu 23.04 and connecting to a system Fortinet running 
>> version
>> 4.71.113.194.
>>
>> After successful connection, the VPN routes and DNS server settings 
>> are applied
>> to my system. The DNS server list is correct, but the servers are 
>> separate by
>> '059' instead of a space character, as displayed by 'resolvectl' below
>>
>> ~/ resolvectl status
>> Link 2 (enxe04f439490d4) Current Scopes: DNS Protocols: +DefaultRoute 
>> +LLMNR
>> -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 
>> 172.22.11.1 DNS
>> Servers: 172.22.11.1 DNS Domain: redacted.net
>>
>> Link 3 (wlp0s20f3) Current Scopes: none Protocols: -DefaultRoute 
>> +LLMNR -mDNS
>> -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 4 (vpn00449b7858) Current Scopes: none Protocols: -DefaultRoute 
>> +LLMNR
>> -mDNS -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 5 (vpn00fa8f88cb) Current Scopes: none Protocols: -DefaultRoute 
>> +LLMNR
>> -mDNS -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 6 (tun0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS
>> -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 22 (tun1) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS
>> -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.0.60.2 DNS 
>> Servers:
>> 10.0.60.2 10.0.60.3 DNS Domain: ns1.redacted.com\059ns2.redacted.com
>>
>> ~/ openconnect --version OpenConnect version v9.01-3 Using GnuTLS 3.7.8.
>> Features present: TPMv2, PKCS#11, RSA software token, HOTP software 
>> token, TOTP
>> software token, Yubikey OATH, System keys, DTLS, ESP Supported protocols:
>> anyconnect (default), nc, gp, pulse, f5, fortinet, array Default 
>> vpnc-script
>> (override with --script): /usr/share/vpnc-scripts/vpnc-script
>> Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported 
>> resolv.conf
>> mode: stub DNS Domain redacted.com private.net
>>
>> _______________________________________________
>> openconnect-devel mailing list
>> openconnect-devel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/openconnect-devel
> 

-- 
Dimitri Papadopoulos
Universit? Paris-Saclay, CEA, NeuroSpin
91191 Gif-sur-Yvette
France
+33 (0)1 69 08 79 12


From dimitri.papadopoulos at cea.fr  Fri Jun 23 05:14:12 2023
From: dimitri.papadopoulos at cea.fr (Dimitri Papadopoulos Orfanos)
Date: Fri, 23 Jun 2023 14:14:12 +0200
Subject: DNS server list has strange separator
In-Reply-To: <df721d8f-a229-6e79-4554-cb938937b9ec@cea.fr>
References: <e9c81bed-4562-ee99-39ea-86296c547bf6@geeksmith.net>
 <df721d8f-a229-6e79-4554-cb938937b9ec@cea.fr>
Message-ID: <0ab8b5ed-9bbe-971b-2e42-7c844ff898a9@cea.fr>

Hi Aaron,

My wrong, I have been mixing up two different things:

* search domains, which are typically found in the XML configuration 
sent by the Fortigate, inside a single XML element, with ';' or "," as 
the separator:
   <dns domain='sub1.redacted.com;sub2.redacted.com' />

* name servers, which are typically sent by IP address, *not* by DNS 
name, and found in distinct XML elements sent by the Fortigate:
   <dns ip='ns1.redacted.com' /><dns ip='ns2.redacted.com' />
while in your case the server appears to be sending something like this:
   <dns ip='ns1.redacted.com\059ns2.redacted.com' />

Two things are different from what we are used to:
1. the DNS servers are transmitted by DNS name rather than IP address,
2. the DNS servers appear to be defined in the same XML element.

I have opened an issue here:
https://gitlab.com/openconnect/openconnect/-/issues/634

Could you run "openfortivpn -v -v - --dump-http-traffic", extract from 
the output the XML configuration sent by the Fortigate, and post the 
(redacted) XML configuration?

The XML configuration sent by the Fortigate starts with something like this:

<?xml version='1.0' encoding='utf-8'?><sslvpn-tunnel

Dimitri

Le 22/06/2023 ? 16:21, Dimitri Papadopoulos a ?crit?:
> Hi,
> 
> Note that 59 is the decimal ASCII encoding for ";".
> 
> Also, 59 cannot is not an octal number, making the "\059" notation even 
> more awkward.
> 
> Therefore I suspect this is a problem with the Fortigate configuration. 
> Using my own corporate VPN, I do not see such a character:
> 
> At some point openconnect reports:
> 
> Got search domain 
> intra.xxxx.xxx;extra.xxxx.xxx;saclay.xxxx.xxx;partenaires.xxxx.xxx;xxxx.xxx
> 
> And after connecting, resolvectl reports:
> 
> $ resolvectl
> Global
>  ?????? Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
> resolv.conf mode: stub
> 
> Link 2 (enp0s31f6)
>  ??? Current Scopes: DNS
>  ???????? Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS 
> DNSSEC=no/unsupported
> Current DNS Server: 8.8.8.8
>  ?????? DNS Servers: 8.8.8.8 192.168.0.254
> 
> Link 3 (tun0)
>  ??? Current Scopes: DNS
>  ???????? Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS 
> DNSSEC=no/unsupported
> Current DNS Server: xxx.xxx.xxx.7
>  ?????? DNS Servers: xxx.xxx.xxx.7 xxx.xxx.xxx.6
>  ??????? DNS Domain: xxxx.xxx extra.xxxx.xxx intra.xxxx.xxx 
> partenaires.xxxx.xxx saclay.xxxx.xxx
> 
> 
> 
> We could work around this peculiar separator, but human imagination has 
> no limits, so where should we stop? More importantly, how do we know the 
> separator is "\059" and not "\"? I haven't read recent DNS RFCs, but I 
> suspect that "059ns2.redacted.com" is as legit as "ns2.redacted.com" 
> nowadays.
> 
> Let's try a different angle: Does FortiCLient handle this in a better way?
> 
> Dimitri
> 
> Le 22/06/2023 ? 05:02, Aaron Smith a ?crit?:
>> Running on Ubuntu 23.04 and connecting to a system Fortinet running 
>> version
>> 4.71.113.194.
>>
>> After successful connection, the VPN routes and DNS server settings 
>> are applied
>> to my system. The DNS server list is correct, but the servers are 
>> separate by
>> '059' instead of a space character, as displayed by 'resolvectl' below
>>
>> ~/ resolvectl status
>> Link 2 (enxe04f439490d4) Current Scopes: DNS Protocols: +DefaultRoute 
>> +LLMNR
>> -mDNS -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 
>> 172.22.11.1 DNS
>> Servers: 172.22.11.1 DNS Domain: redacted.net
>>
>> Link 3 (wlp0s20f3) Current Scopes: none Protocols: -DefaultRoute 
>> +LLMNR -mDNS
>> -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 4 (vpn00449b7858) Current Scopes: none Protocols: -DefaultRoute 
>> +LLMNR
>> -mDNS -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 5 (vpn00fa8f88cb) Current Scopes: none Protocols: -DefaultRoute 
>> +LLMNR
>> -mDNS -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 6 (tun0) Current Scopes: none Protocols: -DefaultRoute +LLMNR -mDNS
>> -DNSOverTLS DNSSEC=no/unsupported
>>
>> Link 22 (tun1) Current Scopes: DNS Protocols: +DefaultRoute +LLMNR -mDNS
>> -DNSOverTLS DNSSEC=no/unsupported Current DNS Server: 10.0.60.2 DNS 
>> Servers:
>> 10.0.60.2 10.0.60.3 DNS Domain: ns1.redacted.com\059ns2.redacted.com
>>
>> ~/ openconnect --version OpenConnect version v9.01-3 Using GnuTLS 3.7.8.
>> Features present: TPMv2, PKCS#11, RSA software token, HOTP software 
>> token, TOTP
>> software token, Yubikey OATH, System keys, DTLS, ESP Supported protocols:
>> anyconnect (default), nc, gp, pulse, f5, fortinet, array Default 
>> vpnc-script
>> (override with --script): /usr/share/vpnc-scripts/vpnc-script
>> Global Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported 
>> resolv.conf
>> mode: stub DNS Domain redacted.com private.net
>>
>> _______________________________________________
>> openconnect-devel mailing list
>> openconnect-devel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/openconnect-devel
> 

-- 
Dimitri Papadopoulos
Universit? Paris-Saclay, CEA, NeuroSpin
91191 Gif-sur-Yvette
France
+33 (0)1 69 08 79 12


From traxtopel at gmail.com  Mon Jun 26 04:55:54 2023
From: traxtopel at gmail.com (Grant Williamson)
Date: Mon, 26 Jun 2023 13:55:54 +0200
Subject: csd-post.sh "You are attempting to use a digital certificate not
 assigned to this device"
Message-ID: <CACNAWW9fpvJEK1m3khbxxt86BfXMxSWqSRyRGXWMwEOFH1cgAw@mail.gmail.com>

I'm encountering an issue with the csd-post.sh script. When attempting
to use it, I receive the error message: "You are attempting to use a
digital certificate not assigned to this device." I would appreciate
any insights on how to add support for when a server cross checks the
MAC address functionality in the script.


From traxtopel at gmail.com  Mon Jun 26 05:05:22 2023
From: traxtopel at gmail.com (Grant Williamson)
Date: Mon, 26 Jun 2023 14:05:22 +0200
Subject: csd-post.sh "You are attempting to use a digital certificate not
 assigned to this device"
In-Reply-To: <CACNAWW9fpvJEK1m3khbxxt86BfXMxSWqSRyRGXWMwEOFH1cgAw@mail.gmail.com>
References: <CACNAWW9fpvJEK1m3khbxxt86BfXMxSWqSRyRGXWMwEOFH1cgAw@mail.gmail.com>
Message-ID: <CACNAWW9_tArRjHJqx3t-HScfcfn7cuLsmhQ2Qy4pgRMmHe7HQw@mail.gmail.com>

Helps if I just try using what is there. Sorry.
endpoint.device.MAC["FFFF.FFFF.FFFF"]="true";

On Mon, Jun 26, 2023 at 1:55?PM Grant Williamson <traxtopel at gmail.com> wrote:
>
> I'm encountering an issue with the csd-post.sh script. When attempting
> to use it, I receive the error message: "You are attempting to use a
> digital certificate not assigned to this device." I would appreciate
> any insights on how to add support for when a server cross checks the
> MAC address functionality in the script.


From dlenski at gmail.com  Fri Jun 30 11:09:45 2023
From: dlenski at gmail.com (Daniel Lenski)
Date: Fri, 30 Jun 2023 11:09:45 -0700
Subject: csd-post.sh "You are attempting to use a digital certificate not
 assigned to this device"
In-Reply-To: <CACNAWW9fpvJEK1m3khbxxt86BfXMxSWqSRyRGXWMwEOFH1cgAw@mail.gmail.com>
References: <CACNAWW9fpvJEK1m3khbxxt86BfXMxSWqSRyRGXWMwEOFH1cgAw@mail.gmail.com>
Message-ID: <CAOw_LSE+8vN781F8jS8n43pexJRSMmy=FSwKqxqv4yXt+Ggxtw@mail.gmail.com>

On Mon, Jun 26, 2023 at 4:56?AM Grant Williamson <traxtopel at gmail.com> wrote:
> I'm encountering an issue with the csd-post.sh script. When attempting
> to use it, I receive the error message: "You are attempting to use a
> digital certificate not assigned to this device." I would appreciate
> any insights on how to add support for when a server cross checks the
> MAC address functionality in the script.

> Helps if I just try using what is there. Sorry.
> endpoint.device.MAC["FFFF.FFFF.FFFF"]="true";

Glad you figured out, but? wow.

"Digital certificate not assigned to this device" is a very
misleading/unclear/irrelevant error message for "you didn't tell us
your MAC address."

Unfortunately, OpenConnect has encountered many such similar cases
where VPN servers send vague/misleading error messages when they reach
an unexpected state
(https://gitlab.com/openconnect/openconnect/-/blob/master/gpst.c#L672-676).
It appears that their developers and administrators only test them
against their official clients, and don't consider what would happen
if a different client sent a different set of information.

(Needless to say, these kinds of flawed assumptions are also a rich
source of security vulnerabilities. ?)


From dlenski at gmail.com  Fri Jun 30 11:50:58 2023
From: dlenski at gmail.com (Daniel Lenski)
Date: Fri, 30 Jun 2023 11:50:58 -0700
Subject: DNS server list has strange separator
In-Reply-To: <0ab8b5ed-9bbe-971b-2e42-7c844ff898a9@cea.fr>
References: <e9c81bed-4562-ee99-39ea-86296c547bf6@geeksmith.net>
 <df721d8f-a229-6e79-4554-cb938937b9ec@cea.fr> <0ab8b5ed-9bbe-971b-2e42-7c844ff898a9@cea.fr>
Message-ID: <CAOw_LSFmPheaozxyj11jm79TFFtK15X4YfRuLbXmP8MZ7BfOFQ@mail.gmail.com>

On Fri, Jun 23, 2023 at 5:14?AM Dimitri Papadopoulos Orfanos
<dimitri.papadopoulos at cea.fr> wrote:
> I have opened an issue here:
> https://gitlab.com/openconnect/openconnect/-/issues/634

Aaron Smith, can you please test
https://gitlab.com/openconnect/openconnect/-/merge_requests/483 which
should fix this?

> * search domains, which are typically found in the XML configuration
> sent by the Fortigate, inside a single XML element, with ';' or "," as
> the separator:
>    <dns domain='sub1.redacted.com;sub2.redacted.com' />

It would be good to get more details from Aaron, but I believe that it
must indeed be the (`<dns domain="X">`) XML attribute which is
bizarrely delimited in this way, because:

(1) the numeric DNS IP addresses *are* being correctly received
(2) the split-DNS domains (`<split-dns domains="Y">`) are not actually
passed along to the vpnc-script in any way


From lixo at geeksmith.net  Fri Jun 30 17:07:39 2023
From: lixo at geeksmith.net (Aaron Smith)
Date: Fri, 30 Jun 2023 17:07:39 -0700
Subject: DNS server list has strange separator
In-Reply-To: <CAOw_LSFmPheaozxyj11jm79TFFtK15X4YfRuLbXmP8MZ7BfOFQ@mail.gmail.com>
References: <e9c81bed-4562-ee99-39ea-86296c547bf6@geeksmith.net>
 <df721d8f-a229-6e79-4554-cb938937b9ec@cea.fr>
 <0ab8b5ed-9bbe-971b-2e42-7c844ff898a9@cea.fr>
 <CAOw_LSFmPheaozxyj11jm79TFFtK15X4YfRuLbXmP8MZ7BfOFQ@mail.gmail.com>
Message-ID: <e38718ef-5b0e-f850-4b51-6dfffb20ee9d@geeksmith.net>

On 6/30/23 11:50, Daniel Lenski wrote:
> On Fri, Jun 23, 2023 at 5:14?AM Dimitri Papadopoulos Orfanos
> <dimitri.papadopoulos at cea.fr> wrote:
>> I have opened an issue here:
>> https://gitlab.com/openconnect/openconnect/-/issues/634
> Aaron Smith, can you please test
> https://gitlab.com/openconnect/openconnect/-/merge_requests/483 which
> should fix this?
Yes, I'll be able to test this next week.
>> * search domains, which are typically found in the XML configuration
>> sent by the Fortigate, inside a single XML element, with ';' or "," as
>> the separator:
>>     <dns domain='sub1.redacted.com;sub2.redacted.com' />
> It would be good to get more details from Aaron, but I believe that it
> must indeed be the (`<dns domain="X">`) XML attribute which is
> bizarrely delimited in this way, because:
>
> (1) the numeric DNS IP addresses *are* being correctly received
> (2) the split-DNS domains (`<split-dns domains="Y">`) are not actually
> passed along to the vpnc-script in any way


