[strongSwan] Azure child rekeying loop

[Noel Kuntze]

The remote side probably uses PFS.
Either set the correct DH group that corresponds to the configuration of the remote side or disable PFS there.

aes256-sha1 != aes256-sha1-modp2048

Am 19. Februar 2017 16:31:08 MEZ schrieb Andrei-Florian Staicu <andrei.staicu at gmail.com>:
>Hi,
>
>I have a site-to-site tunnel to a private classic Azure.
>It starts and works perfectly but, after after approx 43 minutes (i
>think
>it's the child rekeying interval), it starts looping like this:
>
>08[KNL] creating rekey job for CHILD_SA ESP/0x066cf00c/<remote>
>06[IKE] establishing CHILD_SA CONNECTION{1}
>06[IKE] establishing CHILD_SA CONNECTION{1}
>06[ENC] generating CREATE_CHILD_SA request 0 [ N(REKEY_SA) SA No TSi
>TSr ]
>06[NET] sending packet: from <local>[4500] to <remote>[4500] (220
>bytes)
>14[NET] received packet: from <remote>[4500] to <local>[4500] (76
>bytes)
>14[ENC] parsed CREATE_CHILD_SA response 0 [ N(NO_PROP) ]
>14[IKE] received NO_PROPOSAL_CHOSEN notify, no CHILD_SA built
>14[IKE] failed to establish CHILD_SA, keeping IKE_SA
>14[IKE] CHILD_SA rekeying failed, trying again in 30 seconds
>
>strongswan statusall:
>Status of IKE charon daemon (strongSwan 5.4.0, Linux
>3.10.0-514.2.2.el7.x86_64, x86_64):
>  uptime: 57 minutes, since Feb 19 16:17:21 2017
>  malloc: sbrk 2703360, mmap 0, used 522128, free 2181232
>  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
>scheduled: 5
> loaded plugins: charon aes des rc2 sha2 sha1 md4 md5 random nonce x509
>revocation constraints acert pubkey pkcs1 pkcs8 pkcs12 pgp dnskey
>sshkey
>pem openssl gcrypt fips-prf gmp xcbc cmac hmac ctr ccm gcm curl attr
>kernel-netlink resolve socket-default farp stroke vici updown
>eap-identity
>eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic
>xauth-eap xauth-pam xauth-noauth dhcp
>Listening IP addresses:
>  <local>
>Connections:
>CONNECTION:  <local>...<remote>  IKEv2, dpddelay=30s
>CONNECTION:   local:  [<local>] uses pre-shared key authentication
>CONNECTION:   remote: [<remote>] uses pre-shared key authentication
>CONNECTION:   child:  0.0.0.0/0 === 10.254.254.0/29 10.200.0.0/16
>TUNNEL,
>dpdaction=restart
>Security Associations (1 up, 0 connecting):
>CONNECTION[2]: ESTABLISHED 57 minutes ago,
><local>[<local>]...<remote>[<remote>]
>CONNECTION[2]: IKEv2 SPIs: 01e5013ada90fe24_i 0fa0482414130fad_r*,
>rekeying
>in 6 hours
>CONNECTION[2]: IKE proposal:
>AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
>CONNECTION{2}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c62f2d74_i
>066cf00c_o
>CONNECTION{2}:  AES_CBC_256/HMAC_SHA1_96, 37046 bytes_i (739 pkts, 2s
>ago),
>36233 bytes_o (741 pkts, 420s ago), rekeying active
>CONNECTION{2}:   0.0.0.0/0 === 10.200.0.0/16 10.254.254.0/29
>
>
>Any idea why it would be doing that, even though the initial connection
>succeeds?
>
>Thanks.
>
>
>ipsec.conf:
>config setup
>
>conn CONNECTION
>  closeaction=restart
>  dpdaction=restart
>  ike=aes256-sha1-modp1024!
>  esp=aes256-sha1!
>  reauth=no
>  keyexchange=ikev2
>  ikelifetime=28800s
>  keylife=3600s
>  keyingtries=%forever
>  authby=secret
>  type=tunnel
>  forceencaps=yes
>  left=<local>
>  leftid=<local>
>  leftsubnet=0.0.0.0/0
>  right=<remote>
>  rightid=<remote>
>  rightsubnet=10.254.254.0/29,10.200.0.0/16
>  auto=start
>-- 
>Beware of programmers who carry screwdrivers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170220/4691f3bb/attachment.html>