IPSEC - 2.6.0 - after a Fireawall Reboot a restart of the VPN Service is necessary
-
I recently upgraded from 2.5.2 to 2.6.0. After the Upgrade a IPSEC connection from clients will fail, unless I restart the VPN Service. After restarting the Service, clients can connect again.
The Firewall is using a multiwan configuration. before the Upgrade everything was working as expected.
On another Firewall w/o Multiwan, this behavior can't be observed after the upgrade to 2.6.0Is there someone else out there, experiencing such a issue ?
-
@maars-loonga
I have the same problem -
Im having terrible problems all over with 2.6 and iPsec. Connections work then dont reconnect or dont connect at all. Reverting to 2.5 with same config all is 100% fine.
-
i have same issue i am on 22.01 and tunnels keep dropping then ipsec service is unresponsive and had to reboot fullbox
-
My SG-2100 to, version 22.01, after some problems with the Cable internet. S2S between both Netgate Appliances.
Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> IKE_SA con3[2] state change: CONNECTING => DESTROYING Apr 1 20:49:24 charon 49028 10[CFG] <con3|2> configured proposals: IKE:AES_GCM_16_128/PRF_HMAC_SHA2_256/ECP_521, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521 Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> received NO_PROPOSAL_CHOSEN notify error Apr 1 20:49:24 charon 49028 10[ENC] <con3|2> parsed IKE_SA_INIT response 0 [ N(NO_PROP) ] Apr 1 20:49:24 charon 49028 10[NET] <con3|2> received packet: from "Remot IPv6"[500] to "Local IPv6"[500] (36 bytes) Apr 1 20:49:24 charon 49028 10[NET] <con3|2> sending packet: from "Local IPv6"[500] to "Remot IPv6"[500] (376 bytes) Apr 1 20:49:24 charon 49028 10[ENC] <con3|2> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ] Apr 1 20:49:24 charon 49028 10[CFG] <con3|2> sending supported signature hash algorithms: sha256 sha384 sha512 identity Apr 1 20:49:24 charon 49028 10[CFG] <con3|2> configured proposals: IKE:AES_GCM_16_128/PRF_HMAC_SHA2_256/ECP_521, IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_521 Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> IKE_SA con3[2] state change: CREATED => CONNECTING Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> initiating IKE_SA con3[2] to "Remot IPv6" Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating IKE_MOBIKE task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating IKE_AUTH_LIFETIME task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating CHILD_CREATE task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating IKE_CONFIG task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating IKE_CERT_POST task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating IKE_AUTH task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating IKE_CERT_PRE task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating IKE_NATD task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating IKE_INIT task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating IKE_VENDOR task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> activating new tasks Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing CHILD_CREATE task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing IKE_MOBIKE task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing IKE_AUTH_LIFETIME task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing IKE_CONFIG task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing IKE_CERT_POST task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing IKE_AUTH task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing IKE_CERT_PRE task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing IKE_NATD task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing IKE_INIT task Apr 1 20:49:24 charon 49028 10[IKE] <con3|2> queueing IKE_VENDOR task Apr 1 20:49:24 charon 49028 13[KNL] creating acquire job for policy "Local IPv6"/128|/0 === "Remot IPv6"/128|/0 with reqid {1}
Reboot it, no change, works again until the next internet outage.
-
@nocling I tried Ipsec using IPV6 and had pretty weird errors (This was with a starlink service so it does drop more than you would like) - essentially it wasn't stable as an ipsec tunnel (this was using 2.5) - switched over to WireGuard and its been working really well - just doesnt seem to be 100% support from netgate yet so reluctant to replace all ipsec with WireGuard.