Hi Marc, > I'm using a quite symmetric configuration where both gateways with > strongSwan 5.1.1 have the auto=start in configuration in order to force > tunnel being up asap.
Having auto=start on both ends is not unproblematic, as it can result in collisions for IKE and CHILD_SAs. If you really need it, you should check the uniqueids ipsec.conf option, that can ensure that you don't end up in multiple IKE_SAs for the same peer (but read below). > On the logs when falling in the case a), we can see: [CFG] unable to > install policy 12.0.0.0/8 === 11.0.0.0/8 out (mark 0/0x00000000) for > reqid 2, the same policy for reqid 1 exists. When falling in case b) > there is no such log. This error does not have to be bad. The Linux kernel can't handle identical selectors on policies for different SAs, hence they get rejected. Usually this leads to a situation where any redundant CHILD_SA gets rejected. As it is redundant, that shouldn't hurt. However, there are some race conditions that can occur, rejecting both tunnels. > Specifying a reqid in ipsec.conf on both gateways seems to fix the > problem This can work, but it will lead to multiple CHILD_SAs for the same selectors. My recommendation is to reconsider having auto=start on both ends. There is not really a clean way to avoid any duplicates with that approach. And rejecting duplicates usually implies that you'll have race conditions where both peers reject the "other" duplicate, and you end up with no tunnel. Having auto=route on both ends usually works fine: It makes sure no plain traffic leaves the box, and the kernel re-triggers SAs should it fail for whatever reason. Regards Martin _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
