<div dir="ltr">Thank you!<div><br></div><div>--karuna</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Sep 8, 2020 at 6:03 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>
> 1. I'm only adding or removing connections in ipsec.conf and not<br>
> modifying existing connections. And also I only use complete IP<br>
> addresses for both left and right. So, would `ipsec update` be better<br>
> suited and would still cause any other known issues?<br>
<br>
Just never use `ipsec reload` unless you know why you do so.  And if you<br>
don't modify existing connections using `ipsec update` should be fine<br>
(however, if you remove connections, note that this does not affect<br>
existing SAs, so you'd have to terminate those manually, before or after<br>
removing the config).<br>
<br>
> 2. Yes I looked at left|rightsubnet and I don't want to restrict<br>
> protocol/port rather would like to apply to all protocol and all ports.<br>
> And if I understand correctly, the default values for left|rightsubnet<br>
> is all protocol and all port. Correct?<br>
<br>
Yes, by default all traffic between the local and remote IP addresses<br>
will be covered.<br>
<br>
> 3. The charon.ignore_acquire_ts would apply to outbound traffic correct?<br>
> From what I understand (based on below logs), the issue occurs on<br>
> the inbound traffic, strongswan is not accepting the remote TS? Because<br>
> the left|rightsubnet is not configured i.e. default values, so shouldn't<br>
> it be accepting every remote TS?<br>
<br>
Yes, the option applies when outbound traffic hits a trap policy and the<br>
kernel triggers an acquire.  And no, the daemon won't accept just any<br>
TS, only a TS that matches the local and remote IPs is accepted if you<br>
don't configure any traffic selectors.  Since this apparently is the<br>
case here (according to the log), the problem is probably caused by<br>
`ipsec reload` (i.e. there simply is no child config to match the<br>
received traffic selectors against).<br>
<br>
> 4. Or would TSi and TSr need to match for the CREATE_CHILD_SA to be<br>
> successful? In which case, TS_UNACCEPT can happen on both inbound and<br>
> outbound traffic? I guess, I'm asking under what circumstances<br>
> TS_UNACCEPT error is seen?<br>
<br>
Simply when there is no config with matching TS (could have different<br>
reasons).<br>
<br>
> 4. Would strongswan.conf work along with ipsec.conf/starter?<br>
<br>
strongswan.conf contains global settings, which apply to all daemons and<br>
config backends.  You may mix config backends (e.g. swanctl.conf/vici<br>
and ipsec.conf/starter) but I'd not recommend that unless you know<br>
exactly what you are doing.  So either use one or the other.  It's fine<br>
to start the daemon via starter for either of them, though (when using<br>
swanctl, just leave ipsec.conf/ipsec.secrets and the directories under<br>
ipsec.d empty).<br>
<br>
Regards,<br>
Tobias<br>
</blockquote></div>