A Guide to assign VPN group and User IP Pool from Radius in 22.01/2.6 :-)

[keyser]

Hi All.

I have been massively annoyed by the fact that netgate never enabled the ability to assign several IP pools to the mobile warrior IPSec configuration, and have Radius return either the poolname or some other attribute to select which IP range a VPN user is assigned an IP from.
That way you can build firewall rules by "groups" of users based on which IP range they are assigned an IP from.
You can return the framed-ip attribute, but that requires you to assign static IPs to all users on the Radius side -> NOT scalable :-)

So I just spent the better part of a day to figure out what the strongswan IPsec engine supports, and what is actually configured with the default pfSense IPsec scripts that builds the strongswan configuration.

Turns out that the default netgate scripts that builds the strongswan config files, are VERY close to allow for IP pool assignments from radius via a groups identifier - They only need a little tweak to accomplish it, and here's how:

BASICS:
Strongswan already supports multiple IP pools based on group identifiers for users, and it also supports returning a group indentifying attribute from Radius called "Class". Netgate just never made the GUI settings and script functionality to enable it. Unfortunately the Netgate IPSec scripts build the strongswan config files at every service restart, so there is no use in editing the config files directly yourself. We need to modify the scripts that builds the config files.

FUNDAMENTALS:
If you enable “group authentication” on your Mobile Clients tab in IPsec, you can select any group created locally in pfSense that has the "IPsec xauth Dialin" privilige assiged. With this enabled general radius authentication no longer suffices - you have to return the group name selected from Radius via the "Class" attribute.
Parallel to that, pfSense already have all the GUI settings needed to create additional IP Pools - but only if you create a preshared EAP secret under the “preshared secrets” tab. This has no use and is ignored if you run Radius authentication, BUT:

It actually creates the IP pool and all the needed selector info in the strongswan configuration files. We just need to tweak what it writes in the connection selection, so the preshared secret is saved as a groups identifier instead if a userID.
That way it can be used for IP address pool selection at authenticationt time based on the indentifier entered - if you return that identifer via the “Class” attribute from Radius.

Originally when you create a preshared userID and key, it creates a specific "id" in the strongswan configuration file, that causes the connection selection to use your configured pool based on the identifier, if that specific userID establishes an IPsec tunnel (Does not work for Windows Clients though).
I modified the ipsec.inc file that defines how this identifier is written to the strongswan configuration file, and asked it to write the "identifier" as a "groups" identifier instead of an "id", and voila - you can now create pools and return the groups identifier value with the "Class" attribute in Radius - YAY!

It easily done by editing the /etc/inc/ipsec.inc file in pfSense.
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;"
Save the ipsec.inc file and you are good to go!!

All you need remember is:
1: Enable group based authentication on your Radius enabled Mobile client config. Any group you select in the local group list becomes the default group name you must return via the "Class" attribute from radius, if users needs to belong to the default IP pool setup in mobile clients.
2: Define any new pools under "Preshared secrets" by creating a new EAP type preshared secret with a pool - remember the "identity" is now the group name you need to return via the "Class" attribute". The PSK key is ignored and not used in this setup, but must be filled with something random :-)

This config will not survive a pfSense version update as the ipsec.inc file is replaced at that time - so you would need to repeat the config again.

I have created a Redmine post: https://redmine.pfsense.org/issues/13227

Please upvote to have netgate add this group selection feature to IPSEC. It's a MAJOR gain in functionality for larger corporations!!

[keyser]

@stephenw10 said in State of the Union (in pfSense land) - Opinions?:

Ok, that doesn't seem unreasonable. Obviously we are all hands on deck working on 22.05 right now but once that's released we can look at other things.

How would you anticipate that feature appearing?

What would you do for mobile IPSec if you could have anything? What are the common scenarios you see that could be solved?

If, for example, we added a mobile IPSec wizard of some sort to simplify the setup what should it cover? Given that it could probably only accommodate a few scenarios.

Steve

Hi Steve

VERY glad to hear you would consider fixing this

But to be honest: The current UI state of Mobile IPSec VPN is a mess…. A terrible mess…
You can configure/enable things on the “tunnel phase 1” or in “Mobile Clients” that is completely nonsense depending on the configuration of the other - not to mention several tunnel settings that really only makes sense in S2S. So unless you know what you are doing, Mobile IPSec is pretty confusing and not very helpfull.

