Project

General

Profile

Actions

Feature #13227

open

Enable IPSec Virtual IP Pool assignment by Radius for Mobile Users - SIMPLE FIX

Added by Tue Madsen almost 2 years ago. Updated about 15 hours ago.

Status:
New
Priority:
High
Category:
IPsec
Target version:
Start date:
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
24.03
Release Notes:
Default

Description

Currently you cannot create additional Virtual IP Pools to assign mobile users IP addresses from, if you are using EAP-Radius as the authentication source.
This prohibits using different firewall rules for different groups of users.
Everyone is treated the same, unless you specifically assign a static IP to a specific user from Radius via framed-ip-address - which is NOT scalable.

But all the logic is enabled in strongswan, and the GUI settings to swanctl.conf scripts already has enabled the groups features in strongswan, so it will accept the "Class" attribute from Radius as a groups identifier.

There just needs to be a way to create a groups identifier in the GUI with an attached IP Pool that is written correctly to the config files.

By hacking /etc/inc/ipsec.inc I have enabled this by asking the "preshared secrets" GUI part to write an EAP Shared secret as a "groups" in the remote section instead of an "id".
All I did is the following edit in /etc/inc/ipsec.inc":
Locate the major section called: "/***f ipsec/ipsec_setup_userpools" about halfway into the file.
Locate the line: "$scconf['connections'][$upconn]['remote']['id'] = $clientid;"
Change it to "$scconf['connections'][$upconn]['remote']['groups'] = $clientid;"

Once that is done, if you enable "group authentication" on your mobile clients settings, groups identifiers returned with the "Class" attribute is respected, and the user is assigned an IP from the custom pool. Default users are still assigned IPs from the default mobile warrior pool if the Radius return the group(s) name selected in the mobile clients setup.

A very quick fix to this issue would be to add a new "Groups" tab in IPsec where you can add a group identifier and the IP Pool to use for that group. It can use most of the same script parts from "/***f ipsec/ipsec_setup_userpools" in ipsec.inc - it just needs to create the line in the remote part of swanctl.conf with 'groups' instead of 'id'.

Actions #1

Updated by Tue Madsen almost 2 years ago

I Should mention you can use my modifcation afterwards by creating the groups identifier and IP pool needed, by creating a "EAP Shared Secret" with an IP Pool.

If you return your created identifier with the "Class" attribute from Radius, the user is assigned an IP from your new custom pool.

You can read the more elaborate explanation on my modification here: https://forum.netgate.com/topic/172476/a-guide-to-assign-vpn-group-and-user-ip-pool-from-radius-in-22-01-2-6

Actions #2

Updated by Tom Huerlimann over 1 year ago

I posted in the netgate forum about this functionality and got redirected to this record.

https://forum.netgate.com/topic/174957/ipsec-vpn-radius-authentication-via-nps-using-class-property-returned-by-radius-in-firewall-rules

To make this work, it requires manual modifications of the /etc/inc/ipsec.inc file, not surviving any pfSense update.

I post my comment here to give more weight to this feature request.

I'm respectfully requesting an out-of-the-box solution by extending the GUI to configure such scenarios, with the goal to not to loose such configurations after an update.

Actions #3

Updated by Christopher de Haas 11 months ago

I very much hope to see this in an upcoming version. We currently have to use openvpn instances or full pfSense instances to have multiple “types” of mobile client's, but radius assigned IP pools for ipsec is really what we need. I am borderline considering pathing the proposed solution, but obviously can't really do that in production. Really looking forward to a solution here.

Actions #4

Updated by Tue Madsen 11 months ago

Christopher de Haas wrote in #note-3:

I very much hope to see this in an upcoming version. We currently have to use openvpn instances or full pfSense instances to have multiple “types” of mobile client's, but radius assigned IP pools for ipsec is really what we need. I am borderline considering pathing the proposed solution, but obviously can't really do that in production. Really looking forward to a solution here.

Thank you for upvoting this request. It’s baffeling that pfSense does not have this feature yet - I have been asking for years about it because this is the number one reason why I have to install other products than pfSense at different customers.
It may not change your position, but I have about 25 customers using my fix to allow IP-pools use in Mobile IPSec VPN, and it really works beautifully. The “hack” does not influence anything else, and it remains solid regardless of restarts and what not. The only thing that disables it is a version upgrade/reinstall of pfSense itself. Then you have to reapply the fix.
I don’t expect this feature to surface in pfSense any time soon as the initial interest Netgate showed has faded away with the challenges of migrating to FreeBSD 14 and PHP 8.1
But maybe someday - who knows. Until then this is an “easy to use” way of getting what we all need.

Actions #5

Updated by Tue Madsen 20 days ago

@Netgate - is there zero chance of this simple but VERY usefull feature to surface in pfSense? Some of your people have shown a lot of interest in bringing it to production, but have since then forgotten it. I don’t understand how such a VITAL feature for any firewall VPN solution is missing in pfSense.

Actions #6

Updated by Jim Thompson 13 days ago

we're looking at sneaking this in for 24.03

Actions #7

Updated by Jim Thompson 13 days ago

  • Target version set to 24.03
  • Plus Target Version set to 24.03
Actions #8

Updated by Reid Linnemann 3 days ago

  • Assignee set to Reid Linnemann
Actions #9

Updated by Reid Linnemann about 15 hours ago

I started down the path of including this using the key identifier and using the identifier as the 'groups' value instead of 'id' if group auth was selected, but I wasn't happy with it. I've instead implemented a separate tab dedicated to defining group pools. It is a bit rudimentary because I haven't refactored out the root mobile config, so at least one group pool must be properly defined using the group selection and pool definition in the mobile ipsec tab. The also user must take care to not alias groups, or unexpected configuration behavior can result. Short of a complete refactoring of the strongswan conf generation I think this strikes a good balance of usability without drastically overhauling the code. The change is under review and should be present in 24.03-BETA.

Actions

Also available in: Atom PDF