[strongSwan] Windows 7 to strongswan 4.4.1

Wed Oct 31 16:22:56 CET 2012

Anyone have this working and stable (several hours stable)?

On Thu, 18 Oct 2012, Matthew Twomey wrote:

> 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
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
>