[strongSwan] Connectivity between Windows 2019 server and Ubuntu 16.04 stops; can TS be explicitly specified

[Karuna Sagar Krishna]

Hi Tobias,

Would `ipsec update` also work when I update the cert thumbprint in
ipsec.secrets file? i.e. on IKE SA re-negotiation would it use the new cert
thumbprint? I'm assuming that until the IKE SA is re-negotiated the
existing IKE SA and child ESP SA will continue to work, correct?

--karuna


On Tue, Sep 8, 2020 at 10:57 AM Karuna Sagar Krishna <karunasagark at gmail.com>
wrote:

> Thank you!
>
> --karuna
>
>
> On Tue, Sep 8, 2020 at 6:03 AM Tobias Brunner <tobias at strongswan.org>
> wrote:
>
>> Hi Karuna,
>>
>> > 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?
>>
>> Just never use `ipsec reload` unless you know why you do so.  And if you
>> don't modify existing connections using `ipsec update` should be fine
>> (however, if you remove connections, note that this does not affect
>> existing SAs, so you'd have to terminate those manually, before or after
>> removing the config).
>>
>> > 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?
>>
>> Yes, by default all traffic between the local and remote IP addresses
>> will be covered.
>>
>> > 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?
>>
>> Yes, the option applies when outbound traffic hits a trap policy and the
>> kernel triggers an acquire.  And no, the daemon won't accept just any
>> TS, only a TS that matches the local and remote IPs is accepted if you
>> don't configure any traffic selectors.  Since this apparently is the
>> case here (according to the log), the problem is probably caused by
>> `ipsec reload` (i.e. there simply is no child config to match the
>> received traffic selectors against).
>>
>> > 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?
>>
>> Simply when there is no config with matching TS (could have different
>> reasons).
>>
>> > 4. Would strongswan.conf work along with ipsec.conf/starter?
>>
>> strongswan.conf contains global settings, which apply to all daemons and
>> config backends.  You may mix config backends (e.g. swanctl.conf/vici
>> and ipsec.conf/starter) but I'd not recommend that unless you know
>> exactly what you are doing.  So either use one or the other.  It's fine
>> to start the daemon via starter for either of them, though (when using
>> swanctl, just leave ipsec.conf/ipsec.secrets and the directories under
>> ipsec.d empty).
>>
>> Regards,
>> Tobias
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200915/69dce5e5/attachment.html>