IPSEC continuing problems

kitdavis · Dec 30, 2014, 4:05 PM

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>

eri-- · Dec 30, 2014, 8:48 PM

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

kitdavis · Dec 30, 2014, 9:47 PM

<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>

<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>

cmb · Dec 31, 2014, 12:28 AM

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?

kitdavis · Dec 31, 2014, 3:00 AM

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.

cmb · Dec 31, 2014, 3:57 AM

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.

cmb · Jan 7, 2015, 11:31 PM

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.

cmb · Jan 8, 2015, 2:39 AM

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.