<div dir="ltr"><div>This is a follow up on an earlier email I had sent to the group. I am listing out some issues we saw when we tested with Cisco (a 891) and Juniper (SRX) firewalls when the firewalls were initiating Main Mode (ikev1) connections with multiple transforms in a proposal. This was in our test setup. I am listing it here for the benefit of others who might have seen similar issues or have similar setups. We have fixed this in our setup in a certain way that works for us, but the proper fix could be more elaborate. The setup described below used to work well with Strongswan 4.x, but broke when we moved to Strongswan 5.x.x .<br></div><div><br></div><div>Test Setup: </div><div>Strongswan is the responder and is configured with connection definitions that are specific to the FW sites. The connection definitions could either one of PSK or Cert authentication. FWs are usually configured to match this connection definition and that is the only proposal they exchange when they initiate main mode. Everything's dandy in this case. However, we saw issues when the firewalls are confgured with multiple proposals, that could do other types of authentication. For example, the cisco could be configured to do cert authentication to someother firewall and do PSK with our strongswan endpoint. The policy number in the configuration dictates the order in which Cisco sends the transforms in the proposal in the initial contact message.</div><div><br></div><div>The issues we saw are:</div><div>1. Strongswan finds the first acceptable transform from the list of transforms sent in the main mode message, irrespective of the auth method in the transform. So if the firewall sends RSA-SIG as the first proposal, followed by a transform with PSK, strongswan chooses the RSA-SIG transform from the message, if the encryption algo, dh group and hash algo match, even though the connection definition says the site is a PSK site. It then uses the auth method and lifetime from the first transform to respond. If causes the firewall to do cert authentication, which may fail because the firewall was not configured to do cert authentication with our strongswan endpoint.</div><div>2. Strongswan uses lifetime from the first transform in the payload to respond, irrespective of the transfrom chosen. This caused the Juniper to fail because the transform chosen did not match the transform it sent. Cisco did not seem to care.</div><div>3. Strongswan always sends the transform number 1 when it responds to the main mode initiation, irrespective of the transform chosen. This caused Cisco to fail, while Juniper did not care.</div><div>4. This was more of a confiruation issue, but when we configured the site in strongswan, the connection definition used right and left auth to specify PSK authentication. Even after we fixed the above issues, Cisco still failed, because strongswan was sending CERTREQ in the fourth handshake message (key exchange) when it was doing PSK. We found that adding "rightsendcert=never" in the connection definition fixed this problem. This was a problem only when talking to Cisco and not Juniper.</div><div><br></div><div>Some changes we did:</div><div>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.</div><div>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.</div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>cheers,</div><div>sk</div></div>