Issue #3568
vpn connection is unstable
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 almost 2 years 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 almost 2 years 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.x500 to 4.4.4.4500 (334 bytes)
charon: 13[NET] received packet: from 4.4.4.4500 to 10.10.x.x500 (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.x500 to 4.4.4.4500 (316 bytes)
charon: 14[NET] received packet: from 4.4.4.4500 to 10.10.x.x500 (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 almost 2 years 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 almost 2 years 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.44500 to 10.10.x.x4500 (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 almost 2 years 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).