[strongSwan] Some issues we have seen with Main Mode IKEv1 with Cisco and Juniper firewalls.
ajay.grewal at ge.com
Mon Sep 28 21:19:48 CEST 2015
SM K <sacho.polo at ...> 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.
Thanks for sharing this information. We have also run into these issues
when testing against Cisco IOS. Can share your code changes ?
More information about the Users