<div dir="ltr"><div>Thanks Tobias. Few follow up questions:</div><div><br></div>1. I'm only adding or removing connections in ipsec.conf and not modifying existing connections. And also I only use complete IP addresses for both left and right. So, would `ipsec update` be better suited and would still cause any other known issues?<div></div><div></div><div>2. Yes I looked at left|rightsubnet and I don't want to restrict protocol/port rather would like to apply to all protocol and all ports. And if I understand correctly, the default values for left|rightsubnet is all protocol and all port. Correct?</div><div>3. The charon.ignore_acquire_ts would apply to outbound traffic correct? From what I understand (based on below logs), the issue occurs on the inbound traffic, strongswan is not accepting the remote TS? Because the left|rightsubnet is not configured i.e. default values, so shouldn't it be accepting every remote TS?</div><div>4. Or would TSi and TSr need to match for the CREATE_CHILD_SA to be successful? In which case, TS_UNACCEPT can happen on both inbound and outbound traffic? I guess, I'm asking under what circumstances TS_UNACCEPT error is seen?</div><div>4. Would strongswan.conf work along with ipsec.conf/starter?<br></div><div><br></div><div>*Outbound traffic initiating the CREATE_CHILD_SA request*</div>Aug  7 06:59:11 hn0 charon: 05[KNL] creating acquire job for policy <a href="http://10.0.0.18/32[tcp]">10.0.0.18/32[tcp]</a> === <a href="http://10.0.0.17/32[tcp/https]">10.0.0.17/32[tcp/https]</a> with reqid {6}<br>Aug  7 06:59:11 hn0 charon: 05[IKE] establishing CHILD_SA gw0-ipsec{6}<br>Aug  7 06:59:11 hn0 charon: 05[ENC] generating CREATE_CHILD_SA request 0 [ N(USE_TRANSP) SA No TSi TSr ]<br>Aug  7 06:59:11 hn0 charon: 05[NET] sending packet: from 10.0.0.18[500] to 10.0.0.17[500] (240 bytes)<br>Aug  7 06:59:11 hn0 charon: 06[NET] received packet: from 10.0.0.17[500] to 10.0.0.18[500] (256 bytes)<br>Aug  7 06:59:11 hn0 charon: 06[ENC] parsed CREATE_CHILD_SA response 0 [ SA N(USE_TRANSP) No TSi TSr ]<br>Aug  7 06:59:11 hn0 charon: 06[IKE] CHILD_SA gw0-ipsec{64} established with SPIs ccf3ee22_i 6cee8ea4_o and TS <a href="http://10.0.0.18/32">10.0.0.18/32</a> === <a href="http://10.0.0.17/32">10.0.0.17/32</a><div><br></div><div>*Remote node initiating the CREATE_CHILD_SA request*<br>Aug  7 06:59:12 hn0 charon: 12[NET] received packet: from 10.0.0.17[500] to 10.0.0.18[500] (224 bytes)<br>Aug  7 06:59:12 hn0 charon: 12[ENC] parsed CREATE_CHILD_SA request 21 [ SA N(USE_TRANSP) No TSi TSr ]<br>Aug  7 06:59:12 hn0 charon: 12[IKE] traffic selectors <a href="http://10.0.0.18/32">10.0.0.18/32</a> === <a href="http://10.0.0.17/32">10.0.0.17/32</a> inacceptable<br>Aug  7 06:59:12 hn0 charon: 12[IKE] failed to establish CHILD_SA, keeping IKE_SA<br>Aug  7 06:59:12 hn0 charon: 12[ENC] generating CREATE_CHILD_SA response 21 [ N(TS_UNACCEPT) ]<br>Aug  7 06:59:12 hn0 charon: 12[NET] sending packet: from 10.0.0.18[500] to 10.0.0.17[500] (80 bytes)<div><br></div><div>Unfortunately, Ubuntu 16.04 doesn't have strongswan-swanctl package. I could get source and build, but I'm trying to evaluate if it makes sense to spend the effort  <br></div><div><br></div><div>--karuna</div><div><br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 4, 2020 at 1:38 AM Tobias Brunner <<a href="mailto:tobias@strongswan.org">tobias@strongswan.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Karuna,<br>
<br>
> The issue is intermittent<br>
> and possibly coincides with ipsec reload command execution used when we<br>
> make changes in the ipsec.conf file.<br>
<br>
Don't use `ipsec reload`, if anything use `ipsec update` as it only<br>
affects the actually modified configs.  Either way, there are known<br>
issues with rekeying if configs are modified (see e.g. [1], as mentioned<br>
there, using swanctl.conf might work better if that's the issue).<br>
<br>
> We haven't seen this between Linux<br>
> nodes. From the syslog, we see the TS_UNACCEPT error. One of the Windows<br>
> expert in the team captured netsh logs and he mentioned that the Linux<br>
> node is sending a traffic selector with UDP protocol port 1025<br>
> specifically, which is probably leading to TS_UNACCEPT. This is<br>
> unexpected, since we are expecting all protocol and port to be under<br>
> IPSec. However, don't understand why this is intermittent.<br>
<br>
That indicates a different problem.  If the trap policy (auto=route) is<br>
triggered (initially or after a failure), the first traffic selector<br>
sent is derived from the matching packet (which includes protocol and<br>
ports).  If the remote server can't handle that, you may enable<br>
charon.ignore_acquire_ts in strongswan.conf to avoid sending these<br>
traffic selectors.<br>
<br>
> Is there a property to specify the traffic selector explicitly in<br>
> ipsec.conf?<br>
<br>
There are obviously left|rightsubnet but for transport mode SAs you only<br>
have to configure them if you actually want to restrict protocol/port.<br>
<br>
Regards,<br>
Tobias<br>
<br>
[1] <a href="https://wiki.strongswan.org/issues/1338#note-3" rel="noreferrer" target="_blank">https://wiki.strongswan.org/issues/1338#note-3</a><br>
</blockquote></div>