SM K <sacho.polo@...> writes: > Some changes we did: > These are changes we did to fix the issues in our setup. Some of these are hacks to prevent us from making big code changes in strongswan. > 1. To fix issue#1 above, we wanted to use only those transforms in the payload that match the configured auth method in the connection definition. It was not possible to get the configured auth method from ike_cfg_t in the MM_INIT state of the process_r in main_mode.c. The auth method is kept in peer_cfg and it is not possible to get to peer_cfg at this point of the handshake. ike_cfg_t does not have a reference to peer_cfg_t. Since our connections are added via stroke_config.c, we added code in stroke_config.c where the peer_cfg and ike_cfg are created. This code will calculate the auth method from the configuration and add this to the ike_cfg_t. So, when we are matching proposals in main_mode.c to the proposals (transforms) in the payload, we have access to the configured auth_method and we only make a list of proposals to match that have the same auth method as the connection definition auth method. If a proposal selection from this list fails, we fall back to the way strongswan did it before and match other proposals. This is something of a hack, but we did this to make minimal or less intrusive changes to strongswan code. > 2. Once a proposal was chosen that matched the correct auth method, we still had a problem with improper lifetime and transform number in the response from Strongswan (issue 2 and 3). When strongswan creates a list of proposals from the transfroms in the payload (proposal_substructure), it does not maintain the transform number from the original message. So we added a field in proposal_t structure that has a transfrom number, which defaults to 1. We use this transfrom number as the key (alone with proposal number) to get the proper lifetime to use in the response and to put in the proper transfrom number in the response. > > These changes, along with the change in connection definition (mentioned in issue 4), allowed us to successfully respond to the FWs in our test setup mentioned in the beginning of this mail. Hope this helps anyone who has a similar problem. > > cheers, > sk
Hi SM, Thanks for sharing this information. We have also run into these issues when testing against Cisco IOS. Can share your code changes ? Thanks Ajay _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
