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

[Ajay]

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.
> 
> 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