Tunnel with Azure is getting down consistently and need to reset

General questions
, ,
1

Hi Team,

I built two VTI tunnels with Azure and running BGP over IPsec. Somehow frequently the traffic does not pass through time the and then I analyzed the logs and eventually found these. Any idea what could have gone wrong? This is 1.2.8

Nov 11 10:47:38 xxxx charon: 11[CFG] <peer-xx.xx.153.181-tunnel-vti|6448> configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Nov 11 10:47:38 xxxx charon: 11[IKE] <peer-xx.xx.153.181-tunnel-vti|6448> no acceptable proposal found
Nov 11 10:47:38 xxxx charon: 11[IKE] <peer-xx.xx.153.181-tunnel-vti|6448> failed to establish CHILD_SA, keeping IKE_SA
Nov 11 10:47:38 xxxx charon: 11[ENC] <peer-xx.xx.153.181-tunnel-vti|6448> generating CREATE_CHILD_SA response 1925 [ N(NO_PROP) ]
Nov 11 10:47:38 xxxx charon: 11[NET] <peer-xx.xx.153.181-tunnel-vti|6448> sending packet: from xx.xx.97.110[500] to xx.xx.153.181[500] (76 bytes)
Nov 11 10:47:40 xxxx charon: 13[NET] <peer-xx.xx.16.236-tunnel-vti|6431> received packet: from xx.xx.16.236[500] to xx.xx.60.106[500] (396 bytes)
Nov 11 10:47:40 xxxx charon: 13[ENC] <peer-xx.xx.16.236-tunnel-vti|6431> parsed CREATE_CHILD_SA request 209 [ SA No TSi TSr ]
Noxx.xxv 11 10:47:40 xxxx charon: 13[CFG] <peer-xx.xx.16.236-tunnel-vti|6431> received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/NO
_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/NO
_EXT_SEQ
Nov 11 10:47:40 xxxx charon: 13[CFG] <peer-xx.xx.16.236-tunnel-vti|6431> configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Nov 11 10:47:40 xxxx charon: 13[IKE] <peer-xx.xx.16.236-tunnel-vti|6431> no acceptable proposal found
Nov 11 10:47:40 xxxx charon: 13[IKE] <peer-xx.xx.16.236-tunnel-vti|6431> failed to establish CHILD_SA, keeping IKE_SA
Nov 11 10:47:40 xxxx charon: 13[ENC] <peer-xx.xx.16.236-tunnel-vti|6431> generating CREATE_CHILD_SA response 209 [ N(NO_PROP) ]
Nov 11 10:47:40 xxxx charon: 13[NET] <peer-xx.xx.16.236-tunnel-vti|6431> sending packet: from xx.xx.60.106[500] to xx.xx.16.236[500] (76 bytes)
Nov 11 10:47:41 xxxx charon: 10[NET] <peer-xx.xx.153.181-tunnel-vti|6448> received packet: from xx.xx.153.181[500] to xx.xx.97.110[500] (396 bytes)
Nov 11 10:47:41 xxxx charon: 10[ENC] <peer-xx.xx.153.181-tunnel-vti|6448> parsed CREATE_CHILD_SA request 1926 [ SA No TSi TSr ]
Nov 11 10:47:41 xxxx charon: 10[CFG] <peer-xx.xx.153.181-tunnel-vti|6448> received proposals: ESP:AES_GCM_16_256/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA1_96/N
O_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ, ESP:AES_CBC_128/HMAC_SHA1_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA2_256_128/N
O_EXT_SEQ
Nov 11 10:47:41 xxxx charon: 10[CFG] <peer-xx.xx.153.181-tunnel-vti|6448> configured proposals: ESP:AES_CBC_256/HMAC_SHA1_96/MODP_1024/NO_EXT_SEQ
Nov 11 10:47:41 xxxx charon: 10[IKE] <peer-xx.xx.153.181-tunnel-vti|6448> no acceptable proposal found
Nov 11 10:47:41 xxxx charon: 10[IKE] <peer-xx.xx.153.181-tunnel-vti|6448> failed to establish CHILD_SA, keeping IKE_SA
Nov 11 10:47:41 xxxx charon: 10[ENC] <peer-xx.xx.153.181-tunnel-vti|6448> generating CREATE_CHILD_SA response 1926 [ N(NO_PROP) ]
Nov 11 10:47:41 xxxx charon: 10[NET] <peer-xx.xx.153.181-tunnel-vti|6448> sending packet: from xx.xx.97.110[500] to xx.xx.153.181[500] (76 bytes)
Nov 11 10:47:41 xxxx charon: 14[NET] <9209> received packet: from xx.xx.153.181[500] to xx.xx.60.106[500] (620 bytes)
Nov 11 10:47:41 xxxx charon: 14[ENC] <9209> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) V V V V ]
Nov 11 10:47:41 xxxx charon: 14[IKE] <9209> no IKE config found for xx.xx.60.106...xx.xx.153.181, sending NO_PROPOSAL_CHOSEN
Nov 11 10:47:41 xxxx charon: 14[ENC] <9209> generating IKE_SA_INIT response 0 [ N(NO_PROP) ]
2

Config missmatch as proposals received and co figured are different .
Re-check all requirements and real settings

3

Right this is what I suspected and have asked Azure folks to arrange the call. However I still wonder why does it work when we restart the ipsec process? Any clue?

4

It depends who initiates the session. In any case it could work but not in another.