Feature #13227
closedGroup-based Mobile IPsec Virtual Address Pool assignment via RADIUS
100%
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'.
Updated by Tue Madsen over 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
Updated by Tom Huerlimann about 2 years ago
I posted in the netgate forum about this functionality and got redirected to this record.
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.
Updated by Christopher de Haas over 1 year 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.
Updated by Tue Madsen over 1 year 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.
Updated by Tue Madsen 9 months 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.
Updated by Jim Thompson 9 months ago
we're looking at sneaking this in for 24.03
Updated by Jim Thompson 9 months ago
- Target version set to 24.03
- Plus Target Version set to 24.03
Updated by Reid Linnemann 8 months 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.
Updated by Tue Madsen 8 months ago
This a fabulous ♥️ Unfortunately I’m away for a couple of weeks right now, so I won’t be able to participate in betatesting until I’m back. But I’m sure it’s solid as my former fix worked very well - so I assume this will likewise work as intended.
Updated by Marcos M 8 months ago
- Subject changed from Enable IPSec Virtual IP Pool assignment by Radius for Mobile Users - SIMPLE FIX to Support Mobile IPsec Virtual Address Pool assignment via RADIUS
- Status changed from Feedback to Resolved
- Target version deleted (
24.03)
This is working as expected. Note that strongswan's eap-radius
plugin only supports specifying a single group for a user in the RADIUS reply (e.g. Class := "vpnusers"
).
Updated by Jim Pingle 8 months ago
- Project changed from pfSense to pfSense Plus
- Category changed from IPsec to IPsec
- Target version set to 24.03
- Plus Target Version deleted (
24.03)
Updated by Jim Pingle 8 months ago
- Subject changed from Support Mobile IPsec Virtual Address Pool assignment via RADIUS to Group-based Mobile IPsec Virtual Address Pool assignment via RADIUS
Updated by Reid Linnemann 8 months ago
Tue Madsen wrote in #note-11:
This a fabulous ♥️ Unfortunately I’m away for a couple of weeks right now, so I won’t be able to participate in betatesting until I’m back. But I’m sure it’s solid as my former fix worked very well - so I assume this will likewise work as intended.
I'm hoping it's even more useful, as better validation is also being introduced to prevent pool and group collisions to help alleviate some of the confusing invalid configurations that could be generated in the past (and could have been introduced by another source of connections and pools). I'll look forward to seeing your feedback.
Updated by Jon McKinney 7 months ago
I am having issues creating multiple groups. I just installed the plus 24.03 RC last night on my box at home so I can test this feature. We have been waiting for this for some time since we have a lot of remote workers who connect over VPN for various reasons. The error I get is below. Even though the group names and subnets are not even similar.
The following input errors were detected:
Another entry with the same group(s) already exists.
Can you guys recreate this?