I have tried to find some answers on this and other sites trying to find out the problem, but my attempts failed. The rule is very simple: I want to establish my Ipsec tunnel when my Yubikey is plugged.

  • My rule is in the file /etc/udev/rules.d/local.rules

In which the script goes as:

SUBSYSTEM=="input", ACTION=="add", ENV{ID_MODEL}=="Yubikey_4_OTP+U2F+CCID" , RUN+="/usr/local/bin/Yubikey.sh"

Then the script /usr/local/bin/Yubikey.sh contains:

ipsec restart 
if (ipsec status | grep none);then
     ipsec up connection

This invokes the script when any input device is plugged, and then the script should restart ipsec and initiate the tunnel if there was not a tunnel initiated before. However, the tunnel doesn't initiate as I get the following error when I run ipsec status command:

connecting to 'unix:///var/run/charon.ctl' failed: Connection refused
failed to connect to stroke socket 'unix"//var/run/charon.ctl'
  • Ubikey and IPsec, good idea. – Rui F Ribeiro Mar 17 '18 at 18:57

By default only root is allowed to access that socket (and others created by strongSwan). There are options to change that. For instance, with charon.group in strongswan.conf users that are members of the configured group are also allowed to access the socket. There might also be some kernel level security module (e.g. AppArmor) on your system that could prevent access to the socket (check the system log for entries and maybe adapt the policies accordingly).

Instead of using the deprecated ipsec/starter/stroke you might want to consider switching to VICI/swanctl.

  • thanks for your answer. I just the question and I found out charon.ctl accepts only service strongswan restart instead of ipsec restart command. And yes, as you mentioned, ipsec/starter/stroke is deprecated, that is why I thought I could service strongswan instead. – debugging XD Mar 19 '18 at 16:44

So, after researching more, I found out that the problem in /usr/local/bin/Yubikey.sh script which calls ipsec as a service which caused the stroke socket charon.ctl to fail. Instead, I had to change it to:

service strongswan restart

So, I had to use strongswan instead of ipsec as in the recent distributions , ipsec command has been renamed to strongswan.

  • While some distributions (e.g. CentOS/Fedora) rename the ipsec script to strongswan that is not related to the service utility and the services it can control (usually System V init scripts, but depends on the system). The latter may be called strongswan while the script is still named ipsec and vice-versa. And the script's or service's name has nothing to do with the reason you are not able to access the socket. – ecdsa Mar 19 '18 at 17:21
  • ok, thanks for the clarification. Could you add your edit to this answer then? Because this answer works for me so far and I have no further explanation to what is happening exactly. – debugging XD Mar 19 '18 at 17:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.