Tobias Brunner

That backtrace looks weird. In 5.8.2 (and the current release, too, since that file has not change since then), line 175 in `sender.c` is not in `send_packets()`, but `flush()`. And...

No idea, could also just be a bug in the glibc implementation. I doubt this TSX stuff saw widespread use (or real-world testing). [According to Wikipedia](https://en.wikipedia.org/wiki/Transactional_Synchronization_Extensions#History_and_bugs), the TSX extension was...

Yeah, renames are tricky because several things in the IKE daemon are name-based (one example are trap policies, but connections in general are manged by name). So I'd recommend to...

> They are auto generated by our provisioning system, which expands two lists of local and remote subnets to individual child SAs that cover all possible combinations. Is that for...

Yes, established connections are not (or only partially e.g. for child configs as responder) affected by config changes (not only in regards to renames). And as discussed before, the installed...

> the new connection that was re-established _after_ the renames had taken place kept on using the old names. Again, that's because the trap policies are not updated/renamed. They still...

Could you write more about the use case for this?

Couldn't you achieve the same thing, and even more controlled, with passthrough policies? Either configured with strongSwan or manually installed via `ip xfrm policy`. It would also not require a...

If you install the passthrough policies manually they will just be replaced by the actual IPsec policies installed by strongSwan once the connections get established (given the selectors match). You'd...

> We are using auto=route, which makes strongSwan install the IPsec policy as soon as it starts. Is there something we're missing? Aren't you using the wildcard trap policies you...