Will pfSense implement multiple IPsec Mobile Phase 1
-
if not 2.4 (alpha i am using has no signs of that), then someday? :)
Related
https://forum.pfsense.org/index.php?topic=80354.0
https://forum.pfsense.org/index.php?topic=57104.0Usage:
- Multiple WAN
- Splitting up IKEv2 clients in different subnets (each having different "permissions")
- Splitting up IKEv2 clients in different auth methods (cert for normal users, passbased for easy client setup on different OSes for fast "one day access giveway")
- IKEv2 as main, but parallel L2TP/IPsec legacy support possible (although i'm dropping L2TP for good, it may creep up someday, having multiple mobile phases 1 would make running IKEv1 and IKEv2 simultaneously possible)
Thanks!
-
When it actually works in strongSwan in a way we can leverage from the GUI :-)
So, someday, sure.
Last time I tried it, which admittedly has been a year or so, it didn't work in a way that would be acceptable. It has to pick a connection based on what it can see in the initial exchange, and there was not enough information available at that stage to allow similar instances that only differed in backend config (e.g. authentication).
Maybe one IKEv1 and one IKEv2 could work, I didn't try that. It's probably too late for a new feature like that to make 2.4 even if it was tested and proven to work.
-
Thanks for the clear answer!
Should I push such feature request somewhere or is it already on developers radar? If yes, then in redmine? (I bought gold subscription few days ago as a way to say thanks, it does not seem that there are some seperate "paid" cahnnel as stated here?)
EDIT: I see, gold is smth different as "Per-Incident Support" subscription, and the "Support customers" are meant to be the latter, right?
-
We don't do any on-demand development for customers these days like that wiki page implies. Though we do consider features needed by customers more carefully, developer time is still a limited resource.
I believe there is already a redmine feature request open for this, but it might take some searching to find.
-
Just searched more carefully. These are questions in forum, which +/- deals with the same stuff
https://forum.pfsense.org/index.php?topic=119403.msg660675#msg660675
https://forum.pfsense.org/index.php?topic=69357.msg379212#msg379212
https://forum.pfsense.org/index.php?topic=119393.msg660638#msg660638
https://forum.pfsense.org/index.php?topic=101889.msg568311#msg568311The last links to this ticket which has been added on 10.07.2015
https://redmine.pfsense.org/issues/4826Which is not "the same" in the sense that my main reason "why it would be beneficial" is actually spiltting auth types, not "algorithms" although they go hand in hand.
-
I'm curious, was looking at the IKE peer identifier tried as a way to distinguish between policies. I used this method on Cisco's IKEv2 implementation as a means of distinguishing between Microsoft's IKE ID of remote ip address using 0.0.0.0 (i.e. any ip address), Strongswan presents the EAP username as the remote fqdn, and Cisco Anyconnect using key id which can be entered manually.
This allowed me to 3 separate policies. Also, it allowed me to reference a single algorithm policy with several configured so that the client can use the strongest one.
