[strongSwan] Windows 7 to strongswan 4.4.1

[Matthew Twomey]

Greetings all,

I hoping for some hints (or some closure if this is just not going to 
work). I'm using the native Windows 7 remote-access vpn client to connect 
to an instance of strongswan v4.4.1 (this is part of a Vyatta appliance). 
Despite the fact that it's part of the appliance, I'm willing and able to 
manually edit the strongswan config settings outside the vyatta shell. My 
goal is to end up with a connection that functions and stays up 
essentially all day *without* and special changes on the Windows side 
(outside the VPN setup wizard). I can do basically whatever is needed on 
the strongswan side (other than upgrade the version - as it's tied to 
the Vyatta version which is already the latest).

The L2TP/IPSEC VPN itself comes up and functions fine, but always dies 
during quick mode re-keying. It's an IKE1 VPN and Windows appears to have 
an ESP lifetime of 60 minutes (with no option to change that). The 
strongswan side is set not to re-key and once the SA expires, the Windows 
side tries to re-negotiate it - but this fails. I'm fairly new to 
strongswan, so I'm not entirely sure how to troubleshoot this.

Any ideas would be greatly appreciated (or if this is known to be an 
unresolved problem with these software versions, I'd like to know that as 
well).

Thanks for your help!

Here's what I'm seeing in the logs:

##### Initial Main/Quick Mode Negotiation #####
Oct 18 10:37:45 vyatta pluto[3656]: packet from 172.118.235.17:13: 
received Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Oct 18 10:37:45 vyatta pluto[3656]: packet from 172.118.235.17:13: 
received Vendor ID payload [RFC 3947]
Oct 18 10:37:45 vyatta pluto[3656]: packet from 172.118.235.17:13: 
ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Oct 18 10:37:45 vyatta pluto[3656]: packet from 172.118.235.17:13: 
ignoring Vendor ID payload [FRAGMENTATION]
Oct 18 10:37:45 vyatta pluto[3656]: packet from 172.118.235.17:13: 
ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
Oct 18 10:37:45 vyatta pluto[3656]: packet from 172.118.235.17:13: 
ignoring Vendor ID payload [Vid-Initial-Contact]
Oct 18 10:37:45 vyatta pluto[3656]: packet from 172.118.235.17:13: 
ignoring Vendor ID payload [IKE CGA version 1]
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[5] 
172.118.235.17:13 #3: responding to Main Mode from unknown peer 
172.118.235.17:13
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[5] 
172.118.235.17:13 #3: Oakley Transform [AES_CBC (256), HMAC_SHA1, ECP_384] 
refused due to strict flag
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[5] 
172.118.235.17:13 #3: Oakley Transform [AES_CBC (128), HMAC_SHA1, ECP_256] 
refused due to strict flag
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[5] 
172.118.235.17:13 #3: Oakley Transform [AES_CBC (256), HMAC_SHA1, 
MODP_2048] refused due to strict flag
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[5] 
172.118.235.17:13 #3: Oakley Transform [3DES_CBC (192), HMAC_SHA1, 
MODP_2048] refused due to strict flag
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[5] 
172.118.235.17:13 #3: NAT-Traversal: Result using RFC 3947: peer is NATed
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[5] 
172.118.235.17:13 #3: Peer ID is ID_IPV4_ADDR: '179.28.228.125'
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[6] 
172.118.235.17:13 #3: deleting connection "remote-access-mac-zzz" instance 
with peer 172.118.235.17 {isakmp=#0/ipsec=#0}
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[6] 
172.118.235.17:1093 #3: sent MR3, ISAKMP SA established
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[6] 
172.118.235.17:1093 #4: NAT-Traversal: received 2 NAT-OA. using first, 
ignoring others
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[6] 
172.118.235.17:1093 #4: IPSec Transform [AES_CBC (128), HMAC_SHA1] refused 
due to strict flag
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[6] 
172.118.235.17:1093 #4: responding to Quick Mode
Oct 18 10:37:45 vyatta pluto[3656]: "remote-access-mac-zzz"[6] 
172.118.235.17:1093 #4: IPsec SA established {ESP=>0xcb18e8ed <0xe9f6e978 
NATOA=179.28.228.125}

##### Subsequent re-keying effort (which fails 60 minutes later) #####
Oct 18 12:37:05 vyatta pluto[3656]: "remote-access-mac-zzz"[10] 
172.118.235.17:1093 #8: NAT-Traversal: received 2 NAT-OA. using first, 
ignoring others
Oct 18 12:37:05 vyatta pluto[3656]: "remote-access-mac-zzz"[10] 
172.118.235.17:1093 #8: IPSec Transform [AES_CBC (128), HMAC_SHA1] refused 
due to strict flag
Oct 18 12:37:05 vyatta pluto[3656]: "remote-access-mac-zzz"[10] 
172.118.235.17:1093 #8: responding to Quick Mode
Oct 18 12:37:05 vyatta pluto[3656]: "remote-access-mac-zzz"[10] 
172.118.235.17:1093 #8: cannot install eroute -- it is in use for 
"remote-access-mac-zzz"[9] 172.118.235.17:1093 #7
Oct 18 12:37:05 vyatta pluto[3656]: "remote-access-mac-zzz"[10] 
172.118.235.17:1093: deleting connection "remote-access-mac-zzz" instance 
with peer 172.118.235.17 {isakmp=#0/ipsec=#0}
Oct 18 12:37:06 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: Quick Mode I1 message is unacceptable because it 
uses a previously used Message ID 0x02000000 (perhaps this is a duplicated 
packet)
Oct 18 12:37:06 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: sending encrypted notification INVALID_MESSAGE_ID 
to 172.118.235.17:1093
Oct 18 12:37:09 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: Quick Mode I1 message is unacceptable because it 
uses a previously used Message ID 0x02000000 (perhaps this is a duplicated 
packet)
Oct 18 12:37:09 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: sending encrypted notification INVALID_MESSAGE_ID 
to 172.118.235.17:1093
Oct 18 12:37:13 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: Quick Mode I1 message is unacceptable because it 
uses a previously used Message ID 0x02000000 (perhaps this is a duplicated 
packet)
Oct 18 12:37:13 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: sending encrypted notification INVALID_MESSAGE_ID 
to 172.118.235.17:1093
Oct 18 12:37:22 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: Quick Mode I1 message is unacceptable because it 
uses a previously used Message ID 0x02000000 (perhaps this is a duplicated 
packet)
Oct 18 12:37:22 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: sending encrypted notification INVALID_MESSAGE_ID 
to 172.118.235.17:1093
Oct 18 12:37:37 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #7: IPsec SA expired (--dontrekey)
Oct 18 12:37:39 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: Quick Mode I1 message is unacceptable because it 
uses a previously used Message ID 0x02000000 (perhaps this is a duplicated 
packet)
Oct 18 12:37:39 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: sending encrypted notification INVALID_MESSAGE_ID 
to 172.118.235.17:1093
Oct 18 12:37:53 vyatta xl2tpd[1054]: Maximum retries exceeded for tunnel 
47191.  Closing.
Oct 18 12:37:55 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: Quick Mode I1 message is unacceptable because it 
uses a previously used Message ID 0x02000000 (perhaps this is a duplicated 
packet)
Oct 18 12:37:55 vyatta pluto[3656]: "remote-access-mac-zzz"[9] 
172.118.235.17:1093 #6: sending encrypted notification INVALID_MESSAGE_ID 
to 172.118.235.17:1093