Description of problem:

Consider the following scenario:

SERVER ipsec.conf
-----------------
version 2.0

config setup
 plutodebug="all"
 plutostderrlog="/var/log/pluto.log"
 protostack=netkey
 virtual_private=
 oe=off

conn test
 authby=secret
 left=10.37.150.137
 right=10.37.150.136
 keyingtries=1
 ikev2=insist 
 auto=add

CLIENT ipsec.conf
-----------------
version 2.0

config setup
 plutodebug="all"
 plutostderrlog="/var/log/pluto.log"
 protostack=netkey
 virtual_private=
 oe=off

conn test
 authby=secret
 left=10.37.150.137
 right=10.37.150.136
 keyingtries=1
 ikev2=insist 
 auto=start

Client initiates connection and (after some time) servers deletes IPSEC SA by 'ipsec whack --deletestate <ipsec_sa_state_id>'. On both ends IPSEC SA is deleted (ISAKMP SA are kept) but server still contains bare shunt:

000 Connection list:
000  
000 "test": 10.37.150.136<10.37.150.136>...10.37.150.137<10.37.150.137>; prospective erouted; eroute owner: #0
000 "test":     oriented; my_ip=unset; their_ip=unset; my_updown=ipsec _updown;
000 "test":   xauth us:none, xauth them:none,  my_username=[any]; their_username=[any]
000 "test":   our auth:secret, their auth:secret
000 "test":   modecfg info: us:none, them:none, modecfg policy:push, dns:unset, domains:unset, banner:unset, cat:unset;
000 "test":   labeled_ipsec:no;
000 "test":   policy_label:unset;
000 "test":   ike_life: 3600s; ipsec_life: 28800s; replay_window: 32; rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 1;
000 "test":   retransmit-interval: 500ms; retransmit-timeout: 60s;
000 "test":   initial-contact:no; cisco-unity:no; fake-strongswan:no; send-vendorid:no; send-no-esp-tfc:no;
000 "test":   policy: PSK+ENCRYPT+TUNNEL+PFS+IKEV2_ALLOW+IKEV2_PROPOSE+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO;
000 "test":   conn_prio: 32,32; interface: eth0; metric: 0; mtu: unset; sa_prio:auto; sa_tfc:none;
000 "test":   nflog-group: unset; mark: unset; vti-iface:unset; vti-routing:no; vti-shared:no; nic-offload:auto;
000 "test":   our idtype: ID_IPV4_ADDR; our id=10.37.150.136; their idtype: ID_IPV4_ADDR; their id=10.37.150.137
000 "test":   dpd: action:hold; delay:0; timeout:0; nat-t: encaps:auto; nat_keepalive:yes; ikev1_natt:both
000 "test":   newest ISAKMP SA: #3; newest IPsec SA: #0;
000 "test":   IKEv2 algorithm newest: AES_GCM_16_256-HMAC_SHA2_512-MODP2048
000  
000 Total IPsec connections: loaded 1, active 0
000  
000 State Information: DDoS cookies not required, Accepting new IKE connections
000 IKE SAs: total(1), half-open(0), open(0), authenticated(1), anonymous(0)
000 IPsec SAs: total(0), authenticated(0), anonymous(0)
000  
000 #3: "test":500 STATE_PARENT_I3 (PARENT SA established); EVENT_SA_REPLACE in 2612s; newest ISAKMP; idle; import:local rekey
000  
000 Bare Shunt list:
000  
000 10.37.150.136/32:46894 -17-> 10.37.150.137/32:1025 => %hold 0    %acquire-netlink

# ip xfrm state
src 10.37.150.136 dst 10.37.150.137
	proto esp spi 0x00000000 reqid 0 mode transport
	replay-window 0 
	anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
	sel src 10.37.150.136/32 dst 10.37.150.137/32 proto udp sport 46894 dport 1025 dev eth0 

When server tries to re-initiate connection by 'ping <client>' - it does not work:

# ping $CLIENTS
PING cc-v18b.lab.eng.brq.redhat.com (10.37.150.137) 56(84) bytes of data.
^C
--- cc-v18b.lab.eng.brq.redhat.com ping statistics ---
14 packets transmitted, 0 received, 100% packet loss, time 12999ms

When client tries to reconnect or when servers flush ip xfrm state, it works as expected - ie. ping will re-initiate connection - new IPSEC SA is created and both ends can communicate. 

Version-Release number of selected component (if applicable):

libreswan-3.25-2.el7

How reproducible:

100%

Steps to Reproduce:

1. See above.

Actual results:

Connection cannot be re-initiated from server.

Expected results:

Connection can be re-initiated from server.

Additional info:

1) This seems to be a kind of regression since 3.23 where it worked just fine. 

2) When 'ipsec auto --down' is used to torn down IPSEC SA, server can re-initiate connection without issues.

3) Sometimes bare shunts disappear after tens of seconds and connection can be re-initiated from server.