From list at datenwolf.net  Wed Jul  3 03:22:55 2024
From: list at datenwolf.net (Wolfgang 'datenwolf' Draxinger)
Date: Wed, 03 Jul 2024 12:22:55 +0200
Subject: OpenConnect v9.12-125-g0e357726: launch fails with "SSL connection
 failure: The encryption algorithm is not supported."
Message-ID: <3b3a0982e2dc90d050b52d129b63cba68bb91305.camel@datenwolf.net>


Hi,

the version installed on my system:

> #loki: ~root/ #> openconnect -V
OpenConnect version v9.12-125-g0e357726
Using GnuTLS 3.8.5. Features present: TPM, 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):
/etc/sv/openconnect/vpnc-script

I have a configuration that used to work just fine. However, it
seems that there was some update/change on the endpoint, which is
not yet supported by OpenConnect:

> #loki: /etc/sv/openconnect_UzL #> bat run
> ??????????????????????????????????????????????????????????????????
>        ? File: run
> ??????????????????????????????????????????????????????????????????
>    1   ? #!/bin/sh
>    2   ? [ -r conf ] && . ./conf
>    3   ? exec openconnect \
>    4   ?     --protocol=pulse -i tunUzL \
>    5   ?     -s /etc/sv/openconnect_UzL/script \
>    6   ?     -u $USER --passwd-on-stdin $SERVER \
>    7   ?     -v -v -v < pass 2>&1
> ??????????????????????????????????????????????????????????????????
> 
> #loki /etc/sv/openconnect_UzL #> bat conf
> ??????????????????????????????????????????????????????????????????
>        ? File: conf
> ??????????????????????????????????????????????????????????????????
>    1   ? SERVER=sslgate.uni-luebeck.de 
>    2   ? USER=...
> ??????????????????????????????????????????????????????????????????
> 
> # loki /etc/sv/openconnect_UzL #> ./run
> Attempting to connect to server 141.83.44.44:443
> Connected to 141.83.44.44:443
> SSL negotiation with sslgate.uni-luebeck.de
> SSL connection failure: The encryption algorithm is not supported.
> Failed to complete authentication

The failure happens before authentication is attempted, and can be
replicated with a bogus username just as well. I'm not suggesting to
"spam" the server I had configured for testing, but I guess whoever
who's looking into this could run a small number of tests against
it.

Opening a connection using openssl-s_client completes the TLS
negotiation:

> # loki ~dw/ %> openssl s_client sslgate.uni-luebeck.de:443
> Connecting to 141.83.44.44
> depth=2 C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST
> Network, CN=USERTrust RSA Certification Authority
> verify return:1
> depth=1 C=NL, O=GEANT Vereniging, CN=GEANT OV RSA CA 4
> verify return:1
> depth=0 C=DE, ST=Schleswig-Holstein, O=Universit?t zu L?beck,
> CN=sslgate.uni-luebeck.de
> verify return:1
> CONNECTED(00000003)
> ---
> Certificate chain
>  0 s:C=DE, ST=Schleswig-Holstein, O=Universit?t zu L?beck,
> CN=sslgate.uni-luebeck.de
>    i:C=NL, O=GEANT Vereniging, CN=GEANT OV RSA CA 4
>    a:PKEY: rsaEncryption, 3072 (bit); sigalg: RSA-SHA384
>    v:NotBefore: Oct  6 00:00:00 2023 GMT; NotAfter: Oct  5
> 23:59:59 2024 GMT
>  1 s:C=NL, O=GEANT Vereniging, CN=GEANT OV RSA CA 4
>    i:C=US, ST=New Jersey, L=Jersey City, O=The USERTRUST Network,
> CN=USERTrust RSA Certification Authority
>    a:PKEY: rsaEncryption, 4096 (bit); sigalg: RSA-SHA384
>    v:NotBefore: Feb 18 00:00:00 2020 GMT; NotAfter: May  1
> 23:59:59 2033 GMT
> ---
> Server certificate
> -----BEGIN CERTIFICATE-----
> ...
> -----END CERTIFICATE-----
> subject=C=DE, ST=Schleswig-Holstein, O=Universit?t zu L?beck,
> CN=sslgate.uni-luebeck.de
> issuer=C=NL, O=GEANT Vereniging, CN=GEANT OV RSA CA 4
> ---
> No client certificate CA names sent
> ---
> SSL handshake has read 3961 bytes and written 776 bytes
> Verification: OK
> ---
> New, TLSv1.2, Cipher is AES256-GCM-SHA384
> Server public key is 3072 bit
> Secure Renegotiation IS supported
> Compression: NONE
> Expansion: NONE
> No ALPN negotiated
> SSL-Session:
>     Protocol  : TLSv1.2
>     Cipher    : AES256-GCM-SHA384
>     Session-ID: ...
>     Session-ID-ctx: 
>     Master-Key: ...
>     PSK identity: None
>     PSK identity hint: None
>     SRP username: None
>     Start Time: 1720001913
>     Timeout   : 7200 (sec)
>     Verify return code: 0 (ok)
>     Extended master secret: no
> ---
> DONE


