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 <[email protected]> wrote: > Thank you! > > --karuna > > > On Tue, Sep 8, 2020 at 6:03 AM Tobias Brunner <[email protected]> > 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 >> >
