State of the Union (in pfSense land) - Opinions?

keyser

This post is deleted!

NogBadTheBad

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

@mcury You can't. The Framed-ip-pool attribute is not supported by pfSense IPSec (Strongswan).
You can only return Framed-ip-address - ie: static IP addresses pr. user.
That works just fine, but does not scale beyond 5 - 10 users unless lots of manual labor and lots of reserved addresses is your thing ;-)

What you can do is returning the "class" attribute with a groups name that strongswan can use for IP pool Selection. But it's not supported in pfSense now, so you have to apply my "hack":

https://forum.netgate.com/topic/172476/a-guide-to-assign-vpn-group-and-user-ip-pool-from-radius-in-22-01-2-6

I put the following in for a FreeRadius copy & paste in 2017 and its still open, it would help if you had loads of user to add.

https://redmine.pfsense.org/issues/8031

stephenw10

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

mcury

Its working, just tested...
Edited the ipsec.inc as indicated by @keyser

Observations:

test is the name of the identify created in preshared keys (pfsense), pool 172.16.98.128/25
test2 is the second identify created in preshared keys (pfsense), pool 172.16.98.0/25
freeradius is not running in pfsense, only ipsec road warrior is.
I had to enable accounting in ipsec tab.
member of AD group pfsense_admins get an IP from the pool (172.16.98.128/25)
member of AD group vpn_access gets an IP from the pool (172.16.98.0/25)

Unlang code used:

        if (LDAP-Group == "pfsense_admins" && NAS-Port-Id == "con-mobile") {
         update  {
                reply:Class := "pfsense_admins"
#                reply:Framed-IP-Address := "172.16.98.100"
#                reply:Framed-Netmask := "255.255.255.0"
                 reply:Class := "test"
        }
                noop
        }
        elsif (LDAP-Group == "vpn_access" && NAS-Port-Id == "con-mobile") {
          update {
              reply:Class := "vpn_access"
              reply:Class := "test2"
        }
                noop
        }

keyser

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

Its working, just tested...
Edited the ipsec.inc as indicated by @keyser

Excellent proof that I was contemplating writing myself - to make sure people trusted my tests. It does work perfectly.

The only real “caveat” is that you are forced to also assign the default users/default pool on the “Mobile Client” tab a groups id (enable group authentication and select a group name to use - and return from Radius).
If you dont, everyone would land in the default pool because that is the first connection test (top of connection entires) in Strongswan, and everyone would qualify for that if there is no group restrictions on it. If it was the last connection test (bottom of entries), you could actually have all users NOT assigned a class attribute from radius belong to the pool created in the “Mobile Clients” tab.

mcury

Here its working like this:
The default pool is never used, if it fails the AD auth (not group member), the connection is dropped.

freeradius -X is generating a lot of stuff, I won't be able to post it here, but if you want, I can send a DM with it..

keyser

@mcury Yes, exactly as I described - only I think you misunderstood my posting.

You have enabled “Group Authentication” which is needed for this to work as intended. If you didn’t enable that, users in AD groups could pass Auth and even though you return the right groups ID with “Class” for a pool you created, they would still get an IP from the default Pool.
This would happen because the default pool is located in the first strongswan “mobile-con” connection selection (higher priority than those created with the EAP IP Pool identity fix). So all users would match the default Mobile-con connection selection if it did NOT have a groups restriction applied to it - regardless of any groups attribute that was returned with the accept message by radius.

You can have the default pool brought to use. In your setup, if you only return a Class = pfsense_admins or Class = vpn_access, then they would fall into that pool.
And that’s the major reason why the optimal solution to this fix would require a new UI design: Because the current “fix” mixes pfsense groups, IP Pool Identifiers and the Radius Class atrribute and causes them at times to be “the same thing”

PS: Right now you are attempting to return two Class attributes in one accept message, and strongswan only supports returning one. In your case it seems the last one becomes the one used for groups selection in strongswan (Test and Test2 in your case)

@stephenw10 - I’ll get back to you with a proper answer tommorrow.

mcury

@keyser Perfect
Thanks for the insight... =) One more tool in my Swiss army knife (I'm from Brazil by the way)

Blame the globalization for that comment hahaha :)

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

I allowed myself to answer this question in the thread I originally created for my IPSec Fix: https://forum.netgate.com/topic/172476/a-guide-to-assign-vpn-group-and-user-ip-pool-from-radius-in-22-01-2-6

Just so this thread is not further derailed by this details discussion of Mobile IPSec :-)

michmoor

Great thread you started. Im still new to the pfsense product line having come from other vendors. In the beginning, i was frustrated that there was feature incompleteness when compared to other products but I have since changed my mentality a bit

The obvious fact that it's free and there is paid support behind it makes me feel comfortable deploying
Just understanding the use case for the product. I see pfsense as a router and firewall (L4) first and foremost. The VPN functionality when used in an "as-is" deployment is very good. The problems start to come in when you now have a business requirement that a 10+ year old firewall OS doesnt even have a feature set for. Need traffic visibility? Nope. Simple things like, which IP is the top talker between 8am - 4pm. No historical data is found. Sure you can use darkstat but cmon....its more of a hack and it provides no meaningful data. There is no application awareness despite what the marketing on the netgate site will tell you. OpenAppID rules have not been maintained on pfsense since 2017. The metadata conf is updated yes but not the text rules. I could go on but why bother.

My hope is that the pfsense+ train is where the added functionality will appear. I know it's something that people dont want to hear but if they charge for it down the line but has feature completeness in key areas identified in this thread then ill pay. pfsense CE will continue to be free.
As others have said on other forums and even here, it's a great product but one should only deploy in SMB scenarios. If your company has any I.T. budget then more than likely they are going with a named vendor.