On Wed, Jul 31, 2024 at 8:58 AM Benjamin Cardon <bj.car...@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@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). _______________________________________________ openconnect-devel mailing list openconnect-devel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/openconnect-devel
