Project

General

Profile

Actions

Bug #5319

closed

Error message "No config named" in charon daemon

Added by Frédéric Pougnault almost 9 years ago. Updated almost 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
IPsec
Target version:
-
Start date:
10/19/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.x
Affected Architecture:

Description

Hello,

I migrated my pfsense last week from 2.1.5 to 2.2.4.
After the migtration all tunnels was up.
But after few days some tunnels was down and doesn't up automatically.
When I tried to force the connection charon printed the error message "No config named con18000".

To renew the tunnel I was to "kill -9" the charon daemon and start it again with the command "ipsec start"

Actions #1

Updated by Chris Buechler over 8 years ago

  • Status changed from New to Feedback
  • Affected Version changed from 2.2.4 to 2.2.x

is this replicable for you? Not sure how a connection could go missing but actually be there in the conf file.

Actions #2

Updated by Frédéric Pougnault over 8 years ago

I updated last week from 2.2.4 to 2.2.5.
The problem persist, I had to restart charon daemon once a day in the crontab to solve problem.
If I remove the command from the crontab, the error message "No config named conxxx" come back after three days

Actions #3

Updated by Stephen Morri almost 8 years ago

I can confirm this issue that is still present in 2.3.1-RELEASE-p5 :

Sep 23 13:01:12  charon: 09[CFG] received stroke: initiate 'con5'
Sep 23 13:01:12  charon: 09[CFG] received stroke: initiate 'con5'
Sep 23 13:01:12  charon: 09[CFG] no config named 'con5'
Sep 23 13:01:12  charon: 09[CFG] no config named 'con5'

The 'con5' config does exist in /var/etc/ipsec/ipsec.conf

conn con5
    fragmentation = yes
    keyexchange = ikev2
    reauth = yes
    forceencaps = no
    mobike = no

    rekey = yes
    installpolicy = yes
    type = tunnel
    dpdaction = restart
    dpddelay = 10s
    dpdtimeout = 60s
    auto = route
    left = x.x.x.x
    right = x.x.x.x
    leftid = x.x.x.x
    ikelifetime = 86400s
    lifetime = 86400s
    ike = aes256-sha1-modp1024!
    esp = aes256-sha1-modp1024!
    leftauth = psk
    rightauth = psk
    rightid = x.x.x.x
    rightsubnet = x.x.x.x
    leftsubnet = x.x.x.x

Then restart forcefully the daemon because a reload from the GUI doesn't change anything

[2.3.1-RELEASE][admin@pfsense]/root: ps aux | grep charon
root    28957  0.0  1.6 197740 16168  -  Ss    9Sep16     7:21.30 /usr/local/libexec/ipsec/charon
[2.3.1-RELEASE][admin@pfsense]/root: kill -9 28957
[2.3.1-RELEASE][admin@pfsense]/root: rm /var/run/starter.charon.pid 
[2.3.1-RELEASE][admin@pfsense]/root: ipsec start
Starting strongSwan 5.4.0 IPsec [starter]...
no netkey IPsec stack detected
no KLIPS IPsec stack detected
no known IPsec stack detected, ignoring!
[2.3.1-RELEASE][admin@pfsense]/root: ps aux | grep charon
root     4788  0.0  1.2 193644 12608  -  Ss    1:02PM     0:00.04 /usr/local/libexec/ipsec/charon

Then the tunnel does start successfully :

Sep 23 13:02:48  charon 13[CFG] received stroke: initiate 'con5'
Sep 23 13:02:48  charon 08[IKE] <con5|2> initiating IKE_SA con5[2] to x.x.x.x
Actions #4

Updated by Nick Fisk over 7 years ago

I've just been hit by this as well and like the last comment, restarting ipsec from the cmd line fixes the problem for me. I'm running 2.3.2.

I couldn't see any reason why this would happen. The config file /var/etc/ipsec/ipsec.conf has the correct entries. Its almost like the running process has forgotten about them, but running a "ipsec reload" doesn't help either.

