4

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:

#!/bin/sh
ipsec restart 
if (ipsec status | grep none);then
     ipsec up connection
fi

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'
Improve this question
1
  • Ubikey and IPsec, good idea. Commented Mar 17, 2018 at 18:57

2 Answers 2

Reset to default
1

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.

Improve this answer
1
  • 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. Commented Mar 19, 2018 at 16:44
0

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:

#!/bin/sh
service strongswan restart

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

Improve this answer
2
  • 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. Commented Mar 19, 2018 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. Commented Mar 19, 2018 at 17:56

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.