[strongSwan] VPN works with only 1 remote client. second client logs in and disconnects the first.

[Lawrence Chiu]

Hi Tobias,

Seems like one problem goes away and another one starts.  It seems the 
Ipad can't stay connected for a long time, whereas the Android can keep 
up the connection indefinitely.  The time seems to vary but within an 
hour, the Ipad drops the VPN connection.  Question is is this an iPad 
problem or a Strongswan problem?  The auth.log says:

Nov  6 10:19:56 vmware-u003 pluto[39196]: "ios"[15] 166.147.67.44:26014 
#23: IPsec SA established {ESP=>0x09283dd3 <0xc6f85c9b NATOA=0.0.0.0}
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: received Vendor ID payload [RFC 3947]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload 
[4df37928e9fc4fd1b3262170d515c662]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload 
[8f8d83826d246b6fc7a8a6a428c11de8]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload 
[439b59f8ba676c4c7737ae22eab8f582]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload 
[4d1e0e136deafa34c4f3ea9f02ec7285]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload 
[80d0bb3def54565ee84645d4c85ce3ee]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload 
[9909b64eed937c6573de52ace952fa6b]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload 
[draft-ietf-ipsec-nat-t-ike-03]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload 
[draft-ietf-ipsec-nat-t-ike-02]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload 
[draft-ietf-ipsec-nat-t-ike-02_n]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: received Vendor ID payload [XAUTH]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: ignoring Vendor ID payload [Cisco-Unity]
Nov  6 11:03:07 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: received Vendor ID payload [Dead Peer Detection]
Nov  6 11:03:07 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#24: responding to Main Mode from unknown peer 70.139.113.210:4500
Nov  6 11:03:08 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#24: NAT-Traversal: Result using RFC 3947: both are NATed
Nov  6 11:03:09 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#24: Peer ID is ID_DER_ASN1_DN: 'C=CH, O=strongSwan, 
CN=win7.mycompany.local'
Nov  6 11:03:09 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#24: crl not found
Nov  6 11:03:09 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#24: certificate status unknown
Nov  6 11:03:09 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#24: we have a cert and are sending it upon request
Nov  6 11:03:09 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#24: sent MR3, ISAKMP SA established
Nov  6 11:03:09 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#24: sending XAUTH request
Nov  6 11:03:14 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#20: received Delete SA payload: deleting ISAKMP State #20
Nov  6 11:04:19 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#24: max number of retransmissions (2) reached STATE_XAUTH_R1
Nov  6 11:10:38 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#25: initiating Main Mode
Nov  6 11:11:48 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#25: max number of retransmissions (2) reached STATE_MAIN_I1.  No 
response (or no acceptable response) to our first IKE message
Nov  6 11:11:48 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#25: starting keying attempt 2 of at most 3
Nov  6 11:11:48 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#26: initiating Main Mode to replace #25
Nov  6 11:12:58 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#26: max number of retransmissions (2) reached STATE_MAIN_I1.  No 
response (or no acceptable response) to our first IKE message
Nov  6 11:12:58 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#26: starting keying attempt 3 of at most 3
Nov  6 11:12:58 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#27: initiating Main Mode to replace #26
Nov  6 11:14:09 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#27: max number of retransmissions (2) reached STATE_MAIN_I1.  No 
response (or no acceptable response) to our first IKE message
Nov  6 11:15:08 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500 
#21: IPsec SA expired (LATEST!)
Nov  6 11:15:08 vmware-u003 pluto[39196]: "ios"[13] 70.139.113.210:4500: 
deleting connection "ios" instance with peer 70.139.113.210 
{isakmp=#0/ipsec=#0}
Nov  6 11:15:08 vmware-u003 pluto[39196]: lease 10.0.0.1 by 'vmware1' 
went offline
Nov  6 11:15:26 vmware-u003 pluto[39196]: "ios"[15] 166.147.67.44:26014 
#28: initiating Quick Mode ENCRYPT+TUNNEL+XAUTHRSASIG+XAUTHSERVER to 
replace #23 {using isakmp#22}
Nov  6 11:15:26 vmware-u003 pluto[39196]: "ios"[15] 166.147.67.44:26014 
#28: sent QI2, IPsec SA established {ESP=>0x032a8e6b <0xcd8c62f1 
NATOA=0.0.0.0}
Nov  6 11:18:10 vmware-u003 pluto[39196]: packet from 
70.139.113.210:4500: Informational Exchange is for an unknown (expired?) SA




On 11/6/2013 8:36 AM, Lawrence Chiu wrote:
> Thank you Tobias.  I could not use "uniqueids=no" because it was not 
> supported by my version of Strongswan (4.5.2).  But using a different 
> certificate on the Android client solved the problem.
>
> Regards,
> LawrenceC
>
> On 11/6/2013 4:17 AM, Tobias Brunner wrote:
>> Hi Lawrence,
>>
>> It's not the XAuth users but the certificate's DN that is equal and
>> causes the deletion of the previous SA:
>>
>>> Nov  5 12:16:19 vmware-u003 pluto[27166]: "ios"[3] 166.147.65.85:28107
>>> #3: Peer ID is ID_DER_ASN1_DN: 'C=CH, O=strongSwan, 
>>> CN=win7.mycompany.local'
>>> Nov  5 12:16:19 vmware-u003 pluto[27166]: "ios"[3] 166.147.65.85:28107
>>> #3: crl not found
>>> Nov  5 12:16:19 vmware-u003 pluto[27166]: "ios"[3] 166.147.65.85:28107
>>> #3: certificate status unknown
>>> Nov  5 12:16:19 vmware-u003 pluto[27166]: "ios"[4] 166.147.65.85:28107
>>> #3: deleting connection "ios" instance with peer 166.147.65.85
>>> {isakmp=#0/ipsec=#0}
>> If you don't want to use different certificates for each client, you
>> could try setting uniqueids=no in the "config setup" section in 
>> ipsec.conf.
>>
>> I don't know how pluto reacts to INITIAL_CONTACT notifies, but it could
>> be that it deletes previous SAs anyway if it receives such a notify,
>> despite the uniqueids=no setting.  If that's the case you'll have to use
>> different certificates (i.e. different DNs) or update to strongSwan
>> 5.0.1 or newer where charon supports the setting uniqueids=never, which
>> forces it to ignore INITIAL_CONTACT notifies.
>>
>> Regards,
>> Tobias
>>
>