Hi Simon, > From the syslog, it would seem once a possible candidate is picked (by > their order in ipsec.conf), the proposal > selection would not look at the other conns that are also > 192.168.3.193...%any. Is this true?
Yes, the current selection algorithm is very simple and based solely on the IP addresses. This leads exactly to the situation you described. > If true, any suggestion how I can get tunnels with different ciphers > co-exist? Ideally modify the code to go back and pick another > <my_ip>...%any candiate is best for my application. Or perhaps I ban > strict mode when right=%any? We could change the code and consider the proposals sent by the client but that would require quite some refactoring. And it wouldn't really improve the situation much. You simply can't enforce an IKE proposal for a specific client other than by its IP address (the IDs are exchange only after the IKE proposal is selected). The config in ipsec.conf might be a bit misleading on that part, as you define IKE_SA and CHILD_SA options in the same conn section, but in reality these are used separately by charon (first only the IKE part is considered and once the IDs are known the proper CHILD config is selected which might not be from the same conn section in ipsec.conf). Therefore, you might want to rethink why you want to use strict mode as responder for road warriors (i.e. with right=%any). If you don't like charon's default proposal you could, of course, define a strict proposal that contains all the proposals you allow for any of the road warriors (e.g. ike=aes128-sha1-modp1536, aes128-md5-modp1536! which could also be written as ike=aes128-sha1-md5-modp1536!). Regards, Tobias _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
