Hi Noam, > When peering two instances of this code with each other, I have a race > where one instance believes that it has a valid outgoing child_sa, and the > other does not yet recognize this SPI.
When initiating connections from both ends, you should take care to avoid having two tunnels established. An appropriate uniqueids policy can help, but preferably you should avoid initiating connections simultaneously from both ends. Having clear initiator/responder roles is certainly a good idea, alternatively you might want to install IPsec trap policies to trigger connections on demand. > I believe the reason for this race is that both sides have initiator=false I don't think there is an "initiator" option. Do you refer to the "initiator_only" strongswan.conf setting? If that is set to "yes", libcharon does not accept any IKE_SA_INT request messages, but allows active connection initiation only. > and are installing the child-sa from build_r() - whereas the intention was > that one side would have initiator=true and install the SA only in > process_r(). When establishing a connection, the responder installs the CHILD_SA while building the last IKE_AUTH (or CREATE_CHILD_SA) message. The initiator installs the SA while processing that last message. So in theory it might happen that the responder already uses the SA before the initiator has the same SA installed. Usually this is not much a problem, but can happen when the IKE packet is delayed or gets lost and must be retransmitted. Regards Martin _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