I hope that this has an easy fix.

Cheers,
Wolfgang

From kop at karlpinc.com  Wed Jul 24 12:35:45 2024
From: kop at karlpinc.com (Karl O. Pinc)
Date: Wed, 24 Jul 2024 14:35:45 -0500
Subject: Supporting Globalprotect when SAML auth is required at both portal
 and gateway
Message-ID: <20240724143545.7c2f3136@slate.karlpinc.com>

Hi,

I've submitted at PR at gitlab
https://gitlab.com/openconnect/openconnect/-/merge_requests/564
to add support for when SAML authentication must happen at both the
portal and the gateway, so SAML auth happens twice and produces
two different cookies.  The PR also adds to the Globalprotect
documentation on SAML authentication.

It's not clear how the development process goes, but I am somewhat
relying on this feature and don't want to maintain my own fork
forever.  So I'm writing to see if there's anything else I
need to do to facilitate progress.

I am also writing to let you, and the people associated with
gp-saml-gui, know that Globalprotect now has server configurations
which require this sort of authentication.  See, e.g.:

https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000ClQXCA0

Thanks for the help.

Regards,

Karl <kop at karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein


From kop at karlpinc.com  Wed Jul 24 15:03:08 2024
From: kop at karlpinc.com (Karl O. Pinc)
Date: Wed, 24 Jul 2024 17:03:08 -0500
Subject: Debugging UDP ESP failure
Message-ID: <20240724170308.31f58f3a@slate.karlpinc.com>

Hi,

FWIW, while working on authenticating to Globalprotect with
double-SAML authentication, I noticed that my connection
always fails to establish a UDP ESP tunnel.  No matter
the -vvv, I get no real information as to why.  

I see no UDP traffic passing through my firewall related
to the VPN.  Ever.  (Unless I made some sort of stupid mistake.)
Should I be looking for/passing through the firewall _actual_ ESP
traffic?

Although I did notice some ICMP IPv6 packets.  Which would have to
go through the VPN or else won't be passed by my firewall.
It's unclear if these have to do with ESP or not.  Further,
FYI, they seem to be sent even when using --disable-ipv6.

I can use the VPN without ESP, and maybe the issue is
server-side anyway, but I thought I'd ask to see if there
was anything easy to try.  If it's not easy I don't expect
I'll spend the time on it.  I'd rather spend time getting
the double-SAML patch approved.

Thanks for the help.

Regards,

Karl <kop at karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein


From dlenski at gmail.com  Wed Jul 24 16:19:38 2024
From: dlenski at gmail.com (Daniel Lenski)
Date: Wed, 24 Jul 2024 16:19:38 -0700
Subject: Debugging UDP ESP failure
In-Reply-To: <20240724170308.31f58f3a@slate.karlpinc.com>
References: <20240724170308.31f58f3a@slate.karlpinc.com>
Message-ID: <CAOw_LSF340FaygFSgzBbckahVipvzcZfvtbbA7oA4GusPeQn+A@mail.gmail.com>

On Wed, Jul 24, 2024 at 3:02?PM Karl O. Pinc <kop at karlpinc.com> wrote:
>
> No matter the -vvv, I get no real information as to why.

"No real information" is not actionable.

