Workaround for missed ESP key updates in Juniper/oNCP protocol
The Juniper/oNCP protocol informs the client of the ESP key lifetime (in
either seconds or bytes; we do not handle the latter case), but normally the
rekey is initiated by the server, which is supposed to send new keys to the
client with a KMP 302 packet on the oNCP/TLS channel.
However, when the ESP channel is used for data transport, the oNCP/TLS
channel is idle, and we don't know how to keep it alive or even to detect if
it is still alive. Therefore the server-initiated ESP key updates may not
be received, and the ESP channel will suddenly stop working; see https://gitlab.com/openconnect/openconnect/-/issues/627#note_1438325857 for
a probable case.
As a workaround, we can rekey by reconnecting the TLS channel and
re-fetching the config shortly before the ESP keys expire, if we haven't
already received new ESP keys from the server at this point.
Signed-off-by: Daniel Lenski <email address hidden>
d7a524a...
by
Dimitri Papadopoulos Orfanos <email address hidden>
Merge branch 'LOAD_LIBRARY_SEARCH_SYSTEM32' into 'master'
Search wintun.dll in the application directory only
See merge request openconnect/openconnect!541
5d228bb...
by
Dimitri Papadopoulos <email address hidden>
Search wintun.dll in the application directory only
Now that wintun.dll is installed in the application directory by
both openconnect and openconnect-gui packages, we can get rid of
LOAD_LIBRARY_SEARCH_SYSTEM32.
The rekey / trojan invocation is supposed to happen in the future.
Therefore subtract current time from expected time of rekey / invocation,
not the reverse.
These delays have been shown incorrectly ever since the SIGUSR1 handler was
added in b156b581e894b03e7169827b9e293ca2f13e1366.
