Project

General

Profile

Issue #2158

charon-nm triggers nm's vpn service initialization timeout

Added by Raphael Geissert about 4 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
networkmanager (charon-nm)
Affected version:
5.5.1
Resolution:
No feedback

Description

As originally reported via a Debian bug report (https://bugs.debian.org/719210), when using charon-nm with a smartcard it may trigger NetworkManager's vpn initialization timeout (of 5 seconds).
This appears to be due to the fact that charon enumerates the pkcs11 tokens before the DBUS interface is fully setup and the gmainloop run.

Seen since 4.5.2 but confirmed on newer versions.

History

#1 Updated by Tobias Brunner about 4 years ago

  • Category set to networkmanager (charon-nm)
  • Status changed from New to Feedback

The same thing can happen when starter controls charon (its timeout is 10 seconds, though). Loading the certificates could be avoided by disabling charon-nm.plugins.pkcs11.load_certs. You'd then have to load the certificate from a file, or explicitly from a token using the CKA_ID. But that won't work with charon-nm as it does not load any certificates from files when using authentication via PKCS#11 and configuring the CKA_ID is currently not supported either.

The most ideal fix would probably be to provide an interface for the user to select a specific certificate from a token (that could be a lot of work). An easier option would be a text field that takes the CKA_ID or a syntax like we use for leftcert that selects the certificate to use. Another option would be to allow the selection of a client certificate when using PKCS#11 authentication (probably the easiest to implement, but not ideal from a user perspective).

A potential workaround might be to disable charon-nm.plugins.pkcs11.load_certs but enable charon-nm.plugins.pkcs11.reload_certs. Then send a SIGHUP to charon-nm to load the certificates after it is started (but that has to be finished before the connection is initiated). You could try triggering sending that SIGHUP via charon-nm.start-scripts. That should not trigger the timeout by NM but loading the certificates might not be finished when the connection is initiated.

If the timeout used by NM can be increased somehow (easily) then I'd go with that.

#2 Updated by Raphael Geissert about 4 years ago

Tobias Brunner wrote:
[...]

A potential workaround might be to disable charon-nm.plugins.pkcs11.load_certs but enable charon-nm.plugins.pkcs11.reload_certs. Then send a SIGHUP to charon-nm to load the certificates after it is started (but that has to be finished before the connection is initiated). You could try triggering sending that SIGHUP via charon-nm.start-scripts. That should not trigger the timeout by NM but loading the certificates might not be finished when the connection is initiated.

As mentioned via IRC, doing this is not yet possible as there's no signal handler for SIGHUP in charon-nm.

After adding one, it seems there are other issues preventing it from working. I'm going to look into that and report back.

If the timeout used by NM can be increased somehow (easily) then I'd go with that.

The value being hard-coded, this isn't an option as of this time.

#3 Updated by Noel Kuntze over 3 years ago

  • Status changed from Feedback to Closed
  • Resolution set to No feedback

Also available in: Atom PDF