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

Fri Sep 4 21:55:54 CEST 2020

Thanks Tobias. Few follow up questions:

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?
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?
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?
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?
4. Would strongswan.conf work along with ipsec.conf/starter?

*Outbound traffic initiating the CREATE_CHILD_SA request*
Aug  7 06:59:11 hn0 charon: 05[KNL] creating acquire job for policy
10.0.0.18/32[tcp] === 10.0.0.17/32[tcp/https] with reqid {6}
Aug  7 06:59:11 hn0 charon: 05[IKE] establishing CHILD_SA gw0-ipsec{6}
Aug  7 06:59:11 hn0 charon: 05[ENC] generating CREATE_CHILD_SA request 0 [
N(USE_TRANSP) SA No TSi TSr ]
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)
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)
Aug  7 06:59:11 hn0 charon: 06[ENC] parsed CREATE_CHILD_SA response 0 [ SA
N(USE_TRANSP) No TSi TSr ]
Aug  7 06:59:11 hn0 charon: 06[IKE] CHILD_SA gw0-ipsec{64} established with
SPIs ccf3ee22_i 6cee8ea4_o and TS 10.0.0.18/32 === 10.0.0.17/32

*Remote node initiating the CREATE_CHILD_SA request*
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)
Aug  7 06:59:12 hn0 charon: 12[ENC] parsed CREATE_CHILD_SA request 21 [ SA
N(USE_TRANSP) No TSi TSr ]
Aug  7 06:59:12 hn0 charon: 12[IKE] traffic selectors 10.0.0.18/32 ===
10.0.0.17/32 inacceptable
Aug  7 06:59:12 hn0 charon: 12[IKE] failed to establish CHILD_SA, keeping
IKE_SA
Aug  7 06:59:12 hn0 charon: 12[ENC] generating CREATE_CHILD_SA response 21
[ N(TS_UNACCEPT) ]
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)

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

--karuna

On Fri, Sep 4, 2020 at 1:38 AM Tobias Brunner <tobias at strongswan.org> wrote:

> Hi Karuna,
>
> > The issue is intermittent
> > and possibly coincides with ipsec reload command execution used when we
> > make changes in the ipsec.conf file.
>
> Don't use `ipsec reload`, if anything use `ipsec update` as it only
> affects the actually modified configs.  Either way, there are known
> issues with rekeying if configs are modified (see e.g. [1], as mentioned
> there, using swanctl.conf might work better if that's the issue).
>
> > We haven't seen this between Linux
> > nodes. From the syslog, we see the TS_UNACCEPT error. One of the Windows
> > expert in the team captured netsh logs and he mentioned that the Linux
> > node is sending a traffic selector with UDP protocol port 1025
> > specifically, which is probably leading to TS_UNACCEPT. This is
> > unexpected, since we are expecting all protocol and port to be under
> > IPSec. However, don't understand why this is intermittent.
>
> That indicates a different problem.  If the trap policy (auto=route) is
> triggered (initially or after a failure), the first traffic selector
> sent is derived from the matching packet (which includes protocol and
> ports).  If the remote server can't handle that, you may enable
> charon.ignore_acquire_ts in strongswan.conf to avoid sending these
> traffic selectors.
>
> > Is there a property to specify the traffic selector explicitly in
> > ipsec.conf?
>
> There are obviously left|rightsubnet but for transport mode SAs you only
> have to configure them if you actually want to restrict protocol/port.
>
> Regards,
> Tobias
>
> [1] https://wiki.strongswan.org/issues/1338#note-3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20200904/ff00368e/attachment-0001.html>