If you run a recent version of OpenConnect with `-vvv
--dump-http-traffic --protocol=gp`, you should ALWAYS get AT LEAST ONE
log line that specifically mentions ESP, even if it is to simply tell
you why OpenConnect thinks ESP is unavailable. (Like
https://gitlab.com/openconnect/openconnect/-/blob/64f0c03d660f1d17834f7ff7ce9d0151704bb32f/gpst.c#L621)

Please share those.

> Although I did notice some ICMP IPv6 packets.  Which would have to
> go through the VPN or else won't be passed by my firewall.
> It's unclear if these have to do with ESP or not.  Further,
> FYI, they seem to be sent even when using --disable-ipv6.

When OpenConnect sends ICMP packets to initiate/activate/enable the
GlobalProtect ESP tunnel, those packets are themselves encapsulated
via ESP and sent over the tunnel.
https://gitlab.com/openconnect/openconnect/-/blob/64f0c03d660f1d17834f7ff7ce9d0151704bb32f/gpst.c#L1565

So if you aren't capturing these ICMP IPv6 packets *on the tunnel
interface itself*, then they have nothing to do with
OpenConnect/GlobalProtect/ESP.

> I can use the VPN without ESP, and maybe the issue is
> server-side anyway, but I thought I'd ask to see if there
> was anything easy to try.

What I always recommend is that you test with a PAN GlobalProtect
proprietary client running on the same local network as OpenConnect.

- If the proprietary client can't establish an ESP tunnel, then it's
unsurprising if OpenConnect also can't establish an ESP tunnel. Quite
likely either something is broken in the VPN server's configuration,
or some middlebox isn't passing ESP-over-UDP traffic.
- If the proprietary client *can* establish an ESP tunnel, but
OpenConnect can't, then we certainly want to know more? but over the
past ~6 years we think we've eliminated almost all of those cases.
https://gitlab.com/openconnect/openconnect/-/commits/64f0c03d660f1d17834f7ff7ce9d0151704bb32f/gpst.c?search=ESP


From gafianodisantos at gmail.com  Thu Jul 25 08:48:51 2024
From: gafianodisantos at gmail.com (Gina Fogle)
Date: Thu, 25 Jul 2024 11:48:51 -0400
Subject: Grand Piano 07/25
Message-ID: <05d5a0d5ff69957def13f997f58a2fd372263521afadd4200a0d5cab2cbb3c92@mx.google.com>

Hello,

I'm offering my late husband's Yamaha Piano to any music enthusiast who may appreciate it. If you or someone you know might be interested in receiving this instrument for free, please feel free to reach out to me.

Warm regards,
Gina


From kop at karlpinc.com  Thu Jul 25 19:45:52 2024
From: kop at karlpinc.com (Karl O. Pinc)
Date: Thu, 25 Jul 2024 21:45:52 -0500
Subject: Debugging UDP ESP failure
In-Reply-To: <20240725190014.41c57568@slate.karlpinc.com>
References: <20240724170308.31f58f3a@slate.karlpinc.com>
	<CAOw_LSF340FaygFSgzBbckahVipvzcZfvtbbA7oA4GusPeQn+A@mail.gmail.com>
	<20240725190014.41c57568@slate.karlpinc.com>
Message-ID: <20240725214552.4e05313f@slate.karlpinc.com>

On Thu, 25 Jul 2024 19:00:14 -0500
"Karl O. Pinc" <kop at karlpinc.com> wrote:

> Thanks for the reply.  Here's the info you asked for.
> It looks like the proprietary client sets up a UDP VPN
> and openconnect does not.
> 
> That said, I'm using my patched version of openconnect.
> https://gitlab.com/openconnect/openconnect/-/merge_requests/564

Also:
Debian 12.6 (stable, bookworm)

For Globalprotect:
GlobalProtect_tar-6.1.2.0-82
And then after installing the above, install the
below:
GlobalProtect_UI_tar-6.1.2.0-82
(Then reboot, and re-install the UI, be a regular user, start
x-www-browser, and then execute: /opt/.../globalprotect launch-ui
)

Regards,

Karl <kop at karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein


From dlenski at gmail.com  Sat Jul 27 11:04:40 2024
From: dlenski at gmail.com (Daniel Lenski)
Date: Sat, 27 Jul 2024 11:04:40 -0700
Subject: Debugging UDP ESP failure
In-Reply-To: <20240725190014.41c57568@slate.karlpinc.com>
References: <20240724170308.31f58f3a@slate.karlpinc.com> <CAOw_LSF340FaygFSgzBbckahVipvzcZfvtbbA7oA4GusPeQn+A@mail.gmail.com>
 <20240725190014.41c57568@slate.karlpinc.com>
Message-ID: <CAOw_LSHHd9ABq7h5KfYY3HFNw4eOod_Y384Fa77rV6OnNKYEEQ@mail.gmail.com>

On Thu, Jul 25, 2024 at 4:59?PM Karl O. Pinc <kop at karlpinc.com> wrote:
> Thanks for the reply.  Here's the info you asked for.
> It looks like the proprietary client sets up a UDP VPN
> and openconnect does not.

Thanks. From your detailed log I have an idea of what's going on:

> POST https://vpnhost.example.com/ssl-vpn/getconfig.esp
> > POST /ssl-vpn/getconfig.esp HTTP/1.1
> > Host: vpnhost.example.com
> > User-Agent: PAN GlobalProtect
> > Cookie: PHPSESSID=0d908f7158db4981ddb0a77a0333afcb; CLIENTOS=V2luZG93cw%3D%3D
> > X-Pad: 000000000000000000000000000000000000000000000000000000000
> > Content-Type: application/x-www-form-urlencoded
> > Content-Length: 327
> >
> > client-type=1&protocol-version=p1&internal=no&app-version=5.2.13-48&ipv6-support=no&clientos=Windows&os-version=win&hmac-algo=sha1%2cmd5%2csha256&enc-algo=aes-128-cbc%2caes-256-cbc&authcookie=1ae1b6537c0b886eabff1091c6433944&portal=gp-staff-faculty-ext-getway-N&user=REDACTEDUSER%40example.com&domain=%28empty_domain%29&computer=slate
> Got HTTP response: HTTP/1.1 200 OK
> Date: Thu, 25 Jul 2024 21:47:42 GMT
> Content-Type: application/xml; charset=UTF-8
> Content-Length: 2352
> Connection: keep-alive
> Pragma: no-cache
> Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
> Expires: Thu, 19 Nov 1981 08:52:00 GMT
> X-FRAME-OPTIONS: DENY
> Strict-Transport-Security: max-age=31536000;
> X-XSS-Protection: 1; mode=block
> X-Content-Type-Options: nosniff
> Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; img-src * data:; style-src 'self' 'unsafe-inline';
> HTTP body length:  (2352)
> <
> <       <response status="success">
> <               <need-tunnel>yes</need-tunnel>
> <               <ssl-tunnel-url>/ssl-tunnel-connect.sslvpn</ssl-tunnel-url>
> <               <portal>gp-staff-faculty-ext-getway-N</portal>
> <               <user>REDACTEDUSER at example.com</user>
> <               <quarantine>no</quarantine>
> <               <lifetime>86400</lifetime>
> <               <timeout>10800</timeout>
> <               <disconnect-on-idle>10800</disconnect-on-idle>
> <               <bw-c2s>1000</bw-c2s>
> <               <bw-s2c>1000</bw-s2c>
> <               <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>
> <               <ip-address-preferred>yes</ip-address-preferred>
> <               <dns-v6>
> <                       <member>REDACTEDIPV4ADDRESS1</member>
> <                       <member>REDACTEDIPV4ADDRESS2</member>
> <                       <member>REDACTEDIPV4ADDRESS3</member>
> <                       <member>REDACTEDIPV4ADDRESS4</member>
> <                       <member>REDACTEDIPV6ADDRESS1</member>
> <                       <member>REDACTEDIPV6ADDRESS2</member>
> <               </dns-v6>
> <               <dns>
> <                       <member>REDACTEDIPV4ADDRESS1</member>
> <                       <member>REDACTEDIPV4ADDRESS2</member>
> <                       <member>REDACTEDIPV4ADDRESS3</member>
> <                       <member>REDACTEDIPV4ADDRESS4</member>
> <               </dns>
> <               <wins>
> <               </wins>
> <               <dns-suffix>
> <                       <member>example.com</member>
> <               </dns-suffix>
> <               <default-gateway>REDACTEDIPV4ADDRESS0</default-gateway>
> <               <mtu>0</mtu>
> <               <no-direct-access-to-local-network>no</no-direct-access-to-local-network>
> <               <access-routes>
> <                       <member>0.0.0.0/0</member>
> <                       <member>REDACTEDIPV4ADDRESS1/32</member>
> <                       <member>REDACTEDIPV4ADDRESS2/32</member>
> <                       <member>REDACTEDIPV4ADDRESS3/32</member>
> <                       <member>REDACTEDIPV4ADDRESS4/32</member>
> <               </access-routes>
> <               <access-routes-v6>
> <                       <member>::/0</member>
> <               </access-routes-v6>
> <               <exclude-access-routes>
> <               </exclude-access-routes>
> <               <exclude-access-routes-v6>
> <               </exclude-access-routes-v6>
> <               <ipsec>
> <                       <udp-port>4501</udp-port>
> <                       <ipsec-mode>esp-tunnel</ipsec-mode>
> <                       <enc-algo>aes-128-cbc</enc-algo>
> <                       <hmac-algo>sha1</hmac-algo>
> <                       <c2s-spi>0x5F672823</c2s-spi>
> <                       <s2c-spi>0x9FCCE331</s2c-spi>
> <                       <akey-s2c>
> <                               <bits>160</bits>
> <                               <val>4822b9bc1129308917434b8779fc1b5b2b93a491</val>
> <                       </akey-s2c>
> <                       <ekey-s2c>
> <                               <bits>128</bits>
> <                               <val>12e4597fc6b3a161e67be1cb27d80534</val>
> <                       </ekey-s2c>
> <                       <akey-c2s>
> <                               <bits>160</bits>
> <                               <val>fffcfca75dad43a42b56babb9c317ff1cb1020e9</val>
> <                       </akey-c2s>
> <                       <ekey-c2s>
> <                               <bits>128</bits>
> <                               <val>80fc6f79af6635c3253b1e5bbf48a068</val>
> <                       </ekey-c2s>
> <               </ipsec>
> <       </response>
> Tunnel timeout (rekey interval) is 180 minutes.
> Idle timeout is 180 minutes.
> Did not receive ESP keys and matching gateway in GlobalProtect config; tunnel will be TLS only.

OpenConnect is reporting "did not receive ESP keys and matching
gateway in GlobalProtect config". The "matching gateway" part is key.

Your VPN is indeed showing a previously unanticipated case, where the
VPN sends an IPv6 magic ping address
("<gw-address-v6>REDACTEDIPV6ADDRESS7</gw-address-v6>") but it
*doesn't* send an IPv6 client address (there is no "<ip-address-v6>").
In that case, we need to use the IPv4 magic ping address even though
we NORMALLY prefer the IPv6 magic ping address, because that one is
required if we want to be able to use both IPv6 and IPv4.

I put together a fix for this in
https://gitlab.com/openconnect/openconnect/-/commits/handle_GP_ESP_magic_address_corner_case

Can you please build and test that? I don't have a real GP VPN that I
can test it on anymore, unfortunately.


From kop at karlpinc.com  Sat Jul 27 14:04:26 2024
From: kop at karlpinc.com (Karl O. Pinc)
Date: Sat, 27 Jul 2024 16:04:26 -0500
Subject: Debugging UDP ESP failure
In-Reply-To: <CAOw_LSHHd9ABq7h5KfYY3HFNw4eOod_Y384Fa77rV6OnNKYEEQ@mail.gmail.com>
References: <20240724170308.31f58f3a@slate.karlpinc.com>
	<CAOw_LSF340FaygFSgzBbckahVipvzcZfvtbbA7oA4GusPeQn+A@mail.gmail.com>
	<20240725190014.41c57568@slate.karlpinc.com>
	<CAOw_LSHHd9ABq7h5KfYY3HFNw4eOod_Y384Fa77rV6OnNKYEEQ@mail.gmail.com>
Message-ID: <20240727160426.26fb8e97@slate.karlpinc.com>

Hi Daniel,

Good news.

On Sat, 27 Jul 2024 11:04:40 -0700
Daniel Lenski <dlenski at gmail.com> wrote:

> On Thu, Jul 25, 2024 at 4:59?PM Karl O. Pinc <kop at karlpinc.com> wrote:
> > Thanks for the reply.  Here's the info you asked for.
> > It looks like the proprietary client sets up a UDP VPN
> > and openconnect does not.  
> 
> Thanks. From your detailed log I have an idea of what's going on:

> OpenConnect is reporting "did not receive ESP keys and matching
> gateway in GlobalProtect config". The "matching gateway" part is key.
> 
> Your VPN is indeed showing a previously unanticipated case, where the
> VPN sends an IPv6 magic ping address
> ("<gw-address-v6>REDACTEDIPV6ADDRESS7</gw-address-v6>") but it
> *doesn't* send an IPv6 client address (there is no "<ip-address-v6>").
> In that case, we need to use the IPv4 magic ping address even though
> we NORMALLY prefer the IPv6 magic ping address, because that one is
> required if we want to be able to use both IPv6 and IPv4.
> 
> I put together a fix for this in
> https://gitlab.com/openconnect/openconnect/-/commits/handle_GP_ESP_magic_address_corner_case
> 
> Can you please build and test that? I don't have a real GP VPN that I
> can test it on anymore, unfortunately.

Works for me.  The output includes:

  ESP session established with server
  ESP tunnel connected; exiting HTTPS mainloop.
  Configured as READACTEDIPV4NUMBER, with SSL disconnected and ESP established

And I see the expected UDP traffic go through the firewall. Thanks!

Let me know if you need anything else.

---

Various notes for your records follow, just in case anything matters:

---

I had to apply my patches on top of yours:
https://gitlab.com/openconnect/openconnect/-/merge_requests/564

---

For whatever reason, probably because of some failure during a
previous test, there were "extra" net interfaces in existence
after the first time I tried to setup the VPN.  "ip link" output
included:

8: tun0-vpnssh0 at if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether ee:96:fd:5d:2e:8e brd ff:ff:ff:ff:ff:ff link-netnsid 0
10: veth0 at if11: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 82:84:36:33:5c:c3 brd ff:ff:ff:ff:ff:ff link-netns vpnc-script-sshd

and part of the openconnect output included:

  Session authentication will expire at Sun, 28 Jul 2024 15:24:56 CDT
  RTNETLINK answers: File exists
  RTNETLINK answers: File exists
  VPN now accessible through 'ssh fec0::1'

The result of this seemed to be a ESP VPN session, but one
that didn't forward any packets after `ssh fec0::1`.  Everything
that happened in the network namespace just stayed there without
touching the VPN.

This sort of thing has to do with some failure mode of vpnc-script-sshd,
in my experience.

After deleting the interfaces tun0-vpnssh0 and veth0 everything worked
as expected.  I tried twice.  Each time worked, and afterwards there
were no "extra" interfaces left lying about.  So, all good.

---

FYI, I couldn't find a "clean*" target that did not leave files
for git to add.  The best I could do was `make maintainer-clean`,
which left me with:

$ git status
On branch gp_double_SAML_udp
Untracked files:
  (use "git add <file>..." to include in what will be committed)
	compile
	config.h.in
	m4/libtool.m4
	m4/ltoptions.m4
	m4/ltsugar.m4
	m4/ltversion.m4
	m4/lt~obsolete.m4
	tests/test-obsolete-server-crypto.config.27841.tmp
	tests/test-obsolete-server-crypto.config.27906.tmp

So I started with `./autogen.sh` and when on to run ./configure
from there.  Everything built, `make check` passed, and the result
has worked.  So, no worries. (To be more precise, all the checks
passed but "FAIL: auth-certificate", because I don't have the
necessary libraries/packages installed to build that feature.)

Regards,

Karl <kop at karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

P.S.  So nice to be able to test without fighting with the proprietary
client.  :-)


