Project

General

Profile

Actions

Bug #4873

closed

Key Exchange version "Auto" isn't really useful, remove it.

Added by Jim Pingle almost 9 years ago. Updated over 8 years ago.

Status:
Resolved
Priority:
Normal
Category:
IPsec
Target version:
Start date:
07/23/2015
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.2.x
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.

Actions #1

Updated by Chris Buechler almost 9 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.

Actions #2

Updated by Chris Buechler almost 9 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.

Actions #3

Updated by Chris Buechler almost 9 years ago

  • Status changed from Feedback to Resolved

fixed

Actions #4

Updated by Denny Page over 8 years ago

Hate to disagree, but auto is indeed useful. Removal breaks the ability to mix IKEv1 and IKEv2 mobile clients.

Actions #5

Updated by Jim Pingle over 8 years ago

It would be useful if it was actually auto. It's not. It's a synonym for IKEv2 in strongSwan. Needs fixed upstream.

Actions #6

Updated by Chris Buechler over 8 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.

Actions #7

Updated by Denny Page over 8 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.

Actions #8

Updated by Chris Buechler over 8 years ago

there were a variety of problems with that implementation. we'll properly implement it in the future.

Actions #9

Updated by Denny Page over 8 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.

Actions #10

Updated by Chris Buechler over 8 years ago

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.

Actions #11

Updated by Denny Page over 8 years ago

Thank you Chris. Is there anything I could put in via system patches rather than hand editing files?

Actions #12

Updated by Denny Page over 8 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.

Actions

Also available in: Atom PDF