Key Exchange version "Auto" isn't really useful, remove it.
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.
Remove "auto", it's just a synonym for IKEv2. Ticket #4873
#1 Updated by Chris Buechler almost 5 years ago
- 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.
#2 Updated by Chris Buechler almost 5 years ago
- 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.
#6 Updated by Chris Buechler almost 5 years ago
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.
#7 Updated by Denny Page almost 5 years ago
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.
#9 Updated by Denny Page almost 5 years ago
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.
#12 Updated by Denny Page almost 5 years ago
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.