Debugging 2.3-RC IPSEC Startup Issues
-
Since I upgraded to 2.3-RC a few nights ago, I have had an issue where upon reboot I end up with a non-functioning IPSEC. Further investigation leads me to find that for whatever reason, IPSEC was started up twice, and of course that leads to bad things. I see basically the following (NOTE THESE ARE NOT REAL)
root 39914 0.0 0.1 30380 3896 - Is 10:41PM 0:00.00 /usr/local/libexec/ipsec/starter –daemon charon
root 39920 0.0 0.1 30380 3896 - Is 10:41PM 0:00.00 /usr/local/libexec/ipsec/starter --daemon charon
root 39972 0.0 0.4 222300 16380 - Ss 10:41PM 0:08.02 /usr/local/libexec/ipsec/charon --use-syslog
root 39990 0.0 0.4 222300 16380 - Ss 10:41PM 0:08.02 /usr/local/libexec/ipsec/charon --use-syslogThis is completely hypothetical right now as I don't feel like rebooting to reproduce it (and pissing off the teenager).. But basically on every reboot, until I SSH in and kill these by hand (because hitting stop from the Interface doesn't fix this), I'm dead in the water. Once I do kill them I can restart from the interface and my IPSEC tunnels come right up. I've been running 2.3 for months now, and I've never encountered this bug until I updated to RC. So this is something relatively VERY new. I've rebooted about 10 times in the past 2 days since going to 2.3-RC and it still is occurring as well (as I've had an occasional oddity on one boot be cleared up before)
I'd be happy to debug this and try and figure it out, just not sure how to debug startup items like this. Any pointers, etc.
-
I'm not using IPsec but after the upgrade to 2.3 RC the IPsec service was running. There was a tunnel created with no endpoints. I deleted the tunnel, rebooted, and the service/tunnel remain gone for me.
At some points ages ago I was testing IPsec tunnels but I don't see any reference to them in my pre-upgrade backup, and I'm sure there was no ipsec service running in my install of 2.2.6. So I'm not sure where that tunnel came from.
-
This is the code from /etc/inc/vpn.inc that runs 'ipsec start'.
/* manage process */ if ($restart === true) { mwexec("/usr/local/sbin/ipsec restart", false); } else { if (isvalidpid("{$g['varrun_path']}/starter.charon.pid")) { /* Update configuration changes */ /* Read secrets */ mwexec("/usr/local/sbin/ipsec rereadall", false); mwexec("/usr/local/sbin/ipsec reload", false); } else { mwexec("/usr/local/sbin/ipsec start", false); } }
If you try to start it while it's already running, it sees the PID file and just exits.
# ipsec start Starting strongSwan 5.4.0 IPsec [starter]... charon is already running (/var/run/charon.pid exists) -- skipping daemon start
So I'm not sure how it could end up running twice. Maybe if you run 'ipsec start' twice really close to the same time, so both run before the first gets the PID in place.
I'd turn those lines above into something like this:
$ts = microtime(true); log_error("DEBUG: vpn_ipsec_configure manage process. $ts"); /* manage process */ if ($restart === true) { mwexec("/usr/local/sbin/ipsec restart", false); log_error("DEBUG: $ts - ipsec reload"); } else { if (isvalidpid("{$g['varrun_path']}/starter.charon.pid")) { /* Update configuration changes */ /* Read secrets */ log_error("DEBUG: $ts - rereadall and reload"); mwexec("/usr/local/sbin/ipsec rereadall", false); mwexec("/usr/local/sbin/ipsec reload", false); } else { log_error("DEBUG: $ts - ipsec start"); mwexec("/usr/local/sbin/ipsec start", false); } }
and replicate, then look at the log to see what's happening ("clog /var/log/system.log|grep DEBUG" in SSH).