Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    IPSEC continuing problems

    2.2 Snapshot Feedback and Problems - RETIRED
    3
    8
    10.1k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • K
      kitdavis
      last edited by

      I updated to the 12/30 build this morning.  The widget problem seems to be solved as it now properly indicates the correct number of tunnels.  However, I continue to have problems with two tunnels.

      diag_IPSEC will show both tunnels as being up.  The Phase 2 entries will show 0 bytes transferred.  After 5 or so minutes the tunnel will change to connecting and re-establish itself with the same results.

      In the 2.2 log I see the following:  (in descending order)

      Dec 30 10:45:26 charon: 12[NET] sending packet: from 69.69.69.69[500] to 142.142.142.142[500] (420 bytes)
      Dec 30 10:45:26 charon: 12[IKE] sending retransmit 2 of response message ID 0, seq 1
      Dec 30 10:45:26 charon: 12[IKE] <con18000|9>sending retransmit 2 of response message ID 0, seq 1
      Dec 30 10:45:19 charon: 12[NET] sending packet: from 69.69.69.69[500] to 142.142.142.142[500] (420 bytes)
      Dec 30 10:45:19 charon: 12[IKE] sending retransmit 1 of response message ID 0, seq 1
      Dec 30 10:45:19 charon: 12[IKE] <con18000|9>sending retransmit 1 of response message ID 0, seq 1
      Dec 30 10:45:18 charon: 12[NET] sending packet: from 69.69.69.69[500] to 202.202.202.202[500] (84 bytes)
      Dec 30 10:45:18 charon: 12[ENC] generating INFORMATIONAL_V1 request 350422203 [ HASH N(DPD_ACK) ]
      Dec 30 10:45:18 charon: 12[ENC] parsed INFORMATIONAL_V1 request 3473928048 [ HASH N(DPD) ]
      Dec 30 10:45:18 charon: 12[NET] received packet: from 202.202.202.202[500] to 69.69.69.69[500] (84 bytes)
      Dec 30 10:45:15 charon: 12[NET] sending packet: from 69.69.69.69[500] to 142.142.142.142[500] (420 bytes)
      Dec 30 10:45:15 charon: 12[ENC] generating AGGRESSIVE response 0 [ SA KE No ID NAT-D NAT-D HASH V V V V V ]
      Dec 30 10:45:15 charon: 12[CFG] selected peer config "con18000"
      Dec 30 10:45:15 charon: 12[CFG] looking for pre-shared key peer configs matching 69.69.69.69…142.142.142.142[142.142.142.142]
      Dec 30 10:45:15 charon: 12[IKE] 142.142.142.142 is initiating a Aggressive Mode IKE_SA
      Dec 30 10:45:15 charon: 12[IKE] <9> 142.142.142.142 is initiating a Aggressive Mode IKE_SA
      Dec 30 10:45:15 charon: 12[IKE] received DPD vendor ID
      Dec 30 10:45:15 charon: 12[IKE] <9> received DPD vendor ID
      Dec 30 10:45:15 charon: 12[IKE] received draft-ietf-ipsec-nat-t-ike-00 vendor ID
      Dec 30 10:45:15 charon: 12[IKE] <9> received draft-ietf-ipsec-nat-t-ike-00 vendor ID
      Dec 30 10:45:15 charon: 12[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
      Dec 30 10:45:15 charon: 12[IKE] <9> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
      Dec 30 10:45:15 charon: 12[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
      Dec 30 10:45:15 charon: 12[IKE] <9> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
      Dec 30 10:45:15 charon: 12[IKE] received NAT-T (RFC 3947) vendor ID
      Dec 30 10:45:15 charon: 12[IKE] <9> received NAT-T (RFC 3947) vendor ID
      Dec 30 10:45:15 charon: 12[IKE] received FRAGMENTATION vendor ID
      Dec 30 10:45:15 charon: 12[IKE] <9> received FRAGMENTATION vendor ID
      Dec 30 10:45:15 charon: 12[ENC] parsed AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
      Dec 30 10:45:15 charon: 12[NET] received packet: from 142.142.142.142[500] to 69.69.69.69[500] (372 bytes)
      Dec 30 10:45:08 charon: 12[NET] sending packet: from 69.69.69.69[500] to 202.202.202.202[500] (84 bytes)
      Dec 30 10:45:08 charon: 12[ENC] generating INFORMATIONAL_V1 request 1463459452 [ HASH N(DPD_ACK) ]
      Dec 30 10:45:08 charon: 12[ENC] parsed INFORMATIONAL_V1 request 2905154611 [ HASH N(DPD) ]
      Dec 30 10:45:08 charon: 12[NET] received packet: from 202.202.202.202[500] to 69.69.69.69[500] (84 bytes)
      Dec 30 10:45:05 charon: 08[JOB] deleting half open IKE_SA after timeout
      Dec 30 10:45:05 charon: 08[NET] sending packet: from 69.69.69.69[500] to 142.142.142.142[500] (420 bytes)
      Dec 30 10:45:05 charon: 08[IKE] received retransmit of request with ID 0, retransmitting response
      Dec 30 10:45:05 charon: 08[IKE] <con18000|8>received retransmit of request with ID 0, retransmitting response
      Dec 30 10:45:05 charon: 08[NET] received packet: from 142.142.142.142[500] to 69.69.69.69[500] (372 bytes)
      Dec 30 10:44:59 charon: 08[NET] sending packet: from 69.69.69.69[500] to 142.142.142.142[500] (420 bytes)
      Dec 30 10:44:59 charon: 08[IKE] sending retransmit 3 of response message ID 0, seq 1
      Dec 30 10:44:59 charon: 08[IKE] <con18000|8>sending retransmit 3 of response message ID 0, seq 1
      Dec 30 10:44:58 charon: 08[NET] sending packet: from 69.69.69.69[500] to 202.202.202.202[500] (84 bytes)
      Dec 30 10:44:58 charon: 08[ENC] generating INFORMATIONAL_V1 request 629716908 [ HASH N(DPD_ACK) ]
      Dec 30 10:44:58 charon: 08[ENC] parsed INFORMATIONAL_V1 request 3681128156 [ HASH N(DPD) ]
      Dec 30 10:44:58 charon: 08[NET] received packet: from 202.202.202.202[500] to 69.69.69.69[500] (84 bytes)
      Dec 30 10:44:55 charon: 08[NET] sending packet: from 69.69.69.69[500] to 142.142.142.142[500] (420 bytes)
      Dec 30 10:44:55 charon: 08[IKE] received retransmit of request with ID 0, retransmitting response
      Dec 30 10:44:55  charon: 08[IKE] <con18000|8>received retransmit of request with ID 0, retransmitting response
      Dec 30 10:44:55 charon: 08[NET] received packet: from 142.142.142.142[500] to 69.69.69.69[500] (372 bytes)

      At the remote end (version 2.12) I see the following: (in descending order)

      Dec 30 10:18:01 racoon: [yyyy cccc]: [69.69.69.69] ERROR: ignore the packet, received unexpecting payload type 20.
      Dec 30 10:17:59 racoon: [yyyy cccc]: [69.69.69.69] ERROR: notification PAYLOAD-MALFORMED received in informational exchange.
      Dec 30 10:17:59 racoon: NOTIFY: the packet is retransmitted by 69.69.69.69[500] (1).
      Dec 30 10:17:58 racoon: [yyyy cccc]: [69.69.69.69] ERROR: notification PAYLOAD-MALFORMED received in informational exchange.
      Dec 30 10:17:58 racoon: [yyyy cccc]: [69.69.69.69] ERROR: notification INVALID-HASH-INFORMATION received in informational exchange.
      Dec 30 10:17:58 racoon: [yyyy cccc]: [69.69.69.69] ERROR: notification INVALID-HASH-INFORMATION received in informational exchange.
      Dec 30 10:17:58 racoon: [yyyy cccc]: [69.69.69.69] ERROR: notification INVALID-HASH-INFORMATION received in informational exchange.
      Dec 30 10:17:52 racoon: [yyyy cccc]: [69.69.69.69] ERROR: notification PAYLOAD-MALFORMED received in informational exchange.
      Dec 30 10:17:52 racoon: NOTIFY: the packet is retransmitted by 69.69.69.69[500] (1).
      Dec 30 10:17:51 racoon: [yyyy cccc]: [69.69.69.69] ERROR: ignore the packet, received unexpecting payload type 20.
      Dec 30 10:17:49 racoon: [yyyy cccc]: [69.69.69.69] ERROR: notification PAYLOAD-MALFORMED received in informational exchange.
      Dec 30 10:17:49 racoon: [yyyy cccc]: [69.69.69.69] ERROR: notification INVALID-HASH-INFORMATION received in informational exchange.
      Dec 30 10:17:48 racoon: [yyyy cccc]: [69.69.69.69] ERROR: notification INVALID-HASH-INFORMATION received in informational exchange.
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3293472760(0xc44e67f8)
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=88017306(0x53f099a)
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: initiate new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3221989195(0xc00ba74b)
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=197045188(0xbbeabc4)
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3486455108(0xcfcf1544)
      Dec 30 10:17:48 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=232669937(0xdde42f1)
      Dec 30 10:17:47 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
      Dec 30 10:17:47 racoon: [yyyy cccc]: INFO: ISAKMP-SA established 142.142.142.142[500]-69.69.69.69[500] spi:28bc51005b1a7f8a:47e34a41f0a1f7de
      Dec 30 10:17:47 racoon: INFO: NAT not detected
      Dec 30 10:17:47 racoon: INFO: NAT-D payload #1 verified
      Dec 30 10:17:47 racoon: [yyyy cccc]: [69.69.69.69] INFO: Hashing 69.69.69.69[500] with algo #1
      Dec 30 10:17:47 racoon: INFO: NAT-D payload #0 verified
      Dec 30 10:17:47 racoon: [Self]: [142.142.142.142] INFO: Hashing 142.142.142.142[500] with algo #1
      Dec 30 10:17:47 racoon: INFO: Adding xauth VID payload.
      Dec 30 10:17:47 racoon: [Self]: [142.142.142.142] INFO: Hashing 142.142.142.142[500] with algo #1
      Dec 30 10:17:47 racoon: [yyyy cccc]: [69.69.69.69] INFO: Hashing 69.69.69.69[500] with algo #1

      These tunnels (along with 16 others) were working in 2.15.</con18000|8></con18000|8></con18000|8></con18000|9></con18000|9>

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        What kind of id you have configured in these ipsec tunnels?

        1 Reply Last reply Reply Quote 0
        • K
          kitdavis
          last edited by

          <phase1><ikeid>17</ikeid>
          <iketype>ikev1</iketype>
          <mode>aggressive</mode>
          <interface>opt1</interface>
          <remote-gateway>142.142.142.142</remote-gateway>
          <protocol>inet</protocol>
          <myid_type>myaddress</myid_type>
          <myid_data><peerid_type>peeraddress</peerid_type>
          <peerid_data><encryption-algorithm><name>blowfish</name>
          <keylen>192</keylen></encryption-algorithm>
          <hash-algorithm>md5</hash-algorithm>
          <dhgroup>2</dhgroup>
          <lifetime>28800</lifetime>
          <pre-shared-key>xxxxxxxxx</pre-shared-key>
          <private-key><certref><caref><authentication_method>pre_shared_key</authentication_method>

          <nat_traversal>on</nat_traversal>
          <dpd_delay>10</dpd_delay>
          <dpd_maxfail>5</dpd_maxfail></caref></certref></private-key></peerid_data></myid_data></phase1>

          <phase2><ikeid>17</ikeid>
          <mode>tunnel</mode>
          <localid><type>lan</type></localid>
          <remoteid><type>network</type>

          <address>10.20.12.0</address>

          <netbits>24</netbits></remoteid>
          <protocol>esp</protocol>
          <encryption-algorithm-option><name>blowfish</name>
          <keylen>auto</keylen></encryption-algorithm-option>
          <hash-algorithm-option>hmac_md5</hash-algorithm-option>
          <pfsgroup>2</pfsgroup>
          <lifetime>3600</lifetime>
          <pinghost><uniqid>548e46e1af577</uniqid></pinghost></phase2>

          1 Reply Last reply Reply Quote 0
          • C
            cmb
            last edited by

            That actually looks like a racoon bug (issue on 2.1x side) with NAT-D and aggressive mode. If you change it to main mode on both sides does it work?

            1 Reply Last reply Reply Quote 0
            • K
              kitdavis
              last edited by

              I changed both ends of the tunnel to "main" but a working tunnel was not established  (as others have noted, changing the tunnel configuration does not result in a successful renegotiation - in the end, I had to restart the 2.2 pfsense box to release the original tunnel)

              On the 1.2 (raccoon side) I see multiple phase 2 negotiations:

              Dec 30 22:23:24 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3411633883(0xcb5966db)
              Dec 30 22:23:24 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=93339955(0x5904133)
              Dec 30 22:23:24 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:23 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3335216559(0xc6cb5daf)
              Dec 30 22:23:23 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=61373898(0x3a87dca)
              Dec 30 22:23:23 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:23 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3485046344(0xcfb99648)
              Dec 30 22:23:23 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=198651587(0xbd72ec3)
              Dec 30 22:23:23 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:21 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3422655217(0xcc0192f1)
              Dec 30 22:23:21 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=105474991(0x6496baf)
              Dec 30 22:23:21 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:20 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3487097296(0xcfd8e1d0)
              Dec 30 22:23:20 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=186848261(0xb231405)
              Dec 30 22:23:20 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:19 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3444047929(0xcd480039)
              Dec 30 22:23:19 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=192144215(0xb73e357)
              Dec 30 22:23:19 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:19 racoon: ERROR: pfkey DELETE received: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3418525878(0xcbc290b6)
              Dec 30 22:23:19 racoon: ERROR: pfkey DELETE received: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3326234401(0xc6424f21)
              Dec 30 22:23:15 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3318714014(0xc5cf8e9e)
              Dec 30 22:23:15 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=260856016(0xf8c58d0)
              Dec 30 22:23:15 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:13 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3326234401(0xc6424f21)
              Dec 30 22:23:13 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=70570084(0x434d064)
              Dec 30 22:23:13 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:13 racoon: ERROR: pfkey DELETE received: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3417752125(0xcbb6c23d)
              Dec 30 22:23:13 racoon: ERROR: pfkey DELETE received: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3411931567(0xcb5df1af)
              Dec 30 22:23:11 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3418525878(0xcbc290b6)
              Dec 30 22:23:11 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=144710911(0x8a01cff)
              Dec 30 22:23:11 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:10 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3411931567(0xcb5df1af)
              Dec 30 22:23:10 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=188944880(0xb4311f0)
              Dec 30 22:23:10 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:10 racoon: ERROR: pfkey DELETE received: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3310734809(0xc555cdd9)
              Dec 30 22:23:10 racoon: ERROR: pfkey DELETE received: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3403439561(0xcadc5dc9)
              Dec 30 22:23:10 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3417752125(0xcbb6c23d)
              Dec 30 22:23:10 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=241694002(0xe67f532)
              Dec 30 22:23:10 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:23:09 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3403439561(0xcadc5dc9)
              Dec 30 22:23:09 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=113044949(0x6bcedd5)
              Dec 30 22:23:09 racoon: [yyyy cccc]: INFO: respond new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:22:56 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=3310734809(0xc555cdd9)
              Dec 30 22:22:56 racoon: [yyyy cccc]: INFO: IPsec-SA established: ESP 142.142.142.142[500]->69.69.69.69[500] spi=221561054(0xd34c0de)
              Dec 30 22:22:56 racoon: WARNING: attribute has been modified.
              Dec 30 22:22:56 racoon: [yyyy cccc]: INFO: initiate new phase 2 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:22:56 racoon: [yyyy cccc]: INFO: ISAKMP-SA established 142.142.142.142[500]-69.69.69.69[500] spi:3b0339eb9eb6ef18:26bb94a5d180fb74
              Dec 30 22:22:55 racoon: INFO: NAT not detected
              Dec 30 22:22:55 racoon: INFO: NAT-D payload #1 verified
              Dec 30 22:22:55 racoon: [yyyy cccc]: [69.69.69.69] INFO: Hashing 69.69.69.69[500] with algo #1
              Dec 30 22:22:55 racoon: INFO: NAT-D payload #0 verified
              Dec 30 22:22:55 racoon: [Self]: [142.142.142.142] INFO: Hashing 142.142.142.142[500] with algo #1
              Dec 30 22:22:55 racoon: INFO: Adding remote and local NAT-D payloads.
              Dec 30 22:22:55 racoon: [Self]: [142.142.142.142] INFO: Hashing 142.142.142.142[500] with algo #1
              Dec 30 22:22:55 racoon: [yyyy cccc]: [69.69.69.69] INFO: Hashing 69.69.69.69[500] with algo #1
              Dec 30 22:22:55 racoon: [yyyy cccc]: [69.69.69.69] INFO: Selected NAT-T version: RFC 3947
              Dec 30 22:22:55 racoon: INFO: received Vendor ID: RFC 3947
              Dec 30 22:22:55 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
              Dec 30 22:22:55 racoon: INFO: received Vendor ID: CISCO-UNITY
              Dec 30 22:22:55 racoon: INFO: received Vendor ID: DPD
              Dec 30 22:22:55 racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
              Dec 30 22:22:55 racoon: INFO: begin Identity Protection mode.
              Dec 30 22:22:55 racoon: [yyyy cccc]: INFO: initiate new phase 1 negotiation: 142.142.142.142[500]<=>69.69.69.69[500]
              Dec 30 22:22:55 racoon: [yyyy cccc]: INFO: IPsec-SA request for 69.69.69.69 queued due to no phase1 found.

              On the 2.2 side, I see no less than 111 phase 2 entries created for this tunnel  (see screen shots)  all showing 0 bytes out.

              miniview.png
              miniview.png_thumb
              view2.png
              view2.png_thumb

              1 Reply Last reply Reply Quote 0
              • C
                cmb
                last edited by

                Must be something else in that case, unless that somehow affects main mode as well. Once strongswan has negotiated a connection successfully, it hangs onto that until you manually clear it (hit X under Status>IPsec) or it expires, that much is the expected behavior (if IMO not ideal, something we'll look into changing later). Reboot isn't necessary that I've seen.

                That a system you could get me access to? If so, PM me and we can work out the details.

                1 Reply Last reply Reply Quote 0
                • C
                  cmb
                  last edited by

                  This is the issue on your system.
                  https://redmine.pfsense.org/issues/4188

                  yours has a workaround in place on it at the moment that's making the affected connection work. Should have a proper fix for that in place and in snapshots tomorrow.

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    I upgraded your system to the version with that fix in place, overwriting the workaround that was in place previously, and it still looks good. Pretty sure this one's knocked out, and it probably caused some others' weird, hard to debug issues.

                    1 Reply Last reply Reply Quote 0
                    • First post
                      Last post