From dlenski at gmail.com  Sat Jul 27 17:40:09 2024
From: dlenski at gmail.com (Daniel Lenski)
Date: Sat, 27 Jul 2024 17:40:09 -0700
Subject: Debugging UDP ESP failure
In-Reply-To: <20240727160426.26fb8e97@slate.karlpinc.com>
References: <20240724170308.31f58f3a@slate.karlpinc.com> <CAOw_LSF340FaygFSgzBbckahVipvzcZfvtbbA7oA4GusPeQn+A@mail.gmail.com>
 <20240725190014.41c57568@slate.karlpinc.com> <CAOw_LSHHd9ABq7h5KfYY3HFNw4eOod_Y384Fa77rV6OnNKYEEQ@mail.gmail.com>
 <20240727160426.26fb8e97@slate.karlpinc.com>
Message-ID: <CAOw_LSH9NH=WV0bzdXbqGs3Cz6WHMOxnr1Z_qJoRKPzCLnJw2w@mail.gmail.com>

On Sat, Jul 27, 2024 at 2:03?PM Karl O. Pinc <kop at karlpinc.com> wrote:
>
> > I put together a fix for this in
> > https://gitlab.com/openconnect/openconnect/-/commits/handle_GP_ESP_magic_address_corner_case
> >
> > Can you please build and test that? I don't have a real GP VPN that I
> > can test it on anymore, unfortunately.
>
> Works for me.  The output includes:
>
>   ESP session established with server
>   ESP tunnel connected; exiting HTTPS mainloop.
>   Configured as READACTEDIPV4NUMBER, with SSL disconnected and ESP established
>
> And I see the expected UDP traffic go through the firewall. Thanks!

