[strongSwan-dev] Some issues we have seen with Main Mode IKEv1 with Cisco and Juniper firewalls.

[SM K]

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 .

Test Setup:
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.

The issues we saw are:
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.
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.
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.
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.

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20150713/566770fb/attachment.html>