Issue #3568: vpn connection is unstable - strongSwan

Issue #3568

vpn connection is unstable

Added by Karla Toa 4 months ago. Updated 4 months ago.

Status:

Feedback

Priority:

Normal

Assignee:

Category:

configuration

Affected version:

5.6.2

Resolution:

Description

I set up a VPN server in the cloud, but my connection is unstable. The connection lasts more or less 2 hours and it drops, to establish my connection again I must use ipsec up but the idea is to have a permanent connection.

config setup

charondebug="all" 
        uniqueids=yes
        strictcrlpolicy=no

conn test

REKEYING, TUNNEL, reqid 2, expires in xx minutes are always displayed, after 2 rekeying the connection is lost
type=tunnel
compress=no
keyexchange=ikev1
leftid=2.2.2.2
leftsubnet=10.10.0.0/16
leftauth=psk
rightsubnet=10.100.1.0/24
right=4.4.4.4
rightid=4.4.4.4
rightauth=psk
ike=aes128-sha1-modp1024!
esp=aes128-sha1-modp1024!
ikelifetime=3h
lifetime=3600s
auto=start

History

#1 Updated by Tobias Brunner 4 months ago

Status changed from New to Feedback

Read the log to see what happens. But if you are concerned with stability at all, don't use IKEv1.

#2 Updated by Karla Toa 4 months ago

Hi,
I have checked the logs and the message I always see is "received INVALID_ID_INFORMATION error notify"

logs:
charon: 12[IKE] retransmit 5 of request with message ID 0
charon: 12[NET] sending packet: from 10.10.x.x⁵⁰⁰ to 4.4.4.4⁵⁰⁰ (334 bytes)
charon: 13[NET] received packet: from 4.4.4.4⁵⁰⁰ to 10.10.x.x⁵⁰⁰ (316 bytes)
charon: 13[ENC] parsed QUICK_MODE request 195710494 [ HASH SA No KE ID ID ]
charon: 13[IKE] detected rekeying of CHILD_SA test{3}
charon: 13[ENC] generating QUICK_MODE response 195710494 [ HASH SA No KE ID ID ]
charon: 13[NET] sending packet: from 110.10.x.x⁵⁰⁰ to 4.4.4.4⁵⁰⁰ (316 bytes)
charon: 14[NET] received packet: from 4.4.4.4⁵⁰⁰ to 10.10.x.x⁵⁰⁰ (76 bytes)
charon: 14[ENC] parsed INFORMATIONAL_V1 request 1149854268 [ HASH N(INVAL_ID) ]
charon: 14[IKE] received INVALID_ID_INFORMATION error notify
... ...
charon: 01[IKE] unable to reauthenticate in CHILD_SA REKEYING state, delaying for 14s

ipsec statusall:
ESTABLISHED 23 minutes ago, xxxx
IKEv1 SPIs: 4082b966768ac145_i 0a81accafd0ddb4a_r*, pre-shared key reauthentication in 23 minutes
IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
Tasks passive: QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE
QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE QUICK_MODE
QUICK_MODE QUICK_MODE QUICK_MODE
REKEYING, TUNNEL, reqid 2, expires in 37 minutes

I have done some tests but I cannot get the connection to stay for more than 1 hour. The remote side only works with ikev1

#3 Updated by Tobias Brunner 4 months ago

I have checked the logs and the message I always see is "received INVALID_ID_INFORMATION error notify"

During Quick Mode this usually means the traffic selectors are incorrect. However, it's strange that it apparently happens when the peer handles a rekeying response (or it could be from an earlier exchange perhaps). But again, IKEv1 is just crap, so ¯\_(ツ)_/¯. Try to get the logs of the other end to see why it sends the error notify.

#4 Updated by Karla Toa 4 months ago

Hello, now both peers handle ikev2 but I have checked the logs and I see the following:
charon: 06[NET] received packet: from 4.4.4.4⁴⁵⁰⁰ to 10.10.x.x⁴⁵⁰⁰ (236 bytes)
charon: 06[ENC] parsed CREATE_CHILD_SA request 111 [ SA No TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]
charon: 06[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
charon: 06[IKE] traffic selectors 2.2.2.2/32[udp/18234] 0.0.0.0/0 === 4.4.4.4/32[udp/44331] 0.0.0.0/0 inacceptable
charon: 06[IKE] failed to establish CHILD_SA, keeping IKE_SA
charon: 06[ENC] generating CREATE_CHILD_SA response 111 [ N(TS_UNACCEPT) ]

The remote peer indicates that in their logs does not display any errors

I changed the times but still my connection is lost after 1 hour and have to restart with ipsec reload to function again
config setup
charondebug="all"
uniqueids=yes
strictcrlpolicy=no

conn %default
ikelifetime=1440m
#lifetime=3600s
keylife=60m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2

conn test
type=tunnel
compress=no
leftid=2.2.2.2
leftsubnet=10.10.0.0/16
leftauth=psk
rightsubnet=10.100.0.0/24
right=4.4.4.4
rightid=4.4.4.4
rightauth=psk
ike=aes128-sha1-modp1024!
esp=aes128-sha1!
auto=start

#5 Updated by Tobias Brunner 4 months ago

Category changed from ikev1 to configuration
Affected version changed from 5.9.0 to 5.6.2

charon: 06[IKE] traffic selectors 2.2.2.2/32[udp/18234] 0.0.0.0/0 === 4.4.4.4/32[udp/44331] 0.0.0.0/0 inacceptable

The proposed traffic selectors look strange compared to your config. While 0.0.0.0/0 on both ends could be narrowed to what you have configured with left|rightsubnet, the first traffic selectors don't match at all (2.2.2.2/32[udp/18234] just doesn't match 10.10.0.0/16, no packet with those addresses/ports can be tunneled after narrowing). Maybe you can get the peer to avoid sending that first traffic selector (if it was created from a trap policy in strongSwan charon.ignore_acquire_ts could be enabled), or even use the actual traffic selectors you configured.

Also, you seem to be using an older release ("inacceptable" was replaced with "unacceptable" with 5.7.0).

Also available in: Atom PDF

Project

General

Profile

strongSwan

Issues

New issues