Excellent, thanks. I was able to add some semi-automated tests thanks
to your detailed report here, and I've created an MR to fix it in the
next release at
https://gitlab.com/openconnect/openconnect/-/merge_requests/565


From benjamin.redelings at gmail.com  Mon Jul 29 10:35:37 2024
From: benjamin.redelings at gmail.com (Benjamin Redelings)
Date: Mon, 29 Jul 2024 13:35:37 -0400
Subject: Update docs for "pulse secure"?
Message-ID: <f1efd6b6-d1b8-44fa-89cf-3bf56ee762d0@gmail.com>

Hi,

The web page here gives some information about using openconnect on 
"pulse secure" VPNs.

 ??? https://www.infradead.org/openconnect/pulse.html

There is a new python script that allows logging in with WebKit2 and 
extracting the authentication cookie for use with openconnect:

 ??? https://github.com/utknoxville/openconnect-pulse-gui/issues

IMHO it is still beta quality, but is the first tool I've seen that 
allows me to use openconnect instead of the pulseSecure client.? (Which 
is important because the pulseSecure client inexplicably stopped working 
recently, giving an error message about inability to create a virtual 
interface after authentication completes.)

Thanks!

-BenRI



From bj.cardon at gmail.com  Tue Jul 30 11:46:49 2024
From: bj.cardon at gmail.com (Benjamin Cardon)
Date: Tue, 30 Jul 2024 12:46:49 -0600
Subject: ESP Connection Refused Question
Message-ID: <CAEjMM-EyKgcH5xqew6Y6Qq43amxkNbU2FqoH8zmVxw66XCqoqg@mail.gmail.com>

