<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body>
    Hello Paul,<br>
    <br>
    Unfortunately this happened a couple of weeks ago on a test system
    and I have only just noticed it. I have a set up:<br>
    <br>
    remote_server <--> NAT router <-- Internet -->
    local_server_with_pppoe<br>
    <br>
    Remote_server config:<br>
    conn nick-ikev2<br>
     type=tunnel<br>
     authby=secret<br>
     auto=start<br>
     left=10.20.40.248<br>
     leftsourceip=192.168.20.1<br>
     leftsubnet=192.168.20.0/24<br>
     leftid=@clearos_in_clearvm<br>
     right=howitts.co.uk<br>
     rightsubnet=172.17.2.0/24<br>
     rightid=@nick<br>
     ikev2=insist<br>
     dpdaction=restart<br>
     dpdtimeout=120<br>
     dpddelay=30<br>
    <br>
    Local_server_with_pppoe<br>
    conn nick-ikev2<br>
     type=tunnel<br>
     authby=secret<br>
     auto=add<br>
     left=%any<br>
     leftsubnet=192.168.20.0/24<br>
     leftid=@clearos_in_clearvm<br>
     right=%defaultroute<br>
     rightsubnet=172.17.2.0/24<br>
     rightsourceip=172.17.2.1<br>
     rightid=@nick<br>
     ikev2=insist<br>
     dpdaction=clear<br>
     dpdtimeout=120<br>
     dpddelay=30<br>
     rekey=no<br>
     salifetime=9h # (default is 8h)<br>
     ikelifetime=2h # (default is 1h)<br>
    <br>
    The local end changed its IP address and the tunnel never recovered
    with the following repeating in the local logs:<br>
    Mar 11 16:06:17 server pluto[19555]: packet from 209.90.117.194:500:
    initial parent SA message received on 84.9.57.48:500 but no suitable
    connection found with IKEv2 policy<br>
    Mar 11 16:06:17 server pluto[19555]: packet from 209.90.117.194:500:
    responding to SA_INIT message (ID 0) from 209.90.117.194:500 with
    unencrypted notification NO_PROPOSAL_CHOSEN<br>
    Mar 11 16:06:17 server pluto[19555]: packet from 209.90.117.194:500:
    initial parent SA message received on 84.9.57.48:500 but no suitable
    connection found with IKEv2 policy<br>
    Mar 11 16:06:17 server pluto[19555]: packet from 209.90.117.194:500:
    responding to SA_INIT message (ID 0) from 209.90.117.194:500 with
    unencrypted notification NO_PROPOSAL_CHOSEN<br>
    <br>
    And in the remote logs:<br>
    Mar  8 03:20:13 ad-dc-server pluto[1810]: "nick-ikev2" #13439:
    starting keying attempt 7 of an unlimited number<br>
    Mar  8 03:20:13 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    initiating v2 parent SA to replace #13439<br>
    Mar  8 03:20:13 ad-dc-server pluto[1810]: "nick-ikev2" #13439:
    deleting state (STATE_PARENT_I1) and NOT sending notification<br>
    Mar  8 03:20:13 ad-dc-server pluto[1810]: "nick-ikev2" #13439:
    deleting IKE SA for connection 'nick-ikev2' but connection is
    supposed to remain up; schedule EVENT_REVIVE_CONNS<br>
    Mar  8 03:20:13 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    STATE_PARENT_I1: sent v2I1, expected v2R1<br>
    Mar  8 03:20:14 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response<br>
    Mar  8 03:20:14 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    STATE_PARENT_I1: retransmission; will wait 1 seconds for response<br>
    Mar  8 03:20:15 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    STATE_PARENT_I1: retransmission; will wait 2 seconds for response<br>
    Mar  8 03:20:17 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    STATE_PARENT_I1: retransmission; will wait 4 seconds for response<br>
    Mar  8 03:20:21 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    STATE_PARENT_I1: retransmission; will wait 8 seconds for response<br>
    Mar  8 03:20:29 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    STATE_PARENT_I1: retransmission; will wait 16 seconds for response<br>
    Mar  8 03:20:45 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    STATE_PARENT_I1: retransmission; will wait 32 seconds for response<br>
    Mar  8 03:21:17 ad-dc-server pluto[1810]: "nick-ikev2" #13440:
    STATE_PARENT_I1: 60 second timeout exceeded after 7 retransmits.  No
    response (or no acceptable response) to our first IKEv2 message<br>
    <br>
    A simple reload of the conn at the local end fixed it, but I thought
    the tunnel should have successfully re-keyed once the IP address
    changed. The remote end obviously tracked the IP change as the local
    end still received connection attempts. Is it a problem with the
    local dpdaction being set to clear rather than restart or something
    more significant?<br>
    <br>
    Both ends are running ClearOS 7.7 with
    libreswan-3.25-8.1.el7_7.x86_64 from Centos. There have been no
    further Centos/EL7 releases.<br>
    <br>
    Regards,<br>
    <br>
    Nick<br>
  </body>
</html>