Bug #4873
closed
Key Exchange version "Auto" isn't really useful, remove it.
Added by Jim Pingle almost 9 years ago.
Updated almost 9 years ago.
Affected Architecture:
All
Description
With "Key Exchange version" set to Auto in IPsec Phase 1, the Mode setting is set to Main in the GUI even if Aggressive was chosen and saved.
If the setting isn't relevant to Auto, it should be hidden, or the value stored and used properly.
- Subject changed from Unable to change Mode of Phase 1 when "Key Exchange version" set to Auto to Key Exchange version "Auto" is really just IKEv2 synonym, remove it.
- Status changed from Confirmed to Feedback
- Assignee set to Chris Buechler
- Affected Version changed from 2.2.4 to 2.2.x
removed, and upgrade code added to convert. Should be good now.
- Subject changed from Key Exchange version "Auto" is really just IKEv2 synonym, remove it. to Key Exchange version "Auto" isn't really useful, remove it.
strongswan 5.x versions do have a concept of 'auto' in that they'll accept either v1 or v2 as responder, use v2 only as initiator. Not a desirable feature as it was previously implemented, but updating this accordingly.
- Status changed from Feedback to Resolved
Hate to disagree, but auto is indeed useful. Removal breaks the ability to mix IKEv1 and IKEv2 mobile clients.
It would be useful if it was actually auto. It's not. It's a synonym for IKEv2 in strongSwan. Needs fixed upstream.
it being a synonym for IKEv2 was only true of pre-5.x strongswan versions (see my above comment). But still it wasn't useful as implemented.
Having the ability to define multiple mobile P1s is the answer for simultaneously supporting IKEv1 and v2 mobile clients.
While I haven't reviewed the strongSwan code, I can attest that operationally auto is not a synonym for IKEv2. I've been using auto with IKEv1 only iOS and Mac clients beginning with the 2.2.2 release. Others have replicated the config as well.
Info beginning here: https://forum.pfsense.org/index.php?topic=92197.msg518104#msg518104
I'm happy to share my 2.2.3 xml config for testing.
there were a variety of problems with that implementation. we'll properly implement it in the future.
Forgive me for being direct...
The existing solution may not have been proper, but it did work and was very useful. Multiple phase one mobile entries may be a good and proper future solution, but removing the existing solution without a replacement being available is inappropriate.
We are left with fielded mobile units that are now completely broken. With no migration strategy available. This kind of thing makes it very difficult to argue the viability of pfSense in a commercial setting.
given the issues with it, I assumed no one could have been successfully using it. Sorry that was a wrong assumption in your case. Patching vpn.inc and vpn_ipsec_phase1.php to undo that commit is a viable alternative in the mean time.
Thank you Chris. Is there anything I could put in via system patches rather than hand editing files?
As a temporary measure, I have backed out commit 4d7568404c276ea8fd10583e8d769f5ba82587aa by hand for testing. This, combined with a config change to set Peer Identifier to Any, again works.
I would be very grateful if this could be restored for 2.2.5. Thanks.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by