<div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi all,<br><br></div><div>I am running StrongSwan 4.4.1.<br></div>I will ask the questions first, then list the log after.<br><br></div>1. What could cause "unable to add policy" at reauthentication time? Kernal already has those policies installed? resource exhausted? What else?<br>
</div>2. In our lab or when things are working fine, I see logs like below during reauthentication:<br></div>- deleting duplicate IKE_SA for peer blah blah due to uniqueness policy<br></div>- queueing and activating IKE_DELETE task<br>
</div>- policy <a href="http://0.0.0.0/0">0.0.0.0/0</a> === <a href="http://10.10.10.0/24">10.10.10.0/24</a> out already exists, increasing refcount<br></div>What could cause the responder to not realized that this is re-authentication of an existing peer?<br>
<br><br></div>We have a customer with a few hundred units connecting to an IPSec server. Things were okay for a few months. Then re-authentication failed on all the units.<br></div>Typical log:<br>--------------------------------------------------------------------------------------------------------<br>
charon: 04[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]<br>charon: 04[IKE] 2.2.2.2 is initiating an IKE_SA<br>charon: 04[IKE] 2.2.2.2 is initiating an IKE_SA<br>charon: 04[IKE] local host is behind NAT, sending keep alives<br>
charon: 04[IKE] remote host is behind NAT<br>charon: 04[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]<br>charon: 04[NET] sending packet: from 10.128.3.70[500] to 2.2.2.2[6457]<br>
charon: 13[NET] received packet: from 70.208.23.77[2618] to 10.128.3.70[500]<br>charon: 13[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]<br>charon: 02[NET] received packet: from 2.2.2.2[6457] to 10.128.3.70[4500]<br>
charon: 02[ENC] parsed IKE_AUTH request 1 [ IDi IDr AUTH SA TSi TSr N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH) ]<br>charon: 02[CFG] looking for peer configs matching 10.128.3.70[1.1.1.1]...2.2.2.2[SOMESERIALNUM]<br>
charon: 13[IKE] 70.208.23.77 is initiating an IKE_SA<br>charon: 13[IKE] 70.208.23.77 is initiating an IKE_SA<br>charon: 02[CFG] selected peer config 'peer-SOMESERIALNUM-tunnel-1'<br>charon: 02[IKE] authentication of 'SOMESERIALNUM' with pre-shared key successful<br>
charon: 02[IKE] peer supports MOBIKE<br>charon: 02[IKE] authentication of '1.1.1.1' (myself) with pre-shared key<br>charon: 02[IKE] IKE_SA peer-SOMESERIALNUM-tunnel-1[16] established between 10.128.3.70[1.1.1.1]...2.2.2.2[SOMESERIALNUM]<br>
charon: 02[IKE] IKE_SA peer-SOMESERIALNUM-tunnel-1[16] established between 10.128.3.70[1.1.1.1]...2.2.2.2[SOMESERIALNUM]<br>charon: 02[KNL] unable to add policy <a href="http://0.0.0.0/0">0.0.0.0/0</a> === <a href="http://10.121.10.80/28">10.121.10.80/28</a> out<br>
charon: 02[KNL] unable to add policy <a href="http://10.121.10.80/28">10.121.10.80/28</a> === <a href="http://0.0.0.0/0">0.0.0.0/0</a> in<br>charon: 02[KNL] unable to add policy <a href="http://10.121.10.80/28">10.121.10.80/28</a> === <a href="http://0.0.0.0/0">0.0.0.0/0</a> fwd<br>
charon: 02[IKE] unable to install IPsec policies (SPD) in kernel<br>charon: 02[ENC] generating IKE_AUTH response 1 [ IDr AUTH N(MOBIKE_SUP) N(ADD_4_ADDR) N(TS_UNACCEPT) ]<br><br></div>- Then a few DPDs sent from the IPsec server to the unit.<br>
</div>- Then the unit try IKE INIT again and is successful.<br></div>- The connection would stay up for the duration of ikelifetime.<br></div>- Then the cycle repeats.<br><div><div><div><div>--------------------------------------------------------------------------------------------------------<br>
<br>After rebooted the server, the same condition persisted for a few hours before getting back to<br></div><div>normal?! Now there are a few "unable to add policy" in the server log once every few hours.<br><br>
</div><div>Regards,<br></div><div>sialnije<br></div></div></div></div></div>