Unfortunately this happened a couple of weeks ago on a test system and I have only just noticed it. I have a set up:
remote_server <--> NAT router <-- Internet --> local_server_with_pppoe
Remote_server config:
conn nick-ikev2
type=tunnel
authby=secret
auto=start
left=10.20.40.248
leftsourceip=192.168.20.1
leftsubnet=192.168.20.0/24
leftid=@clearos_in_clearvm
right=howitts.co.uk
rightsubnet=172.17.2.0/24
rightid=@nick
ikev2=insist
dpdaction=restart
dpdtimeout=120
dpddelay=30
Local_server_with_pppoe
conn nick-ikev2
type=tunnel
authby=secret
auto=add
left=%any
leftsubnet=192.168.20.0/24
leftid=@clearos_in_clearvm
right=%defaultroute
rightsubnet=172.17.2.0/24
rightsourceip=172.17.2.1
rightid=@nick
ikev2=insist
dpdaction=clear
dpdtimeout=120
dpddelay=30
rekey=no
salifetime=9h # (default is 8h)
ikelifetime=2h # (default is 1h)
The local end changed its IP address and the tunnel never recovered with the following repeating in the local logs:
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
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
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
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
And in the remote logs:
Mar 8 03:20:13 ad-dc-server pluto[1810]: "nick-ikev2" #13439: starting keying attempt 7 of an unlimited number
Mar 8 03:20:13 ad-dc-server pluto[1810]: "nick-ikev2" #13440: initiating v2 parent SA to replace #13439
Mar 8 03:20:13 ad-dc-server pluto[1810]: "nick-ikev2" #13439: deleting state (STATE_PARENT_I1) and NOT sending notification
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
Mar 8 03:20:13 ad-dc-server pluto[1810]: "nick-ikev2" #13440: STATE_PARENT_I1: sent v2I1, expected v2R1
Mar 8 03:20:14 ad-dc-server pluto[1810]: "nick-ikev2" #13440: STATE_PARENT_I1: retransmission; will wait 0.5 seconds for response
Mar 8 03:20:14 ad-dc-server pluto[1810]: "nick-ikev2" #13440: STATE_PARENT_I1: retransmission; will wait 1 seconds for response
Mar 8 03:20:15 ad-dc-server pluto[1810]: "nick-ikev2" #13440: STATE_PARENT_I1: retransmission; will wait 2 seconds for response
Mar 8 03:20:17 ad-dc-server pluto[1810]: "nick-ikev2" #13440: STATE_PARENT_I1: retransmission; will wait 4 seconds for response
Mar 8 03:20:21 ad-dc-server pluto[1810]: "nick-ikev2" #13440: STATE_PARENT_I1: retransmission; will wait 8 seconds for response
Mar 8 03:20:29 ad-dc-server pluto[1810]: "nick-ikev2" #13440: STATE_PARENT_I1: retransmission; will wait 16 seconds for response
Mar 8 03:20:45 ad-dc-server pluto[1810]: "nick-ikev2" #13440: STATE_PARENT_I1: retransmission; will wait 32 seconds for response
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
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?
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.
Regards,
Nick
_______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