So to answer your question: I see two ways of doing this:

1: The easy fix where we just add another messy option, that can cause further confusion unless you know what you are doing.

2: Do the MAJOR UI overhaul for Mobile IPSec and Xauth/EAP integration to local pfSense User/EAP databases. This would entail a lot of work and a whole new selection driven way of configuring Mobile IPsec. If you are willing to consider this, I would love to help out organising the UI design and feature integration.

HOWEVER: I would very much prefer that the easy way is added/fixed as fast as possible, and then time will tell when a release is available where Mobile IPSec is done right :-)

For the easy minimal fix I see two two options:

• “Baremetal absolute minimum” would be to (pretty horrible design solution but it will work):
  1: Under “Preshared Secrets” create a third option in the selector called “IP Pools” and let us enter a pool identifier and pool settings. This is written to swanctl.conf as only a remote “groups” override of default mobile con settings, and a corresponding IP Pool.
  2: Keep everything else as it is but perhaps rename the “Preshared Secrets” Tab to “Preshared Secrets & IP Pools”

• “The better minimal solution” would entail the following changes, and link to a docs page that explains the correlation between IP Pools, their Identifiers, Xauth use of pfSense Local Groups, EAP Options and The Radius Class Attribute (still pretty confusing, but at least workable):
  1: Rename the “Preshared Keys” tab to “Local PSK and EAP Secrets”
  2: Strip the IP Pools settings from EAP enties in the preshared Secrets Tab.
  3: Add a “IP Pools” Tab where you can enter pools (groups) identifiers with corresponding IP Pool settings. Preferably with IPv4 and IPv6 options so it’s not IPv4 only.
  4: Add a IP pools selector to each EAP Secret created in “Local PSK and EAP Secrets” that connects that ID to a created pool instead of creating a different pool of it own.
  5: Rename the “Group Authentication” enabler in “Mobile Clients (Xauth)” to “Enable Groups Authentication and IP Pools assignment”
  6: If this is ticked, remove the “Virtual Address pool” and “Virtual IPv6 Address Pool” fields on this page (in Mode-cfg), and force the admin to select which previously created IP Pool to use for the groups selected (The selected pool is then entered into the default con-mobile settings as the default pool)

It’s not pretty, I know, but the whole IPSec mobile UI is full of contradictions and setting/options that makes NO sense depending on settings you have made elsewhere. At least this second option would clean it up just a little bit :-)

On another note:

The BY FAR most common scenario that needs resolving is being able to create different firewall rules for different VPN users - regardless of the Authentication method.
For the long term “right” solution with a major UI redesign, the most important thing would be that use of IP Pools is respected across authentication methods - so you can always use IP Pools for both IPv4 and IPv6.
The UI redesign would need to split IPSec VPN into two main tabs: “Site 2 Site IPSec” and “Mobile IPsec”. This would remove the mobile tunnel from the site 2 site tunnels tab.
It would allow the UI design on Mobile IPSec to automatically integrate mobile tunnel, source and authentication selections (remove contradicting options/selections as you go along) into the mobile tunnel settings.
In effect it would combine Mobile Client settings and Phase 1/2 mobile tunnel settings to one UI.

WISHLIST OBSERVATION: Since there can be only one Mobile IPSec tunnel, the current implementation of “Mobile Clients” -> “User Authentication” in IPSec is pretty confusing, because the “local database” or any Radius server selected, means vastly different things - and i sometimes void - depending on the authentication method selected in Phase1 settings under the Mobile IPSec Tunnel.
Maybe that selector should be expanded to select between “Local database (Xauth/PAP)”, “Local preshared Secrets (MSchapv2/EAP)”, “Remote Radius Users (Xauth/PAP/MSchapv2)” and “Remote Radius Server (EAP) ? - If a Radius Option is selected, let the user select between defined Radius servers.
The key here is to remove nonvalid options you can actually select in Phase1 on the mobile connections tunnel - depending on what you selected in “User Authentication”.
FX: No EAP options if local pfsense users is selected, No Xauth options if a EAP option is selected? It would with a simple stroke remove a lot of the confusing contradictions currently present.

Let me know what you think :-)

[keyser]

@stephenw10

Please don’t forget this for the next release of pfSense :-)

Let me know if there is additional information or confirmation you need for this :-)

[keyser]

@keyser @stephenw10 - I hope this little fix is not forgotten? I have seen no acceptance of the redmine ticket.