Hi, my company has a GlobalProtect VPN and I've been successfully
using it using GPopen and openconnect for years. A few months ago,
they changed something in our network or VPN that is causing the VPN
to fail to connect via ESP when I'm in our office, though it works
perfectly fine outside the office network. I have tried to figure out
what exactly is preventing ESP from starting up and the only thing I
can really see in the logs that is different between in the office
versus out of the office is this log

Jul 30 11:06:33 xps15 plasmashell[3116179]: 2024-07-30 11:06:33.467
INFO  [3116179] [GPClient::onVPNLogAvailable at 518] ESP receive error:
Connection refused

My question is, what does this log line imply and where is the
connection being refused from? Is it just UDP packets to the gateway
address? Prior to this, it does do a handshake using Okta to sign in
which works just fine so it's transferring the ESP packets explicitly
that seems to be the problem. To me, this suggests a network
configuration/firewall issue but I need more info to tell our
networking team what to investigate.

Any help would be appreciated.

Thanks!
Ben


From kop at karlpinc.com  Tue Jul 30 13:01:04 2024
From: kop at karlpinc.com (Karl O. Pinc)
Date: Tue, 30 Jul 2024 15:01:04 -0500
Subject: ESP Connection Refused Question
In-Reply-To: <CAEjMM-EyKgcH5xqew6Y6Qq43amxkNbU2FqoH8zmVxw66XCqoqg@mail.gmail.com>
References: <CAEjMM-EyKgcH5xqew6Y6Qq43amxkNbU2FqoH8zmVxw66XCqoqg@mail.gmail.com>
Message-ID: <20240730150104.6674dd18@slate.karlpinc.com>

