[strongSwan] Azure child rekeying loop

[Andrei-Florian Staicu]

Worked perfectly with
  ike=aes256-sha1-modp1024!
  esp=aes256-sha1-modp2048!
I'm sorry I missed that, sorry for wasting your time.

On Mon, Feb 20, 2017 at 9:01 AM Noel Kuntze <noel at familie-kuntze.de> wrote:

> 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.
>
> --
Beware of programmers who carry screwdrivers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20170220/5f32d368/attachment-0001.html>