After 19.7 upgrade some IPSEC tunnel only came up after edit/apply #3582

mimugmail · 2019-07-18T05:17:21Z

Firewall with 3 VPNs updated to 19.7 and rebooted. 2 tunnels were stuck in Phase2 (other side OPNsense) and one tunnel up (Sophos). When I edit one of the two connection and hit apply, both of the others are up again.

I did a diff after reboot and compared with after hitting apply (error is reproduceable with every reboot):

root@mcbfw01:~ # diff -Naur /usr/local/etc/ipsec.conf /root/ipsec.conf.before
--- /usr/local/etc/ipsec.conf   2019-07-18 07:09:20.148367000 +0200
+++ /root/ipsec.conf.before     2019-07-18 07:08:32.711341000 +0200
@@ -53,7 +53,6 @@
   rightid = 91.66.72.9
   rightsubnet = 192.168.169.0/24
   leftsubnet = 10.65.220.0/24
-  esp = aes256-sha1-modp1536,aes192-sha1-modp1536,aes128-sha1-modp1536!
   auto = route

 conn con3
@@ -79,7 +78,6 @@
   rightid = 211.86.55.226
   rightsubnet = 10.0.82.0/24
   leftsubnet = 172.22.24.0/24
-  esp = aes256-sha1-modp1536,aes192-sha1-modp1536,aes128-sha1-modp1536!
   auto = route

 include ipsec.opnsense.d/*.conf

This is the log from the upgraded firewall:

Jul 18 07:07:41 mcbfw01 charon: 06[KNL] creating acquire job for policy 81.26.63.9/32 === 214.86.22.226/32 with reqid {2}
Jul 18 07:07:41 mcbfw01 charon: 06[ENC] <con3|3> generating QUICK_MODE request 3793965782 [ HASH SA No ID ID ]
Jul 18 07:07:41 mcbfw01 charon: 06[NET] <con3|3> sending packet: from 81.26.63.9[500] to 214.86.22.226[500] (188 bytes)
Jul 18 07:07:41 mcbfw01 charon: 06[NET] <con3|3> received packet: from 214.86.22.226[500] to 81.26.63.9[500] (76 bytes)
Jul 18 07:07:41 mcbfw01 charon: 06[ENC] <con3|3> parsed INFORMATIONAL_V1 request 2153474621 [ HASH N(NO_PROP) ]
Jul 18 07:07:41 mcbfw01 charon: 06[IKE] <con3|3> received NO_PROPOSAL_CHOSEN error notify
Jul 18 07:07:47 mcbfw01 charon: 06[KNL] creating acquire job for policy 81.26.63.9/32 === 214.86.22.226/32 with reqid {2}
Jul 18 07:07:47 mcbfw01 charon: 05[ENC] <con3|3> generating QUICK_MODE request 1883965852 [ HASH SA No ID ID ]
Jul 18 07:07:47 mcbfw01 charon: 05[NET] <con3|3> sending packet: from 81.26.63.9[500] to 214.86.22.226[500] (188 bytes)
Jul 18 07:07:47 mcbfw01 charon: 05[NET] <con3|3> received packet: from 214.86.22.226[500] to 81.26.63.9[500] (76 bytes)
Jul 18 07:07:47 mcbfw01 charon: 05[ENC] <con3|3> parsed INFORMATIONAL_V1 request 2461407214 [ HASH N(NO_PROP) ]
Jul 18 07:07:47 mcbfw01 charon: 05[IKE] <con3|3> received NO_PROPOSAL_CHOSEN error notify
Jul 18 07:07:54 mcbfw01 charon: 05[KNL] creating acquire job for policy 81.26.63.9/32 === 214.86.22.226/32 with reqid {2}
Jul 18 07:07:54 mcbfw01 charon: 06[ENC] <con3|3> generating QUICK_MODE request 562544285 [ HASH SA No ID ID ]
Jul 18 07:07:54 mcbfw01 charon: 06[NET] <con3|3> sending packet: from 81.26.63.9[500] to 214.86.22.226[500] (188 bytes)
Jul 18 07:07:54 mcbfw01 charon: 05[NET] <con3|3> received packet: from 214.86.22.226[500] to 81.26.63.9[500] (76 bytes)
Jul 18 07:07:54 mcbfw01 charon: 05[ENC] <con3|3> parsed INFORMATIONAL_V1 request 523731975 [ HASH N(NO_PROP) ]
Jul 18 07:07:54 mcbfw01 charon: 05[IKE] <con3|3> received NO_PROPOSAL_CHOSEN error notify

And this from the remote site:

Jul 18 07:08:40 OPN-BER charon: 11[NET] <con1|65> received packet: from 81.26.63.9[500] to 214.86.22.226[500] (188 bytes)
Jul 18 07:08:40 OPN-BER charon: 11[ENC] <con1|65> parsed QUICK_MODE request 4224452279 [ HASH SA No ID ID ]
Jul 18 07:08:40 OPN-BER charon: 11[CFG] <con1|65> received proposals: ESP:AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ
Jul 18 07:08:40 OPN-BER charon: 11[CFG] <con1|65> configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ, ESP:AES_CBC_192/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/MODP_1536/NO_EXT_SEQ
Jul 18 07:08:40 OPN-BER charon: 11[IKE] <con1|65> no matching proposal found, sending NO_PROPOSAL_CHOSEN
Jul 18 07:08:40 OPN-BER charon: 11[ENC] <con1|65> generating INFORMATIONAL_V1 request 2535783569 [ HASH N(NO_PROP) ]
Jul 18 07:08:40 OPN-BER charon: 11[NET] <con1|65> sending packet: from 214.86.22.226[500] to 81.26.63.9[500] (76 bytes)

And there is also one other guy in the forums complaining ...
https://forum.opnsense.org/index.php?topic=13516.msg62233;boardseen#new

The text was updated successfully, but these errors were encountered:

fichtner · 2019-07-18T05:42:03Z

This is weird, because...

$ git checkout stable/19.7
Switched to branch 'stable/19.7'
Your branch is up to date with 'origin/stable/19.7'.
$ git diff stable/19.1 src/etc/inc/plugins.inc.d/ipsec.inc 
diff --git a/src/etc/inc/plugins.inc.d/ipsec.inc b/src/etc/inc/plugins.inc.d/ipsec.inc
index f8692b5b8..68819f8ae 100644
--- a/src/etc/inc/plugins.inc.d/ipsec.inc
+++ b/src/etc/inc/plugins.inc.d/ipsec.inc
@@ -231,7 +231,8 @@ function ipsec_firewall(\OPNsense\Firewall\Plugin $fw)
                                       "quick" => false,
                                       "type" => "pass",
                                       "statetype" => "keep",
-                                      "label" => "IPsec: " . (!empty($ph1ent['descr']) ? $ph1ent['descr'] : $rgip)
+                                      "#ref" => "vpn_ipsec_settings.php#disablevpnrules",
+                                      "descr" => "IPsec: " . (!empty($ph1ent['descr']) ? $ph1ent['descr'] : $rgip)
                                     );
 
                     // find gateway

... there is no functional change in IPsec code between 19.1.10 and 19.7.

fichtner · 2019-07-18T05:46:34Z

Can you diff the config history for clues?

mimugmail · 2019-07-18T07:13:50Z

Hm, there's nothing.

root@mcbfw01:~ # diff -Naur /conf/config.xml /root/config.xml.reboot
--- /conf/config.xml    2019-07-18 09:11:46.818015000 +0200
+++ /root/config.xml.reboot     2019-07-18 09:11:17.318114000 +0200
@@ -787,9 +787,9 @@
     <column_count>2</column_count>
   </widgets>
   <revision>
-    <username>root@81.26.36.132</username>
-    <time>1563433906.814</time>
-    <description>/vpn_ipsec_phase1.php made changes</description>
+    <username>(system)</username>
+    <time>1563441179.6419</time>
+    <description>/usr/local/opnsense/mvc/script/run_migrations.php made changes</description>
   </revision>
   <OPNsense>
     <captiveportal version="1.0.0">
@@ -1560,5 +1560,5 @@
     <client/>
   </ipsec>
   <ppps/>
-  <staticroutes/>
+  <staticroutes version="1.0.0"/>
 </opnsense>

fichtner · 2019-07-18T07:27:32Z

And the System: Configuration: History page?

You're saying on reboot IPsec comes up but forgets to write a single configuration line and after save and apply it's back? Does this happen after every reboot or just one time on 19.7?

This is weird...

mimugmail · 2019-07-18T07:34:01Z

It happens on every reboot. The tunnels are stuck in Phase1. I change to Status Overview where I can stop and initiate the tunnel multiple times, doesn't work. Then I edit one connection, don't change anything, save, apply. Then the tunnels go up. It's reproduceable ..

mimugmail · 2019-07-18T07:54:30Z

Configuration diff from 7/17/19 12:03:17 to 7/18/19 09:33:22
--- /conf/backup/config-1563425176.1244.xml	2019-07-18 06:46:16.126954000 +0200 
+++ /conf/config.xml	2019-07-18 09:33:22.372178000 +0200 
@@ -788,8 +788,8 @@ 
   </widgets> 
   <revision> 
     <username>root@81.26.36.132</username> 
-    <time>1563357797.4607</time> 
-    <description>/api/core/firmware/setFirmwareConfig made changes</description> 
+    <time>1563435202.3678</time> 
+    <description>/vpn_ipsec_phase1.php made changes</description> 
   </revision> 
   <OPNsense> 
     <captiveportal version="1.0.0"> 
@@ -839,26 +839,6 @@ 
         </aliases> 
       </Alias> 
     </Firewall> 
-    <IDS version="1.0.2"> 
-      <rules/> 
-      <userDefinedRules/> 
-      <files/> 
-      <fileTags/> 
-      <general> 
-        <enabled>0</enabled> 
-        <ips>0</ips> 
-        <promisc>0</promisc> 
-        <interfaces>wan</interfaces> 
-        <homenet>192.168.0.0/16,10.0.0.0/8,172.16.0.0/12</homenet> 
-        <defaultPacketSize/> 
-        <UpdateCron/> 
-        <AlertLogrotate>W0D23</AlertLogrotate> 
-        <AlertSaveLogs>4</AlertSaveLogs> 
-        <MPMAlgo>ac</MPMAlgo> 
-        <syslog>0</syslog> 
-        <LogPayload>0</LogPayload> 
-      </general> 
-    </IDS> 
     <monit version="1.0.8"> 
       <general> 
         <enabled>0</enabled> 
@@ -1394,6 +1374,33 @@ 
       <queues/> 
       <rules/> 
     </TrafficShaper> 
+    <IDS version="1.0.3"> 
+      <rules/> 
+      <userDefinedRules/> 
+      <files/> 
+      <fileTags/> 
+      <general> 
+        <enabled>0</enabled> 
+        <ips>0</ips> 
+        <promisc>0</promisc> 
+        <interfaces>wan</interfaces> 
+        <homenet>192.168.0.0/16,10.0.0.0/8,172.16.0.0/12</homenet> 
+        <defaultPacketSize/> 
+        <UpdateCron/> 
+        <AlertLogrotate>W0D23</AlertLogrotate> 
+        <AlertSaveLogs>4</AlertSaveLogs> 
+        <MPMAlgo>ac</MPMAlgo> 
+        <syslog>0</syslog> 
+        <syslog_eve>0</syslog_eve> 
+        <LogPayload>0</LogPayload> 
+      </general> 
+    </IDS> 
+    <Syslog version="1.0.0"> 
+      <general> 
+        <enabled>1</enabled> 
+      </general> 
+      <destinations/> 
+    </Syslog> 
   </OPNsense> 
   <cert> 
     <refid>5a12f8c246dd0</refid> 
@@ -1450,13 +1457,13 @@ 
         <name>aes</name> 
         <keylen>128</keylen> 
       </encryption-algorithm> 
-      <hash-algorithm>sha1</hash-algorithm> 
-      <dhgroup>5</dhgroup> 
       <lifetime>86400</lifetime> 
       <pre-shared-key>x</pre-shared-key> 
       <authentication_method>pre_shared_key</authentication_method> 
       <descr>Liros</descr> 
       <nat_traversal>on</nat_traversal> 
+      <dhgroup>5</dhgroup> 
+      <hash-algorithm>sha1</hash-algorithm> 
       <private-key/> 
       <remote-gateway>96.237.72.214</remote-gateway> 
       <dpd_delay>10</dpd_delay> 
@@ -1553,5 +1560,5 @@ 
     <client/> 
   </ipsec> 
   <ppps/> 
-  <staticroutes version="1.0.0"/> 
+  <staticroutes/> 
 </opnsense>

fichtner · 2019-07-18T07:57:21Z

Looks ok to me, it could only be a boot artefact if anything.

mimugmail · 2019-07-18T08:01:44Z

Hm, any idea why it always reverts on reboot?

fichtner · 2019-07-18T08:03:29Z

No clue so far. We will need to print-debug on this. I don't see this on my phase 2 connections.

mimugmail · 2019-07-19T14:51:32Z

Ok, I found the issue (not the solution). When in Phase2 the encryption is set to AES(auto), the esp line in con is missing after reboot. When you hit just Save in VPN menu the value now is:
aes256-sha1-modp1536,aes192-sha1-modp1536,aes128-sha1-modp1536!

If I switch from auto to e.g. 256 it's the correct value from the beginning:
esp = aes256-sha1-modp1536!

So, it must be something with AES(auto) ...

Add a little plugin glue to two tainted spots.

AdSchellevis · 2019-07-21T17:45:29Z

@mimugmail can you share a config snippet (phase1 + phase2) where this happens? there are different paths leading to an esp line. at a first glance boot and apply are using the same code.

mimugmail · 2019-07-22T05:31:34Z

@AdSchellevis this is the config.xml part:

    <phase1>
      <ikeid>2</ikeid>
      <iketype>ikev1</iketype>
      <interface>wan</interface>
      <mode>main</mode>
      <protocol>inet</protocol>
      <myid_type>myaddress</myid_type>
      <peerid_type>peeraddress</peerid_type>
      <encryption-algorithm>
        <name>aes</name>
        <keylen>128</keylen>
      </encryption-algorithm>
      <lifetime>86400</lifetime>
      <pre-shared-key>X</pre-shared-key>
      <authentication_method>pre_shared_key</authentication_method>
      <descr>Kiros</descr>
      <nat_traversal>on</nat_traversal>
      <dhgroup>5</dhgroup>
      <hash-algorithm>sha1</hash-algorithm>
      <private-key/>
      <remote-gateway>95.137.72.214</remote-gateway>
      <dpd_delay>10</dpd_delay>
      <dpd_maxfail>5</dpd_maxfail>
    </phase1>
    
    <phase2>
      <ikeid>2</ikeid>
      <uniqid>5a609d04da8ca</uniqid>
      <mode>tunnel</mode>
      <pfsgroup>5</pfsgroup>
      <lifetime>28800</lifetime>
      <descr>Kiros</descr>
      <protocol>esp</protocol>
      <localid>
        <type>opt1</type>
      </localid>
      <remoteid>
        <type>network</type>
        <address>192.168.169.0</address>
        <netbits>24</netbits>
      </remoteid>
      <encryption-algorithm-option>
        <name>aes</name>
        <keylen>auto</keylen>
      </encryption-algorithm-option>
      <hash-algorithm-option>hmac_sha1</hash-algorithm-option>
    </phase2>

And that's what came out after reboot:

conn con2
  aggressive = no
  fragmentation = yes
  keyexchange = ikev1
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
  dpdaction = restart
  dpddelay = 10s
  dpdtimeout = 60s
  left = 85.24.64.20
  right = 95.137.72.214

  leftid = 85.24.64.20
  ikelifetime = 86400s
  lifetime = 28800s
  ike = aes128-sha1-modp1536!
  leftauth = psk
  rightauth = psk
  rightid = 95.137.72.214
  rightsubnet = 192.168.169.0/24
  leftsubnet = 10.65.220.0/24
  auto = route

When I go to VPN - IPSec - Tunnel Settings and hit Save the config is:

conn con2
  aggressive = no
  fragmentation = yes
  keyexchange = ikev1
  mobike = yes
  reauth = yes
  rekey = yes
  forceencaps = no
  installpolicy = yes
  type = tunnel
  dpdaction = restart
  dpddelay = 10s
  dpdtimeout = 60s
  left = 85.24.64.20
  right = 95.137.72.214

  leftid = 85.24.64.20
  ikelifetime = 86400s
  lifetime = 28800s
  ike = aes128-sha1-modp1536!
  leftauth = psk
  rightauth = psk
  rightid = 95.137.72.214
  rightsubnet = 192.168.169.0/24
  leftsubnet = 10.65.220.0/24
  esp = aes256-sha1-modp1536,aes192-sha1-modp1536,aes128-sha1-modp1536!
  auto = route

When I set a fixed bit length of AES is phase2 it's working.

Thanks for jumping in :)

AdSchellevis · 2019-07-22T09:42:29Z

@mimugmail I can reproduce your issue, this is quite weird. run ipsec_configure_do() after boot and the esp section is back again.

AdSchellevis · 2019-07-22T11:34:41Z

@mimugmail php is playing tricks here with a global assignment, 64858b5 rewrites the globals to function calls

mimugmail · 2019-07-22T12:46:44Z

Works, best Ad in town, thanks! :)

fichtner · 2019-07-22T12:55:00Z

Nice catch this one indeed!

hboetes · 2019-07-22T20:26:30Z

I just connected 2 dots and ran the command:
opnsense-patch 64858b5

To apply the patch, without having to wait for the hotfix.

@AdSchellevis please remove this comment if it's not helpful or dangerous.

AdSchellevis · 2019-07-23T06:39:24Z

@hboetes what comment?

hboetes · 2019-07-23T06:52:02Z

@AdSchellevis the very comment the sentence comes from.

AdSchellevis · 2019-07-23T06:53:44Z

@hboetes ah, I totally misunderstood, you mean your opnsense-patch comment, on 19.7 it's safe to run, no worries :)

…bootup, closes #3582 (cherry picked from commit 64858b5)

MrChrH · 2019-07-24T10:27:19Z

Ok, I found the issue (not the solution). When in Phase2 the encryption is set to AES(auto), the esp line in con is missing after reboot. When you hit just Save in VPN menu the value now is:
aes256-sha1-modp1536,aes192-sha1-modp1536,aes128-sha1-modp1536!

If I switch from auto to e.g. 256 it's the correct value from the beginning:
esp = aes256-sha1-modp1536!

So, it must be something with AES(auto) ...

I also had some tunnels which dropped phase2 after some time, all had been AES(auto). Changed auto to 256 and it is working so far like the other tunnels that were configured to 256 from beginning.

MindVersal · 2019-11-17T07:51:17Z

I have this bug.
Patch 64858b5 appled, version upgraded to 19.7.6.
Did not help.
On first instance: IPSec with 1 phase1 and 3 phase2 => start only one phase2.
On second instance: IPSec with 1 phase1 and 7 phase2 => start only three phase2.
After edit in some phase2 come up all phase2.
I did not find any patterns in the configs.
It does not depend on the order of entries.

For Example:

In first time log with only one phase2 of tree:

Nov 17 10:24:41 sense-secure charon: 10[CFG] rereading secrets
Nov 17 10:24:41 sense-secure charon: 10[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
Nov 17 10:24:41 sense-secure charon: 10[CFG] loaded IKE secret for XX.XX.XX.XX
Nov 17 10:24:41 sense-secure charon: 10[CFG] expanding file expression '/usr/local/etc/ipsec.secrets.opnsense.d/*.secrets' failed
Nov 17 10:24:41 sense-secure charon: 10[CFG] rereading ca certificates from '/usr/local/etc/ipsec.d/cacerts'
Nov 17 10:24:41 sense-secure charon: 10[CFG] rereading aa certificates from '/usr/local/etc/ipsec.d/aacerts'
Nov 17 10:24:41 sense-secure charon: 10[CFG] rereading ocsp signer certificates from '/usr/local/etc/ipsec.d/ocspcerts'
Nov 17 10:24:41 sense-secure charon: 10[CFG] rereading attribute certificates from '/usr/local/etc/ipsec.d/acerts'
Nov 17 10:24:41 sense-secure charon: 10[CFG] rereading crls from '/usr/local/etc/ipsec.d/crls'
Nov 17 10:24:41 sense-secure charon: 15[CFG] received stroke: delete connection 'con1-000'
Nov 17 10:24:41 sense-secure charon: 15[CFG] deleted connection 'con1-000'
Nov 17 10:24:41 sense-secure charon: 15[CFG] received stroke: delete connection 'con1-001'
Nov 17 10:24:41 sense-secure charon: 15[CFG] deleted connection 'con1-001'
Nov 17 10:24:41 sense-secure charon: 15[CFG] received stroke: delete connection 'con1-002'
Nov 17 10:24:41 sense-secure charon: 15[CFG] deleted connection 'con1-002'
Nov 17 10:24:41 sense-secure charon: 10[CFG] received stroke: add connection 'con1-000'
Nov 17 10:24:41 sense-secure charon: 10[CFG] added configuration 'con1-000'
Nov 17 10:24:41 sense-secure charon: 15[CFG] received stroke: initiate 'con1-000'
Nov 17 10:24:41 sense-secure charon: 15[ENC] <con1-000|253> generating QUICK_MODE request 576809996 [ HASH SA No KE ID ID ]
Nov 17 10:24:41 sense-secure charon: 15[NET] <con1-000|253> sending packet: from YY.YY.YY.YY[4500] to XX.XX.XX.XX[4500] (348 bytes)
Nov 17 10:24:41 sense-secure charon: 10[CFG] received stroke: add connection 'con1-001'
Nov 17 10:24:41 sense-secure charon: 10[CFG] added child to existing configuration 'con1-000'
Nov 17 10:24:41 sense-secure charon: 10[CFG] received stroke: initiate 'con1-001'

After edit log with all tree phase2:

Nov 17 10:24:45 sense-secure charon: 10[CFG] rereading secrets
Nov 17 10:24:45 sense-secure charon: 10[CFG] loading secrets from '/usr/local/etc/ipsec.secrets'
Nov 17 10:24:45 sense-secure charon: 10[CFG] loaded IKE secret for XX.XX.XX.XX
Nov 17 10:24:45 sense-secure charon: 10[CFG] expanding file expression '/usr/local/etc/ipsec.secrets.opnsense.d/*.secrets' failed
Nov 17 10:24:45 sense-secure charon: 10[CFG] rereading ca certificates from '/usr/local/etc/ipsec.d/cacerts'
Nov 17 10:24:45 sense-secure charon: 10[CFG] rereading aa certificates from '/usr/local/etc/ipsec.d/aacerts'
Nov 17 10:24:45 sense-secure charon: 10[CFG] rereading ocsp signer certificates from '/usr/local/etc/ipsec.d/ocspcerts'
Nov 17 10:24:45 sense-secure charon: 10[CFG] rereading attribute certificates from '/usr/local/etc/ipsec.d/acerts'
Nov 17 10:24:45 sense-secure charon: 10[CFG] rereading crls from '/usr/local/etc/ipsec.d/crls'
Nov 17 10:24:45 sense-secure charon: 16[CFG] received stroke: delete connection 'con1-000'
Nov 17 10:24:45 sense-secure charon: 16[CFG] deleted connection 'con1-000'
Nov 17 10:24:45 sense-secure charon: 10[CFG] received stroke: delete connection 'con1-001'
Nov 17 10:24:45 sense-secure charon: 10[CFG] deleted connection 'con1-001'
Nov 17 10:24:45 sense-secure charon: 16[CFG] received stroke: add connection 'con1-000'
Nov 17 10:24:45 sense-secure charon: 16[CFG] added configuration 'con1-000'
Nov 17 10:24:45 sense-secure charon: 16[CFG] received stroke: initiate 'con1-000'
Nov 17 10:24:45 sense-secure charon: 16[ENC] <con1-000|253> generating QUICK_MODE request 201826997 [ HASH SA No KE ID ID ]
Nov 17 10:24:45 sense-secure charon: 16[NET] <con1-000|253> sending packet: from YY.YY.YY.YY[4500] to XX.XX.XX.XX[4500] (348 bytes)
Nov 17 10:24:45 sense-secure charon: 13[CFG] received stroke: add connection 'con1-001'
Nov 17 10:24:45 sense-secure charon: 13[CFG] added child to existing configuration 'con1-000'
Nov 17 10:24:45 sense-secure charon: 12[CFG] received stroke: initiate 'con1-001'
Nov 17 10:24:45 sense-secure charon: 13[CFG] received stroke: add connection 'con1-002'
Nov 17 10:24:45 sense-secure charon: 13[CFG] added child to existing configuration 'con1-000'
Nov 17 10:24:45 sense-secure charon: 13[CFG] received stroke: initiate 'con1-002'

Can you tell me:
Where to look?
What can be done?

P.S: It seems as if there are not even attempts to initiate the second phases.

fichtner added the support Community support label Jul 18, 2019

mimugmail referenced this issue Jul 21, 2019

ipsec: ok to drop ipsec include from services

6449801

Add a little plugin glue to two tainted spots.

AdSchellevis self-assigned this Jul 22, 2019

AdSchellevis added bug Production bug and removed support Community support labels Jul 22, 2019

fichtner added this to the 20.1 milestone Jul 22, 2019

AdSchellevis closed this as completed in 64858b5 Jul 22, 2019

fichtner pushed a commit that referenced this issue Jul 23, 2019

IPsec, ditch globals from legacy include causes strange behaviour on …

96cb8d4

…bootup, closes #3582 (cherry picked from commit 64858b5)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

After 19.7 upgrade some IPSEC tunnel only came up after edit/apply #3582

After 19.7 upgrade some IPSEC tunnel only came up after edit/apply #3582

mimugmail commented Jul 18, 2019 •

edited

Loading

fichtner commented Jul 18, 2019

fichtner commented Jul 18, 2019

mimugmail commented Jul 18, 2019

fichtner commented Jul 18, 2019

mimugmail commented Jul 18, 2019

mimugmail commented Jul 18, 2019

fichtner commented Jul 18, 2019

mimugmail commented Jul 18, 2019

fichtner commented Jul 18, 2019

mimugmail commented Jul 19, 2019

AdSchellevis commented Jul 21, 2019

mimugmail commented Jul 22, 2019

AdSchellevis commented Jul 22, 2019

AdSchellevis commented Jul 22, 2019

mimugmail commented Jul 22, 2019

fichtner commented Jul 22, 2019

hboetes commented Jul 22, 2019

AdSchellevis commented Jul 23, 2019

hboetes commented Jul 23, 2019

AdSchellevis commented Jul 23, 2019

MrChrH commented Jul 24, 2019

MindVersal commented Nov 17, 2019

After 19.7 upgrade some IPSEC tunnel only came up after edit/apply #3582

After 19.7 upgrade some IPSEC tunnel only came up after edit/apply #3582

Comments

mimugmail commented Jul 18, 2019 • edited Loading

fichtner commented Jul 18, 2019

fichtner commented Jul 18, 2019

mimugmail commented Jul 18, 2019

fichtner commented Jul 18, 2019

mimugmail commented Jul 18, 2019

mimugmail commented Jul 18, 2019

fichtner commented Jul 18, 2019

mimugmail commented Jul 18, 2019

fichtner commented Jul 18, 2019

mimugmail commented Jul 19, 2019

AdSchellevis commented Jul 21, 2019

mimugmail commented Jul 22, 2019

AdSchellevis commented Jul 22, 2019

AdSchellevis commented Jul 22, 2019

mimugmail commented Jul 22, 2019

fichtner commented Jul 22, 2019

hboetes commented Jul 22, 2019

AdSchellevis commented Jul 23, 2019

hboetes commented Jul 23, 2019

AdSchellevis commented Jul 23, 2019

MrChrH commented Jul 24, 2019

MindVersal commented Nov 17, 2019

mimugmail commented Jul 18, 2019 •

edited

Loading