Bug #5319
closed
Error message "No config named" in charon daemon
Added by Frédéric Pougnault over 8 years ago. Updated over 4 years ago.
0%
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"
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.
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
Updated by Stephen Morri over 7 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
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.
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.
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.
Updated by Frédéric Pougnault almost 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'
Updated by Robert Olofsson almost 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.
Updated by Kilian Ries over 6 years ago
Bug is still present in 2.3.4-RELEASE-p1. Any news on fixing this?
Updated by Vladimir Lind
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.
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.
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 ;)
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.
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).
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).
Updated by Jim Pingle over 4 years ago
- Status changed from Feedback to Closed
No timely and meaningful feedback received.