Hi Daniel,
thanks a lot for your fast reply!
On 8/10/22 20:36, Daniel Lenski wrote:
On Wed, Aug 10, 2022 at 1:21 AM Bernd Schubert
<bernd.schub...@fastmail.fm> wrote:
I had found this thread
https://askubuntu.com/questions/1273285/vpn-openconnect-pulse-disconnects-itself-in-ubuntu-20
and according to the discussion the issue is supposed to be resolved
with 8.20.
No.
I think you are referring to my comment
(https://askubuntu.com/a/1368954) on that discussion. As my comment
indicates, the issue that was fixed in v8.20 is…
(a) Only applicable to connecting with --protocol=nc, NOT RELEVANT to
connecting with --protocol=pulse. Pulse servers typically support both
protocols.
Ah ok, I actually already tried --protocol=nc - same issue.
(b) A different kind of error. The error YOU are encountering is an
error in the SSL/TLS channel of the VPN; the error described in that
discussion is an error in the ESP channel.
Ah, I didn't see/understand these differences.
Any idea what is going on
My theory is that, because we have no known keepalive mechanism for
the Pulse TLS channel, it eventually gets disconnected due to some
TCP/TLS socket timeout.
… or how to debug it?
(1) Add --timestamp so that you can see if there's a reproducible
timing of the problem. For example, does it always occur exactly 10
minutes after you initially connect?
(2) You describe this problem as a "dead connection", but it appears
from your log that OpenConnect is successfully detecting the loss of
connectivity on the SSL channel and reconnecting. Does the VPN
continue working after reconnecting?
No, the connection does not work anymore when that happens. I have to
restart openconnect to be able to continue to work (I'm glad that
screen/tmux/x2go exist...).
```
Send ESP probes for DPD
Send ESP probes for DPD
Send ESP probes for DPD
Read error on SSL session: Error in the pull function. <-- error here
SSL negotiation with <server>
Connected to HTTPS on <server> with ciphersuite
(TLS1.2)-(RSA)-(AES-128-CBC)-(SHA256)
Got HTTP response: HTTP/1.1 101 Switching Protocols
…
<continues to reconnect and refetch the configuration>
```
At least for me the interesting part is that openconnect is not sending
these ESP probes anymore then - I wonder if it is hanging. Going to get
pstack output tomorrow.
So I enabled time stamps now (thanks for the parameter)
1)
...
[2022-08-10 21:22:11] ESP session established with server
[2022-08-10 21:22:33] Send ESP probes for DPD
[2022-08-10 21:23:03] Send ESP probes for DPD
....
[2022-08-10 21:42:35] Send ESP probes for DPD
[2022-08-10 21:42:42] ESP detected dead peer <-------- Hmmm
[2022-08-10 21:42:42] UDP SO_SNDBUF: 28000
[2022-08-10 21:43:42] Send ESP probes
[2022-08-10 21:44:42] Send ESP probes
...
[2022-08-10 21:53:13] Send ESP probes
[2022-08-10 21:53:53] Read error on SSL session: Error in the pull function.
...
===> >30 min
2)
....
[2022-08-10 21:57:46] ESP session established with server
[2022-08-10 21:58:01] Send ESP probes for DPD
[2022-08-10 21:58:16] Send ESP probes for DPD
...
[2022-08-10 22:02:32] Send ESP probes for DPD
[2022-08-10 22:02:35] Read error on SSL session: Error in the pull function.
===> <5min
With 2 runs (it gets late here) once around 30 min and another time
around 5 minutes.
Thanks,
Bernd
_______________________________________________
openconnect-devel mailing list
openconnect-devel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/openconnect-devel
