Dashboard Show IPSEC inactive
-
Just migrated from 2.1.5 to 2.2-RC and problem exists in this release. Status page (diag_ipsec.php) shows tunnels active, but widget shows them inactive.
Release info:
2.2-RC (i386)
built on Fri Dec 26 09:31:09 CST 2014
FreeBSD 10.1-RELEASE-p3 -
All known issues there have been fixed, including some regressions introduced early last week, confirmed fixed on a number of systems on the 26th snapshot. What does your diag_ipsec.php page look like exactly? Screenshot would be helpful.
-
2.2-RC (i386)
built on Sun Dec 28 04:40:24 CST 2014
FreeBSD 10.1-RELEASE-p3I my system, 3/7 ipsec ph2 is up, but the widget shows all 7 as down.
-
I see the same behaviour as well.
The dashboard never shows more than 6 tunnels as being up.
-
I my system, 3/7 ipsec ph2 is up, but the widget shows all 7 as down.
Your counters are all 0, if you pass traffic across it does it then show as up?
-
No. I have traffic through 2/7 ph2, but "Active Tunnels" is still 0.
-
Additional information: tunnels that show as "down" in the widget are all missing the <iketype>tag in config.xml. These tunnels were all created on earlier versions of pfSense and migrated during the router upgrade. Manually setting iketype to ikev1 below <ikeid>resolves the widget problem.
I can't tell you exactly what release originally created the config.xml entries, since my backups don't go back that far, but it seems like the migration process ought to check for missing <iketype>and set it to ikev1 if missing.</iketype></ikeid></iketype>
-
https://github.com/pfsense/pfsense/pull/1412
Maybe this pull request will help - it allows for iketype being empty, similar to what is already done in other places like /usr/local/www/vpn_ipsec.php and /etc/inc/vpn.inc
Try the 1-line change to the if test there and confirm if it makes it work.Edit add:
It also looks like there would be a problem on Status->IPsec disconnect/connect button for those entries with no iketype.
https://github.com/pfsense/pfsense/pull/1413
Can you also confirm if that is a problem, and if this pull request fixes it? -
Given that we'd probably be better off with some upgrade code to explicitly set the iketype on upgrade so it isn't ever undefined, too.
-
Given that we'd probably be better off with some upgrade code to explicitly set the iketype on upgrade so it isn't ever undefined, too.
Yes, there are already a few places in the code that treat empty iketype as ikev1, thus working with the old configs. A search for "iketype" turned up the 2 places above that did not handle the empty iketype case.
But it is nice that the config explicitly specifies things like this, because in 10 years when there is IKEv1,2,3,4… people will be a little confused by an ancient config with no iketype specified, and it saves future new code having to remember to handle the empty case.