pfSense

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

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

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.

I can confirm this one too. 2.3.2 in use.

ipsec reload

ipsec update

ipsec stop
Stopping strongSwan IPsec failed: starter is not running

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

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.

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'

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.

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

Bug is also present in 2.4-rel

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.

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.

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 ;)

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.

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).

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).