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