Actions #5

Updated by Fabian Melters over 7 years ago

I can confirm this one too. 2.3.2 in use.

ipsec reload

or
ipsec update

Does not help. Stopping IPSec via the Webinterface, does only stop the "starter" but not "charon".
Trying to stop it via the commandline:
ipsec stop
Stopping strongSwan IPsec failed: starter is not running

Killing charon and restarting ipsec is the only way to fix this so far.

Actions #6

Updated by Alex Vergilis over 7 years ago

With 2.3.2, in a hub and spoke model of IPsec tunnels, when the hub was restarted, about 10 percent of the spoke models experienced this issue and could not reconnect or stop the service.

As with others, killing charon and restarting ipsec, is the only way I was able to address this.

Actions #7

Updated by Frédéric Pougnault about 7 years ago

Hello,

In 2.3.3 the bug is present.
After two months when ipsec tunnel are down they don't restart because of this message :

charon: 14[CFG] no config named 'con30000'

Actions #8

Updated by Robert Olofsson about 7 years ago

This bug is also present in 2.3.4, I have to kill the charon process every 2-3 days to keep the problem from appearing.

Actions #9

Updated by Kilian Ries almost 7 years ago

Bug is still present in 2.3.4-RELEASE-p1. Any news on fixing this?

Actions #10

Updated by Vladimir Lind over 6 years ago

Bug is also present in 2.4-rel

Actions #11

Updated by Daniel Clasen over 5 years ago

Still present in 2.4.2-RELEASE-p1
Took me a full day to figure out that this was the problem... Will the bug be fixed or is it already fixed in a newer version?
For a workaround it would also be nice if the IPSec restart from the webui would also restart the charon service. Then one is at least able to restart the whole IPSec stack without sshing to the pf box or rebooting everything.

Actions #12

Updated by Jim Pingle over 5 years ago

Testing on 2.4.2 is meaningless. That version is over a year old and 4 (almost 5) releases behind, and several strongSwan revisions behind as well. Test on 2.4.4 or, preferably, on the upcoming 2.4.4-p1 release.

Actions #13

Updated by Daniel Clasen over 5 years ago

Jim Pingle wrote:

Testing on 2.4.2 is meaningless. That version is over a year old and 4 (almost 5) releases behind, and several strongSwan revisions behind as well. Test on 2.4.4 or, preferably, on the upcoming 2.4.4-p1 release.

Sure, but I wasn't just testing... This is a version we are still running on a big internal corporate network. It is just not that easy to get approval to upgrade main network components always to its latest versions. But this is exactly why I am asking if it is fixed in a newer version. If so that would give me some ammo I can arm up with and go to my management ;)

Actions #14

Updated by Jim Pingle over 5 years ago

That is not a topic for the ticket system, however, but something you should ask on the forum. The older versions are unsupported and have known security flaws, which should be more than enough to convince any sane management team that an update is warranted.

Actions #15

Updated by Daniel Clasen over 5 years ago

Sorry but I can't see how it is not a topic for the ticket system to ask if that is fixed in a newer/supported release. Regardless of what version is old and unsupported and what not. If you can't answer that, Jim, it is totally fine for me. Maybe there is somebody out in the wild who knows it and is willing to tell us here. I just can't test it myself currently as I won't find the time to setup a test system and reproduce the issue (as it is currently not reproducible at all for me).

Actions #16

Updated by Jim Pingle over 5 years ago

Daniel Clasen wrote:

Sorry but I can't see how it is not a topic for the ticket system to ask if that is fixed in a newer/supported release.

Upgrade procedures and your company's inability to follow best security practices is off-topic. You can ask if an old bug has been fixed on a newer version, but when you're already multiple versions behind, few people are probably going to be able to answer that question accurately. The best path forward is to upgrade (in a lab first, preferably).

Actions #17

Updated by Jim Pingle almost 5 years ago

  • Status changed from Feedback to Closed

No timely and meaningful feedback received.

Actions

Also available in: Atom PDF