On Tue, 30 Jul 2024 12:46:49 -0600
Benjamin Cardon <bj.cardon at gmail.com> wrote:

> Hi, my company has a GlobalProtect VPN and I've been successfully
> using it using GPopen and openconnect for years. A few months ago,
> they changed something in our network or VPN that is causing the VPN
> to fail to connect via ESP when I'm in our office, though it works
> perfectly fine outside the office network.

I am just guessing that the following reference to a patch won't
help, but it wouldn't hurt to try with "the latest code".

https://lists.infradead.org/pipermail/openconnect-devel/2024-July/005448.html

Otherwise, my limited experience says to use -vvv --dump-http-traffic
and send the output to the list to get help.  Don't forget
to redact SAML or other cookies used for authorization (!), and
anything else that might be private.

Karl <kop at karlpinc.com>
Free Software:  "You don't pay back, you pay forward."
                 -- Robert A. Heinlein

P.S.  What would be cool would be to have a
--dump-http-traffic=anonyonimized option,
that redacts everything "sensitive".  This would
make bug reporting much easier, although people
might still send cookies because they can be
cut-and-pasted as part of human interaction.



From dlenski at gmail.com  Tue Jul 30 15:34:31 2024
From: dlenski at gmail.com (Daniel Lenski)
Date: Tue, 30 Jul 2024 15:34:31 -0700
Subject: ESP Connection Refused Question
In-Reply-To: <CAEjMM-EyKgcH5xqew6Y6Qq43amxkNbU2FqoH8zmVxw66XCqoqg@mail.gmail.com>
References: <CAEjMM-EyKgcH5xqew6Y6Qq43amxkNbU2FqoH8zmVxw66XCqoqg@mail.gmail.com>
Message-ID: <CAOw_LSG85DaDVfCPXUF94nyjyVQBjOWqpHdtjvymETcnLqv+RA@mail.gmail.com>

On Tue, Jul 30, 2024 at 11:47?AM Benjamin Cardon <bj.cardon at gmail.com> wrote:
>
> Hi, my company has a GlobalProtect VPN and I've been successfully
> using it using GPopen and openconnect for years.


What is GPopen?

> A few months ago, they changed something in our network or VPN that is causing the VPN to fail to connect via ESP when I'm in our office, though it works perfectly fine outside the office network. I have tried to figure out what exactly is preventing ESP from starting up and the only thing I can really see in the logs that is different between in the office versus out of the office is this log
>
> Jul 30 11:06:33 xps15 plasmashell[3116179]: 2024-07-30 11:06:33.467
> INFO  [3116179] [GPClient::onVPNLogAvailable at 518] ESP receive error:
> Connection refused
>
>  My question is, what does this log line imply and where is the connection being refused from?

Find and provide additional context, and then we'll both have a better
idea of what's going on.

As Karl Pinc wrote, run the OpenConnect command-line client with `-vvv
--dump-http-traffic` and share the logs from that, particularly log
messages about ESP configuration.

> Is it just UDP packets to the gateway address? Prior to this, it does do a handshake using Okta to sign in which works just fine so it's transferring the ESP packets explicitly that seems to be the problem. To me, this suggests a network configuration/firewall issue but I need more info to tell our networking team what to investigate.

It is *likely* that some kind of middlebox is preventing UDP packets
from getting through in the non-working network environment, but there
are other possibilities as well.


From bj.cardon at gmail.com  Tue Jul 30 16:04:14 2024
From: bj.cardon at gmail.com (Benjamin Cardon)
Date: Tue, 30 Jul 2024 17:04:14 -0600
Subject: ESP Connection Refused Question
In-Reply-To: <CAOw_LSG85DaDVfCPXUF94nyjyVQBjOWqpHdtjvymETcnLqv+RA@mail.gmail.com>
References: <CAEjMM-EyKgcH5xqew6Y6Qq43amxkNbU2FqoH8zmVxw66XCqoqg@mail.gmail.com>
 <CAOw_LSG85DaDVfCPXUF94nyjyVQBjOWqpHdtjvymETcnLqv+RA@mail.gmail.com>
