Подскажите пожалуйста, что может быть не так.
Происходит хендшейк, но стопорится посередине. Причем видимо на стороне Кинетика.
[I] Apr 18 22:55:08 ipsec: Starting strongSwan 5.5.0 IPsec [starter]...
[I] Apr 18 22:55:08 ipsec: 00[DMN] Starting IKE charon daemon (strongSwan 5.5.0, Linux 2.6.22.15, mips)
[I] Apr 18 22:55:08 ipsec: 00[CFG] loading secrets
[I] Apr 18 22:55:08 ipsec: 00[CFG] loaded IKE secret for xxxxxx@gmail.com
[I] Apr 18 22:55:08 ipsec: 00[CFG] loaded EAP secret for vpnuser
[I] Apr 18 22:55:08 ipsec: 00[CFG] starting systime check, interval: 10s
[I] Apr 18 22:55:08 ipsec: 00[LIB] loaded plugins: charon aes des sha2 sha1 md5 random nonce openssl xcbc cmac hmac attr kernel-netlink socket-default stroke updown eap-mschapv2 eap-dynamic xauth-generic xauth-eap error-notify systime-fix
[I] Apr 18 22:55:08 ipsec: 06[CFG] received stroke: add connection 'Hyperexpert'
[I] Apr 18 22:55:08 ipsec: 06[CFG] added configuration 'Hyperexpert'
[I] Apr 18 22:55:08 ipsec: 08[CFG] received stroke: initiate 'Hyperexpert'
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending XAuth vendor ID
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending DPD vendor ID
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending NAT-T (RFC 3947) vendor ID
[I] Apr 18 22:55:08 ipsec: 08[IKE] sending draft-ietf-ipsec-nat-t-ike-02\n vendor ID
[I] Apr 18 22:55:08 ipsec: 08[IKE] initiating Main Mode IKE_SA Hyperexpert[1] to 208.115.99.179
[I] Apr 18 22:55:08 ipsec: 10[IKE] received DPD vendor ID
[I] Apr 18 22:55:08 ipsec: 10[IKE] received FRAGMENTATION vendor ID
[I] Apr 18 22:55:08 ipsec: 10[IKE] received XAuth vendor ID
[I] Apr 18 22:55:08 ipsec: 10[IKE] received NAT-T (RFC 3947) vendor ID
[I] Apr 18 22:55:08 ipsec: 10[CFG] received proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#
[I] Apr 18 22:55:08 ipsec: 10[CFG] configured proposals: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_8192/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_6144/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_4096/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_3072/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536/#, IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024/#
[I] Apr 18 22:55:08 ipsec: 10[CFG] selected proposal: IKE:AES_CBC=128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048/#
[I] Apr 18 22:55:09 ipsec: 11[IKE] linked key for crypto map 'Hyperexpert' is not found, still searching
и на этом still searching уходит в себя.
На стороне сервера:
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: responding to Main Mode from unknown peer 93.xx.xx.xx on port 128
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP8192] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP6144] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP4096] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: Oakley Transform [AES_CBC (128), HMAC_SHA1, MODP3072] refused
Apr 18 15:43:21 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R1: sent MR1, expecting MI2
Apr 18 15:43:22 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R2: sent MR2, expecting MI3
Apr 18 15:43:22 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R2: retransmission; will wait 0.5 seconds for response
Apr 18 15:43:23 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: ignoring informational payload INVALID_KEY_INFORMATION, msgid=00000000, length=28
Apr 18 15:43:23 mine pluto[19954]: | ISAKMP Notification Payload
Apr 18 15:43:23 mine pluto[19954]: | 00 00 00 1c 00 00 00 01 01 10 00 11
Apr 18 15:43:23 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: received and ignored informational message
Apr 18 15:43:23 mine pluto[19954]: "xauth-psk"[1] 93.xx.xx.xx #1: STATE_MAIN_R2: retransmission; will wait 1 seconds for response
Ну и далше онее убивает
STATE_MAIN_R2: 60 second timeout exceeded after 7 retransmits. No response (or no acceptable response) to our IKEv1 message