Even though everything works, IPsec is marked not running
-
Hi,
I upgraded pfsense from 2.1.5 to 2.2.2 (I skipped some versions because of https://forum.pfsense.org/index.php?topic=91739.0 ).
I have IPsec site to site tunnels to amazon and after upgrade in status -> Ipsec I see big red cross with "IPsec not running" I see all tunnels as disconnected in pfsense gui, but everything actually works, communication flows and so on. When I click to start IPsec process nothing happens, page reloads, IPsec still looks as not running and logs don't show anything about restart at all they continue to fill themselves with INFO about how the tunnels nicely works.Any thoughts about what could be wrong? Or tell me what logs/information to provide and I will.
Thanks!
-
I would love to have your "problem". Leave the thing alone while it works. There are loads of people with "all green" in the GUI and traffic going to /dev/blackhole.
-
When I try to disable ipsec by unselecting "Enable Ipsec" I get "Unread Notice: [ There were error(s) loading the rules: pfctl: DIOCADDRULE: Operation not supported by device - The line in question reads [0]: ]"
and the same when I try to do some changes to tunnel configuration and save it… it looks like the gui completely lost control of the ipsec -
IPSec status looks like a Christmas tree because of this:
@pedymaster:(https://forum.pfsense.org/index.php?topic=91739.0 ).
After the activation of this feature, pfSense isn't complaining anymore about the usage of "impossible IP's" but …. IPsec - a boatload of code - is trying to tell you, through pfSense, that something isn't quiet right.
Well, that is correct. RFC 3927 is busted, IPSec isn't happy about it. -
When I try to disable ipsec by unselecting "Enable Ipsec" I get "Unread Notice: [ There were error(s) loading the rules: pfctl: DIOCADDRULE: Operation not supported by device - The line in question reads [0]: ]"
and the same when I try to do some changes to tunnel configuration and save it… it looks like the gui completely lost control of the ipsecThat sounds like what happens when the system doesn't reboot post-upgrade, you end up with mismatched kernel and userland and components running that otherwise don't exist. Did the system reboot post-upgrade, is your uptime as shown on the dashboard reasonable?
IPSec status looks like a Christmas tree because of this:
@pedymaster:(https://forum.pfsense.org/index.php?topic=91739.0 ).
For 1 in a thousand people maybe, if that. Outside of Amazon VPC VPNs using BGP, that impacts no one with a sane configuration.
-
@cmb:
That sounds like what happens when the system doesn't reboot post-upgrade, you end up with mismatched kernel and userland and components running that otherwise don't exist. Did the system reboot post-upgrade, is your uptime as shown on the dashboard reasonable?
Will check the uptime tomorrow and let you know. Thanks! I also plan to try upgrade version by version manually. Right now it is from 2.1.5 to 2.2.2 and I know that 2.2.1 was OK, so I will try to upgrade to 2.2.1 and then to 2.2.2.
-
IPSec status looks like a Christmas tree because of this:
@pedymaster:(https://forum.pfsense.org/index.php?topic=91739.0 ).
After the activation of this feature, pfSense isn't complaining anymore about the usage of "impossible IP's" but …. IPsec - a boatload of code - is trying to tell you, through pfSense, that something isn't quiet right.
Well, that is correct. RFC 3927 is busted, IPSec isn't happy about it.My problem happens even before I do the "hack" mentioned in the topic, so I dont think its related
-
I "solved" The issue. I knew the IPsec was working correctly on 2.2.1, so I instead of going 2.1.5 -> 2.2.2 I did a middle step 2.1.5 -> 2.2.1 -> 2.2.2 and all works as expected now