Message-ID: <CAEjMM-Fv59JQ4oJpLC2THGSEWGvVNtim3xcgdzm+LFkm4055Cg@mail.gmail.com>

Sorry Daniel for the lack of info. GPopen is just my fork of an old
version of GlobalProtect-openconnect before it became payware.

When I'm in the office again tomorrow I'll collect more info and scrub
it to share here.

Thanks!
Ben

On Tue, Jul 30, 2024 at 4:35?PM Daniel Lenski <dlenski at gmail.com> wrote:
>
> On Tue, Jul 30, 2024 at 11:47?AM Benjamin Cardon <bj.cardon at gmail.com> wrote:
> >
> > Hi, my company has a GlobalProtect VPN and I've been successfully
> > using it using GPopen and openconnect for years.
>
>
> What is GPopen?
>
> > A few months ago, they changed something in our network or VPN that is causing the VPN to fail to connect via ESP when I'm in our office, though it works perfectly fine outside the office network. I have tried to figure out what exactly is preventing ESP from starting up and the only thing I can really see in the logs that is different between in the office versus out of the office is this log
> >
> > Jul 30 11:06:33 xps15 plasmashell[3116179]: 2024-07-30 11:06:33.467
> > INFO  [3116179] [GPClient::onVPNLogAvailable at 518] ESP receive error:
> > Connection refused
> >
> >  My question is, what does this log line imply and where is the connection being refused from?
>
> Find and provide additional context, and then we'll both have a better
> idea of what's going on.
>
> As Karl Pinc wrote, run the OpenConnect command-line client with `-vvv
> --dump-http-traffic` and share the logs from that, particularly log
> messages about ESP configuration.
>
> > Is it just UDP packets to the gateway address? Prior to this, it does do a handshake using Okta to sign in which works just fine so it's transferring the ESP packets explicitly that seems to be the problem. To me, this suggests a network configuration/firewall issue but I need more info to tell our networking team what to investigate.
>
> It is *likely* that some kind of middlebox is preventing UDP packets
> from getting through in the non-working network environment, but there
> are other possibilities as well.


From dlenski at gmail.com  Wed Jul 31 17:11:00 2024
From: dlenski at gmail.com (Daniel Lenski)
Date: Wed, 31 Jul 2024 17:11:00 -0700
Subject: ESP Connection Refused Question
In-Reply-To: <CAEjMM-GoJLBWawXWehwiyLjRDu947875wP9kso5_o0QUeS5XoA@mail.gmail.com>
References: <CAEjMM-EyKgcH5xqew6Y6Qq43amxkNbU2FqoH8zmVxw66XCqoqg@mail.gmail.com>
 <CAOw_LSG85DaDVfCPXUF94nyjyVQBjOWqpHdtjvymETcnLqv+RA@mail.gmail.com>
 <CAEjMM-Fv59JQ4oJpLC2THGSEWGvVNtim3xcgdzm+LFkm4055Cg@mail.gmail.com> <CAEjMM-GoJLBWawXWehwiyLjRDu947875wP9kso5_o0QUeS5XoA@mail.gmail.com>
Message-ID: <CAOw_LSGPSk62fTqKzsJ1edS=P9z4ZiMMVn-bX6-gqQGSSKRw=w@mail.gmail.com>

On Wed, Jul 31, 2024 at 8:58?AM Benjamin Cardon <bj.cardon at gmail.com> wrote:
> Attached is the handshake. Everything up to line 72 is collecting the
> auth cookie from Okta.

Yes, it appears from this log that there's simply no UDP connectivity
between the client and the server. The ESP-over-UDP tunnel can't be
connected, and so OpenConnect gives up and uses the TLS tunnel
instead.

Jul 31 09:24:00 xps15 plasmashell[3351696]: 2024-07-31 09:24:00.977
INFO  [3351696] [GPClient::onVPNLogAvailable at 518] Failed to connect
ESP tunnel; using HTTPS instead.

UDP connectivity can be broken in all kinds of idiosyncratic ways that
are often specific to your network environment.

The most important thing to try, in terms of NARROWING DOWN the
possible breakages, would be to rerun this from the network
environment *where ESP does work* and *compare the logs*. In
particular, does anything change in the /ssl-vpn/getconfig.esp
response, besides the randomized IPSEC security parameters and perhaps
the IP address assigned to the client?

And to make debugging easier, use
https://github.com/dlenski/gp-saml-gui + the OpenConnect command-line
interface (instead of the GUI-fied wrapper of
https://github.com/yuezk/GlobalProtect-openconnect).


