Open yjjl opened 6 months ago
Looks related to https://gitlab.com/openconnect/openconnect/-/issues/701
Can you try it with submitting HIP? sudo gpclient connect --hip <portal>
Tried, HIP error message goes away but connectivity problem persists.
For me today, with my organization's UK gateway, --disable-ipv6
seemed me to be the key, but currently that only seems to be supported with the version 1.x GlobalProtect-openconnect.
For me today, with my organization's UK gateway,
--disable-ipv6
seemed me to be the key, but currently that only seems to be supported with the version 1.x GlobalProtect-openconnect.
That's very helpful. I'm adding --disable-ipv6
option in 2.x
That addition, in today's https://github.com/yuezk/GlobalProtect-openconnect/releases/tag/v2.3.0, got me in for the first time with the 2.x code.
@martindorey so the --disable-ipv6
works for you?
@yjjl can you try 2.3.0 with the --disable-ipv6
option?
To the particular gateway I was using above, in somewhere between five and ten trials, I've got in with ssh every time with --disable-ipv6 --hip
and never with just --hip
, always falling foul of Dead Peer Detection. I might guess there are other causes for that problem, but I'm confident that you've solved mine - thanks!
Hi, Tried that with the 2.3.0 version but the error remains. There's no connectivity, DNS fails and the error message is the same:
2024-05-21T09:53:46Z INFO openconnect::ffi] Tunnel timeout (rekey interval) is 180 minutes. [2024-05-21T09:53:46Z INFO openconnect::ffi] Idle timeout is 180 minutes. [2024-05-21T09:53:46Z INFO openconnect::ffi] POST https://xxx.xx.uk/ssl-vpn/hipreportcheck.esp [2024-05-21T09:53:51Z WARN openconnect::ffi] Failed to connect ESP tunnel; using HTTPS instead. [2024-05-21T09:54:12Z WARN openconnect::ffi] GPST Dead Peer Detection detected dead peer! [2024-05-21T09:54:12Z INFO openconnect::ffi] POST https://xxx.xx.uk/ssl-vpn/getconfig.esp [2024-05-21T09:54:12Z INFO openconnect::ffi] SSL negotiation with xxx.xx.uk [2024-05-21T09:54:12Z INFO openconnect::ffi] Connected to HTTPS on xxx.xx.uk with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
tried both of
sudo gpclient --fix-openssl connect --disable-ipv6 --hip
Any ideas what could be the issue here?
I should add that error message reappears whenever I try to make a new connection (e.g. open a web page).
@yjjl can you try with the openconnect
command?
openconnect --protocol=gp --disable-ipv6 <portal>
openconnect --protocol=gp <portal>
Authentication doesn't work that way, get the following error message: POST https://xxx.xx.uk/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux Attempting to connect to server xxx:443 Connected to xxx:443 SSL negotiation with xxx.xxx.uk Connected to HTTPS on xxx.xxx.uk with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM) Got HTTP response: HTTP/1.1 200 OK Date: Wed, 22 May 2024 10:54:49 GMT Content-Type: application/xml; charset=UTF-8 Content-Length: 1560 Connection: keep-alive Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0 Set-Cookie: SESSID=ddd2b01c-3c47-40a4-9c68-e590dfaccffe; Path=/; SameSite=Lax; HttpOnly; Secure 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: (1560) SAML REDIRECT authentication is required via https://login.microsoftonline.com/XXXXXXX When SAML authentication is complete, specify destination form field by appending :field_name to login URL. Failed to parse server response Response was: <?xml version="1.0" encoding="UTF-8" ?>
Failed to complete authentication
I've tried to complete the SAML authentication by opening the link and then running openconnect but the same issue reappears.
Same issue here, we don't use any SSO so I can provide the requested logs (no difference with/without --disable-ipv6
though):
sudo openconnect --protocol=gp --csd-wrapper=/usr/libexec/openconnect/hipreport.sh --disable-ipv6 xxx.xx
POST https://xxx.xx/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to xxx:443
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Enter login credentials
Email address: xxx@xxx.xx
Password:
POST https://xxx.xx/global-protect/getconfig.esp
Portal reports GlobalProtect version 6.1.4-711; we will report the same client version.
Portal set HIP report interval to 60 minutes).
1 gateway servers available:
GW-EXTERNAL-ON-DEMAND (xxx.xx)
Please select GlobalProtect gateway.
GATEWAY: [GW-EXTERNAL-ON-DEMAND]:GW-EXTERNAL-ON-DEMAND
POST https://xxx.xx/ssl-vpn/login.esp
GlobalProtect login returned authentication-source=AUT-SEQ-GP
GlobalProtect login returned password-expiration-days=0
GlobalProtect login returned portal-userauthcookie=oJJl7db8EL/vfWlScCf5jPVOkM3qYcI5hR+xMlKQz9Qee9NJyiyOclkDwckaph/91Vkuu0M+8oJ0bfIb7qPTvyBpyen/P1Pm0as7MB570+VN3f0B6QWjDOB1Nvh4mqAZNHso3dH9B5StX1u4BemF0baj/G5zqe7gWDZ3MMIjHSPl5qQZ43ujyNrkBi2/lNARkVBEF5v0UWVWP/1KhlxxQVDqdI/0A0P1uAuLlHgm0pR3/KD0AbsSVmwHHf6fcDYX3E0ySpVW0g3EJD1lzsqmNNCxtvioKbG/1gm+3Pwmhct6mWzcADC10L9TE+jbYu9VbtnJzMMUrz+O4wX/9uiqTEoB4pKoMWININELioiJwJkV5CbjN5ZtEgCpGY/x/xi7SYGtHHH4vkYiCn0JwANyKF2kUP5UWTQ9CF/twtKO1AjofenQ69MetnNGHUT4rDY2iwqMdDVFpy2LRmIGCkqd2QlLRSUCOmDaWC/s5V3RZVsPEHWYuMG8ht71g+Bg65TyxU9t5XhA+83T/HkWINSW838oroMI54sVMkQdX6qyQ4XP1kcMTXE/s31qq0uZGP5N0J+juyEUsPiZRqRz81MT8JfzF0/wLnf3XvjS2m0+XJqp+YNkCEBAW/TTpUYtE5ZuO01rXWzWBVep3PMfI9wHX0IfgPDN/DSNP6QsPEhhJY8=
GlobalProtect login returned portal-prelogonuserauthcookie=empty
GlobalProtect login returned usually-equals-4=4
POST https://xxx.xx/ssl-vpn/getconfig.esp
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.
No MTU received. Calculated 1455 for SSL tunnel. No ESP keys received
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
Trying to run HIP Trojan script '/usr/libexec/openconnect/hipreport.sh'.
HIP script '/usr/libexec/openconnect/hipreport.sh' completed successfully (report is 2311 bytes).
POST https://xxx.xx/ssl-vpn/hipreport.esp
HIP report submitted successfully.
Set up UDP failed; using SSL instead
Configured as 10.193.24.182, with SSL connected and ESP disabled
Session authentication will expire at Thu May 23 17:29:38 2024
Using vhost-net for tun acceleration, ring size 32
GPST Dead Peer Detection detected dead peer!
POST https://xxx.xx/ssl-vpn/getconfig.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
GPST Dead Peer Detection detected dead peer!
POST https://xxx.xx/ssl-vpn/getconfig.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
GPST Dead Peer Detection detected dead peer!
POST https://xxx.xx/ssl-vpn/getconfig.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
GPST Dead Peer Detection detected dead peer!
POST https://xxx.xx/ssl-vpn/getconfig.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
^CPOST https://xxx.xx/ssl-vpn/logout.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Logout successful.
RTNETLINK answers: No such process
RTNETLINK answers: No such process
RTNETLINK answers: No such process
User cancelled (SIGINT/SIGTERM); exiting.
sudo openconnect --protocol=gp --csd-wrapper=/usr/libexec/openconnect/hipreport.sh xxx.xx
POST https://xxx.xx/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to xxx:443
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Enter login credentials
Email address: xxx@xxx.xx
Password:
POST https://xxx.xx/global-protect/getconfig.esp
Portal reports GlobalProtect version 6.1.4-711; we will report the same client version.
Portal set HIP report interval to 60 minutes).
1 gateway servers available:
GW-EXTERNAL-ON-DEMAND (xxx.xx)
Please select GlobalProtect gateway.
GATEWAY: [GW-EXTERNAL-ON-DEMAND]:GW-EXTERNAL-ON-DEMAND
POST https://xxx.xx/ssl-vpn/login.esp
GlobalProtect login returned authentication-source=AUT-SEQ-GP
GlobalProtect login returned password-expiration-days=0
GlobalProtect login returned portal-userauthcookie=mKNcuqseBlw6oUTus8XzPUVQbXwyis8NgbDmVy/yaIF/y9sRzM1+73LMOr8WDWZIa4scDteSpT6aibUy0ZFkwcMRTD+2yB1r/hd51LHfZsiRnqWPYLKvGslxIHx/IYAVPwCNKqqaEdfGzPNvVYs60Qai6fJzayRu58iOwZxwG8cus+fWOyqAU/PCaaJmh4Zx/WGOhKOxyjH4HlinovtFp2TJKtuYNW2iwabrk2njvQCqrfyT/UHcfMinjr5pnMb3dmGvaWOqBig732ok4tNzo0M3eLSX1W5fliEf2Fqt5jOUIXITVqOxZB3OLF1lQbWlsr6T/26uWAKiV8N+hlsjR88B58cKkVEuhjI13OoTNlw9xt9YAc+klVMiFsGjlB4VG3lVKevvZkuFpOo6xeEVWNAa01MM0hx4H94/a2OKqfDoqS27F9U57ftDqzwE4k1EtLZciOkT3tM583MVc8plUgveJaCauzjvtHIf9hzG+zA/So43FwJwE/fV0nPsm9G9Y6rCR9q/zcL56PnlBNsXJ8NwM9UwW0ZjfXzVuuHkxUGqpcMIqkLBNGI9CTuzgLLevy3Ae5nHAW65skxEPJhcjKOx4WQI6dTT7HKXsa9S7okmWc0ExF3J1kU8su9uAdQQlJ1I4zxlBtEQRjdEbL0Z7HA9FlFmpk25FRZXXL8EL/k=
GlobalProtect login returned portal-prelogonuserauthcookie=empty
GlobalProtect login returned usually-equals-4=4
POST https://xxx.xx/ssl-vpn/getconfig.esp
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.
No MTU received. Calculated 1455 for SSL tunnel. No ESP keys received
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
Trying to run HIP Trojan script '/usr/libexec/openconnect/hipreport.sh'.
HIP script '/usr/libexec/openconnect/hipreport.sh' completed successfully (report is 2311 bytes).
POST https://xxx.xx/ssl-vpn/hipreport.esp
HIP report submitted successfully.
Set up UDP failed; using SSL instead
Configured as 10.193.24.194, with SSL connected and ESP disabled
Session authentication will expire at Thu May 23 17:51:25 2024
Using vhost-net for tun acceleration, ring size 32
GPST Dead Peer Detection detected dead peer!
POST https://xxx.xx/ssl-vpn/getconfig.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
GPST Dead Peer Detection detected dead peer!
POST https://xxx.xx/ssl-vpn/getconfig.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
^CPOST https://xxx.xx/ssl-vpn/logout.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Logout successful.
RTNETLINK answers: No such process
RTNETLINK answers: No such process
RTNETLINK answers: No such process
User cancelled (SIGINT/SIGTERM); exiting.
For completeness sake, logs without --csd-wrapper
set:
sudo openconnect --protocol=gp xxx.xx
POST https://xxx.xx/global-protect/prelogin.esp?tmp=tmp&clientVer=4100&clientos=Linux
Connected to xxx:443
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Enter login credentials
Email address: xxx@xxx.xx
Password:
POST https://xxx.xx/global-protect/getconfig.esp
Portal reports GlobalProtect version 6.1.4-711; we will report the same client version.
Portal set HIP report interval to 60 minutes).
1 gateway servers available:
GW-EXTERNAL-ON-DEMAND (xxx.xx)
Please select GlobalProtect gateway.
GATEWAY: [GW-EXTERNAL-ON-DEMAND]:GW-EXTERNAL-ON-DEMAND
POST https://xxx.xx/ssl-vpn/login.esp
GlobalProtect login returned authentication-source=AUT-SEQ-GP
GlobalProtect login returned password-expiration-days=0
GlobalProtect login returned portal-userauthcookie=kd7c180bU5lTCBuIORTh2u64ArZvcMXKLrOFu41yhieMncxP6TjKZJqgu7+Uul1RWON3/kFeg2jW8QODu4wY6v451LKPxf/V+JjBz2hq+6p7xOPDQ6Y3RyClVuMuwlyp8FzyBy5q08YdPaCqSAdOI//qKv1eP1T22M3FyzrZ9AEB7IG/FlbKpF3yTsbGIcK3NuyWfjzN5WGd5xN7LfkCYVz/r+oMq4ofy+5Nv+Dhxnp1OK7lqaecZr4lXCoHau9pfRVs0QepopKQ3wsK2kTeJTZCxWeuSuh6ulJru+b2AeSfgu33+Vr6aecNQz+QkmHjqC/LGAyCLYMGP7aj6vF6LXGDSj6CImdJSLLWiOKd2VzGIIjBLC6zBeSOqbKJog77bXL18PoCn9hv6DKb1w5wuWBdVQM26LPplkz7FrvWO/D4EvDfpa0LE4ZLG8YKCnSgMqgwQye4vGlJz9YMBfmdekteKNmhkDg/QZJQvlCeTK/XqzL80PBw5t11ZcDSRIaIBiok3Wc1IKH0qD0E90PNRjSIAnd75YB3q5OBPhZebBoUBi3U031ofybTbUu67wsnRS297iTOVYd50XBYmNH79t+yO+8lHicYbrrzVIszeu0SBbmeJz7YV4t48GKcG86tkHRUcNYAeqh6DAaMXZRZIQv3HyOUjomBkDVQFmEznxk=
GlobalProtect login returned portal-prelogonuserauthcookie=empty
GlobalProtect login returned usually-equals-4=4
POST https://xxx.xx/ssl-vpn/getconfig.esp
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.
No MTU received. Calculated 1455 for SSL tunnel. No ESP keys received
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
WARNING: Server asked us to submit HIP report with md5sum 451e92e3c4065219a121a8c3a8224cfa.
VPN connectivity may be disabled or limited without HIP report submission.
You need to provide a --csd-wrapper argument with the HIP report submission script.
Set up UDP failed; using SSL instead
Configured as 10.193.24.195, with SSL connected and ESP disabled
Session authentication will expire at Thu May 23 17:55:42 2024
Using vhost-net for tun acceleration, ring size 32
Read error on SSL session: Erreur de la fonction « pull ».
Packet receive error: Opération non permise
POST https://xxx.xx/ssl-vpn/getconfig.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
GPST Dead Peer Detection detected dead peer!
POST https://xxx.xx/ssl-vpn/getconfig.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Tunnel timeout (rekey interval) is 180 minutes.
Idle timeout is 180 minutes.
POST https://xxx.xx/ssl-vpn/hipreportcheck.esp
^CPOST https://xxx.xx/ssl-vpn/logout.esp
Négociation SSL avec xxx.xx
Connected to HTTPS on xxx.xx with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
Logout successful.
RTNETLINK answers: No such process
RTNETLINK answers: No such process
RTNETLINK answers: No such process
User cancelled (SIGINT/SIGTERM); exiting.
Hi, I have the same problem as @yjjl I'm using SAML authentication via Okta. Tested the same things, same outcome.
In my case, once the connection has been made, there is almost no traffic, but somehow a few (very few) packets are able to reach the target and back (i.e., during a continuous ping). Tried to play with the MTU, no success.
Update - today I managed to get it to run without having made any changes (other than the --disable-ipv6 flag). The connection is extremely intermittent and frequently disconnects completely, but at least works some of the time unlike before although not reliably enough to be useable. I suspect there have been changes server-side but our central IT staff are not very transparent about any changes.
I commented on here the other day but looks like my comment was either deleted or didn't actually save.
I've actually hit this same problem on the 2.3.1 client.
I used
sudo gpclient connect {portal} --csd-wrapper /usr/libexec/openconnect/hipreport.sh --disable-ipv6 --os Linux --clean
to connect.
I get the same as reported above -- timeouts and repeated Dead Peer messages. This is the case on Linux Mint, Fedora and Manjaro.
Now our IT guys have an older version on a backup VPN connection endpoint, so I used the same thing but pointed to that. (10.x.x on the broken endpoint, 9.x.x on the backup one -- not sure if that's of any use, though as a response to @yjjl, maybe that's something similar to what happened in your case)
I was able to do some comparisons between a failed and working portal:
On the working portal, it has the following when it connects:
POST https://{portal}/ssl-vpn/logout.esp
SSL negotiation with {portal}
Connected to HTTPS on {portal} with ciphersuite (TLS1.2)-(RSA)-(AES-256-GCM)
On the broken one, it has the following when it connects:
POST https://{portal}/ssl-vpn/getconfig.esp
SSL negotiation with {portal}
Connected to HTTPS on {portal} with ciphersuite (TLS1.2)-(ECDHE-SECP256R1)-(RSA-SHA256)-(AES-256-GCM)
I noticed the difference in ciphersuite between the two -- could this be perhaps causing the problems? e.g. maybe openconnect or openssl can't handle the ECDHE-SECP256R1
and/or RSA-SHA256
?
Hi @huang-jy thanks for your investigation.
But I'm afraid the cipher suite might not be the root cause of this problem. Because the HTTPS error could occur if it doesn't support the cipher suite. I think we should dive into the logic of OpenConnect to understand when will it throw this error. Related in https://gitlab.com/openconnect/openconnect/-/issues/701
@yuezk thanks very much, I was already aware of that issue (indeed my research into this issue did send me there) -- I'm already keeping an eye on it.
FWIW, the GlobalProtect client suffers from the same issues and our IT staff seem unable to understand why. May be due to the version of Linux used? I'm on Ubuntu MATE 22.04 so nothing exotic.
Any updates on this? The behaviour has changed slightly - I now get intermittent connections which work as normal, but most of the time any connections fail (time out).
@yjjl there is no progress on our side. This might related to the server-side configuration or the VPN portal in your case.
I encountered the same issue. Below is my comment on https://gitlab.com/openconnect/openconnect/-/issues/701, which I have copied here for reference.
I encountered the same issue. After connecting to GlobalProtect VPN using openconnect, there is no network connection, and it keeps reconnecting with the error message:
GPST Dead Peer Detection detected dead peer
. Sometimes, after a few reconnections, a stable network can be established, but most of the time, there is no network. (During reconnection, there may be a few seconds of available network connection.)I tested two devices in the same network environment: one Linux (Fedora 41) and one MacBook Pro (macOS 14.7). Using the same openconnect (v9.12) command to connect to the same VPN portal, everything works fine on macOS, but on Linux, I encounter the issues described above. I also tested the official GlobalProtect client. On Linux, there is a similar problem: no network and constant reconnecting, with the log showing the error:
Too many outstanding keepalive and no response from GP gateway, disconnect tunnel
. However, the official client on macOS works perfectly.I tried the following on Linux: changing the MTU, enabling/disabling IPv6, submitting/not submitting hipreport, and modifying the --os option to impersonate macOS, but none of these had any effect. However, on macOS, everything seems to work fine regardless of the settings for the above parameters.
I suspect that the issue lies with the Linux system itself rather than the VPN server, especially since everything works fine on macOS. However, I don’t know where the problem might be, and sometimes a stable network connection can indeed be achieved on Linux (after several reconnections), which makes debugging very difficult.
Used to work until recently, no known changes server-side SAML authentication works, but no internet connectivity once connection has been made. Connection information returns Default route 0.0.0.0 for tun interface Output below
Command line output:
Logs GUI log: (same issues)
Environment:
ps aux | grep 'gnome-keyring\|kwalletd5' | grep -v grep
: [Required for secure store error] xx 1663 0.0 0.0 243840 7576 ? Sl 16:16 0:00 /usr/bin/gnome-keyring-daemon --daemonize --login xx 5423 0.0 0.0 243696 8960 ? Sl 16:23 0:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets