Regular Member
Posts: 367
Registered: ‎05-09-2014
Kudos: 128
Solutions: 7

strongswan remote-access VPN - key renegotiation failing (looks like)

so i've got a semi-functional L2TP/IPSec remote-access VPN setup, using x509 certs. i can connect fine, and transfer data normally. until, after a random amount of time, the VPN link dies. there doesn't seem to be a pattern to it, and it seems to be time-related; i can transfer 100KB or many GB over the tunnel, but after what seems like ~10-15 minutes, i lose access. i am then unable to reconnect remotely; i have to restart the VPN, using "sudo /etc/init.d/ipsec restart". doing "restart vpn" isn't enough.

Jun 13 23:41:24 Gateway ipsec_starter[12781]: Starting strongSwan 4.5.2 IPsec [starter]...
Jun 13 23:41:24 Gateway pluto[12799]: Starting IKEv1 pluto daemon (strongSwan 4.5.2) THREADS SMARTCARD VENDORID CISCO_QUIRKS
Jun 13 23:41:24 Gateway ipsec_starter[12798]: pluto (12799) started after 20 ms
Jun 13 23:41:24 Gateway pluto[12799]:   including NAT-Traversal patch (Version 0.6c)
Jun 13 23:41:24 Gateway pluto[12799]: failed to load pkcs11 module '/usr/lib/opensc-pkcs11.so'
Jun 13 23:41:26 Gateway pluto[12799]:   loaded ca certificate from '/etc/ipsec.d/cacerts/ca.crt'
Jun 13 23:41:26 Gateway pluto[12799]: Changing to directory '/etc/ipsec.d/crls'
Jun 13 23:41:26 Gateway pluto[12799]: listening for IKE messages
Jun 13 23:41:26 Gateway pluto[12799]: adding interface eth2/eth2 10.172.172.1:500
Jun 13 23:41:26 Gateway pluto[12799]: adding interface eth2/eth2 10.172.172.1:4500
Jun 13 23:41:26 Gateway pluto[12799]: adding interface eth1/eth1 172.16.16.1:500
Jun 13 23:41:26 Gateway pluto[12799]: adding interface eth1/eth1 172.16.16.1:4500
Jun 13 23:41:26 Gateway pluto[12799]: adding interface eth0/eth0 GATEWAY_IP:500
Jun 13 23:41:26 Gateway pluto[12799]: adding interface eth0/eth0 GATEWAY_IP:4500
Jun 13 23:41:26 Gateway pluto[12799]: adding interface lo/lo 127.0.0.1:500
Jun 13 23:41:26 Gateway pluto[12799]: adding interface lo/lo 127.0.0.1:4500
Jun 13 23:41:26 Gateway pluto[12799]: adding interface eth1/eth1 IPv6ADDR:500
Jun 13 23:41:26 Gateway pluto[12799]: adding interface lo/lo ::1:500
Jun 13 23:41:26 Gateway pluto[12799]: loading secrets from "/etc/ipsec.secrets"
Jun 13 23:41:26 Gateway pluto[12799]:   loaded private key from '/etc/ipsec.d/private/Gateway.key'
Jun 13 23:41:26 Gateway pluto[12799]:   loaded host certificate from '/etc/ipsec.d/certs/Gateway.crt'
Jun 13 23:41:26 Gateway pluto[12799]:   id '%any' not confirmed by certificate, defaulting to 'C=US, ST=TN, L=CITY, O=ORG, CN=Gateway, E=EMAILADDR'
Jun 13 23:41:26 Gateway pluto[12799]: added connection description "remote-access-win-aaa"
Jun 13 23:41:26 Gateway pluto[12799]:   loaded host certificate from '/etc/ipsec.d/certs/Gateway.crt'
Jun 13 23:41:26 Gateway pluto[12799]:   id '%any' not confirmed by certificate, defaulting to 'C=US, ST=TN, L=CITY, O=ORG, CN=Gateway, E=EMAILADDR'
Jun 13 23:41:26 Gateway pluto[12799]: added connection description "remote-access-mac-zzz"
Jun 13 23:41:26 Gateway pluto[12799]: the protocol must be the same for leftport and rightport
Jun 13 23:46:37 Gateway pluto[12799]: packet from REMOTE_IP:500: received Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000008]
Jun 13 23:46:37 Gateway pluto[12799]: packet from REMOTE_IP:500: received Vendor ID payload [RFC 3947]
Jun 13 23:46:37 Gateway pluto[12799]: packet from REMOTE_IP:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
Jun 13 23:46:37 Gateway pluto[12799]: packet from REMOTE_IP:500: ignoring Vendor ID payload [FRAGMENTATION]
Jun 13 23:46:37 Gateway pluto[12799]: packet from REMOTE_IP:500: ignoring Vendor ID payload [MS-Negotiation Discovery Capable]
Jun 13 23:46:37 Gateway pluto[12799]: packet from REMOTE_IP:500: ignoring Vendor ID payload [Vid-Initial-Contact]
Jun 13 23:46:37 Gateway pluto[12799]: packet from REMOTE_IP:500: ignoring Vendor ID payload [IKE CGA version 1]
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[1] REMOTE_IP #1: responding to Main Mode from unknown peer REMOTE_IP
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[1] REMOTE_IP #1: Oakley Transform [AES_CBC (256), HMAC_SHA1, ECP_384] refused due to strict flag
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[1] REMOTE_IP #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, ECP_256] refused due to strict flag
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[1] REMOTE_IP #1: Oakley Transform [AES_CBC (256), HMAC_SHA1, MODP_2048] refused due to strict flag
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[1] REMOTE_IP #1: Oakley Transform [3DES_CBC (192), HMAC_SHA1, MODP_2048] refused due to strict flag
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[1] REMOTE_IP #1: NAT-Traversal: Result using RFC 3947: peer is NATed
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[1] REMOTE_IP #1: Peer ID is ID_DER_ASN1_DN: 'C=US, ST=TN, L=CITY, O=ORG, CN=LAPTOP, E=EMAILADDR'
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[1] REMOTE_IP #1: crl not found
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[1] REMOTE_IP #1: certificate status unknown
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP #1: deleting connection "remote-access-mac-zzz" instance with peer REMOTE_IP {isakmp=#0/ipsec=#0}
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP #1: we have a cert and are sending it upon request
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: sent MR3, ISAKMP SA established
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #2: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #2: IPSec Transform [AES_CBC (128), HMAC_SHA1] refused due to strict flag
Jun 13 23:46:37 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #2: responding to Quick Mode
Jun 13 23:46:38 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #2: IPsec SA established {ESP=>0xc46c3803 <0xced0f433 NATOA=192.168.111.2}
Jun 13 23:46:39 Gateway xl2tpd[2094]: Connection established to REMOTE_IP, 1701.  Local: 17365, Remote: 2 (ref=0/0).  LNS session is 'default'
Jun 13 23:46:39 Gateway xl2tpd[2094]: Call established with REMOTE_IP, Local: 28945, Remote: 1, Serial: 0
Jun 13 23:46:39 Gateway pppd[13160]: pppd 2.4.4 started by root, uid 0
Jun 13 23:46:39 Gateway zebra[497]: interface ppp0 index 11 <POINTOPOINT,NOARP,MULTICAST> added.
Jun 13 23:46:39 Gateway pppd[13160]: Connect: ppp0 <--> /dev/pts/1
Jun 13 23:46:41 Gateway pppd[13160]: Unsupported protocol 'Compression Control Protocol' (0x80fd) received
Jun 13 23:46:41 Gateway zebra[497]: warning: PtP interface ppp0 with addr 10.255.255.0/32 needs a peer address
Jun 13 23:46:41 Gateway zebra[497]: interface index 11 was renamed from ppp0 to l2tp0
Jun 13 23:46:41 Gateway pppd[13160]: Cannot determine ethernet address for proxy ARP
Jun 13 23:46:41 Gateway pppd[13160]: local  IP address 10.255.255.0
Jun 13 23:46:41 Gateway pppd[13160]: remote IP address 192.168.252.2
Jun 13 23:46:41 Gateway zebra[497]: interface l2tp0 index 11 changed <UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>.
Jun 14 00:15:56 Gateway pluto[12799]: "remote-access-mac-zzz"[3] REMOTE_IP:4500 #3: NAT-Traversal: received 2 NAT-OA. using first, ignoring others
Jun 14 00:15:56 Gateway pluto[12799]: "remote-access-mac-zzz"[3] REMOTE_IP:4500 #3: IPSec Transform [AES_CBC (128), HMAC_SHA1] refused due to strict flag
Jun 14 00:15:56 Gateway pluto[12799]: "remote-access-mac-zzz"[3] REMOTE_IP:4500 #3: responding to Quick Mode
Jun 14 00:15:56 Gateway pluto[12799]: "remote-access-mac-zzz"[3] REMOTE_IP:4500 #3: cannot install eroute -- it is in use for "remote-access-mac-zzz"[2] REMOTE_IP:4500 #2
Jun 14 00:15:56 Gateway pluto[12799]: "remote-access-mac-zzz"[3] REMOTE_IP:4500: deleting connection "remote-access-mac-zzz" instance with peer REMOTE_IP {isakmp=#0/ipsec=#0}
Jun 14 00:15:58 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x00000002 (perhaps this is a duplicated packet)
Jun 14 00:15:58 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: sending encrypted notification INVALID_MESSAGE_ID to REMOTE_IP:4500
Jun 14 00:16:01 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x00000002 (perhaps this is a duplicated packet)
Jun 14 00:16:01 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: sending encrypted notification INVALID_MESSAGE_ID to REMOTE_IP:4500
Jun 14 00:16:05 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x00000002 (perhaps this is a duplicated packet)
Jun 14 00:16:05 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: sending encrypted notification INVALID_MESSAGE_ID to REMOTE_IP:4500
Jun 14 00:16:13 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x00000002 (perhaps this is a duplicated packet)
Jun 14 00:16:13 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: sending encrypted notification INVALID_MESSAGE_ID to REMOTE_IP:4500
Jun 14 00:16:14 Gateway pluto[12799]: packet from 92.28.116.250:500: next payload type of ISAKMP Message has an unknown value: 133
Jun 14 00:16:14 Gateway pluto[12799]: packet from 92.28.116.250:500: sending notification PAYLOAD_MALFORMED to 92.28.116.250:500
Jun 14 00:16:16 Gateway pluto[12799]: packet from 92.28.116.250:500: next payload type of ISAKMP Message has an unknown value: 133
Jun 14 00:16:16 Gateway pluto[12799]: packet from 92.28.116.250:500: sending notification PAYLOAD_MALFORMED to 92.28.116.250:500
Jun 14 00:16:18 Gateway pluto[12799]: packet from 92.28.116.250:500: next payload type of ISAKMP Message has an unknown value: 133
Jun 14 00:16:18 Gateway pluto[12799]: packet from 92.28.116.250:500: sending notification PAYLOAD_MALFORMED to 92.28.116.250:500
Jun 14 00:16:22 Gateway pluto[12799]: packet from 92.28.116.250:500: next payload type of ISAKMP Message has an unknown value: 133
Jun 14 00:16:22 Gateway pluto[12799]: packet from 92.28.116.250:500: sending notification PAYLOAD_MALFORMED to 92.28.116.250:500
Jun 14 00:16:30 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x00000002 (perhaps this is a duplicated packet)
Jun 14 00:16:30 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: sending encrypted notification INVALID_MESSAGE_ID to REMOTE_IP:4500
Jun 14 00:16:46 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0x00000002 (perhaps this is a duplicated packet)
Jun 14 00:16:46 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: sending encrypted notification INVALID_MESSAGE_ID to REMOTE_IP:4500
Jun 14 00:17:02 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: received Delete SA(0xc46c3803) payload: deleting IPSEC State #2
Jun 14 00:17:02 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500 #1: received Delete SA payload: deleting ISAKMP State #1
Jun 14 00:17:02 Gateway pluto[12799]: "remote-access-mac-zzz"[2] REMOTE_IP:4500: deleting connection "remote-access-mac-zzz" instance with peer REMOTE_IP {isakmp=#0/ipsec=#0}

 of note are the "Quick Mode I1 message is unacceptable because it uses a previously used Message ID" entries; they are what happens immediately after the connection drops.

bearing in mind that i've only been teaching myself L2TP/IPsec VPNs for about 4 days, any ideas of what's going wrong?

vpn config:

 ipsec {
     auto-firewall-nat-exclude enable
     esp-group ORG {
         compression disable
         lifetime 3600
         mode tunnel
         pfs enable
         proposal 1 {
             encryption aes256
             hash sha1
         }
     }
     ike-group ORG {
         dead-peer-detection {
             action restart
             interval 15
             timeout 30
         }
         lifetime 28800
         proposal 1 {
             encryption aes256
             hash sha1
         }
     }
     ipsec-interfaces {
         interface eth0
     }
     nat-networks {
         allowed-network 0.0.0.0/0 {
         }
     }
     nat-traversal enable
 }
 l2tp {
     remote-access {
         authentication {
             local-users {
                 username USER {
                     password PASS
                 }
             }
             mode local
         }
         client-ip-pool {
             start 192.168.252.2
             stop 192.168.252.5
         }
         ipsec-settings {
             authentication {
                 mode x509
                 x509 {
                     ca-cert-file /config/auth/ipsec/ca.crt
                     server-cert-file /config/auth/ipsec/Gateway.crt
                     server-key-file /config/auth/ipsec/Gateway.key
                 }
             }
             ike-lifetime 3600
         }
         outside-address GATEWAY_IP
     }
 }

 

Previous Employee
Posts: 13,551
Registered: ‎06-10-2011
Kudos: 5480
Solutions: 1656
Contributions: 2

Re: strongswan remote-access VPN - key renegotiation failing (looks like)

Could this be related to the "Windows reconnect" issue discussed previous (e.g., here)?

Regular Member
Posts: 367
Registered: ‎05-09-2014
Kudos: 128
Solutions: 7

Re: strongswan remote-access VPN - key renegotiation failing (looks like)

mmmm i don't think so, because the client here was an Android phone. unless the Android L2TP client has the same problem...

Previous Employee
Posts: 13,551
Registered: ‎06-10-2011
Kudos: 5480
Solutions: 1656
Contributions: 2

Re: strongswan remote-access VPN - key renegotiation failing (looks like)

That is possible since the log sequences do look similar.

Highlighted
Regular Member
Posts: 367
Registered: ‎05-09-2014
Kudos: 128
Solutions: 7

Re: strongswan remote-access VPN - key renegotiation failing (looks like)

bump.

just seeing if anyone's found a solution for this? from what i'm reading, the strongSwan folks don't even support the "pluto" daemon anymore, and are discouraging IKEv1 use, so i'm not sure how further down this rabbit hole i really want to go....