Connection keeps resetting, error message GPST Dead Peer Detection detected dead peer! #364
Comments
|
Looks related to https://gitlab.com/openconnect/openconnect/-/issues/701 Can you try it with submitting HIP? |
|
Tried, HIP error message goes away but connectivity problem persists. |
|
For me today, with my organization's UK gateway, |
That's very helpful. I'm adding |
|
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 @yjjl can you try 2.3.0 with the |
|
To the particular gateway I was using above, in somewhere between five and ten trials, I've got in with ssh every time with |
|
Hi, 2024-05-21T09:53:46Z INFO openconnect::ffi] Tunnel timeout (rekey interval) is 180 minutes. tried both of 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
|
|
Authentication doesn't work that way, get the following error message: xxx.xx 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 For completeness sake, logs without |
|
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
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: On the broken one, it has the following when it connects: 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 |
|
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.
|
|
same issue for me on Ubuntu 24.04 and SAML login with Microsoft. Interestingly, also the official Linux GlobalProtect client stopped working on my system. |
|
It is likely a server-side bug. This discussion might be relevant: https://live.paloaltonetworks.com/t5/globalprotect-discussions/globalprotect-connection-issues-in-pan-os-10-2-7-h3/td-p/571507 I reached out to my organization's Tech Support, and they acknowledged the existence of this bug. However, they declined to upgrade the server-side software, as most users do not use Linux... |
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
The text was updated successfully, but these errors were encountered: