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

gabacho4

@cool_corona I would agree with you. I think with the new business model and some time, we might start to see some movement on some of these issues. I think the previous model of pretty much 100% free unless you wanted to donate to Netgate definitely had an impact. I do find the argument that Palo Alto or Cisco or a namedPaidService can do X or Y better to be a dead one. Have fun paying an arm and a leg for all the licenses just to get the basic functionality that pfsense offers, let alone the extras.

I also think Netgate could do a better job being transparent about things they are working on or intend to implement and perhaps engage their user base more. The redmine shows issues being worked but I’ve seen it mentioned a few times that they have an internal “to do” list with Plus. Understand their need to keep new and exciting developments under wraps until they can excitedly announce them, but don’t see a reason that they can’t come out and say “your desire for request/feature X has been heard and is being worked on” or something to that extent. And of course, they can also just tell us when there’s no chance in hell. Reminds me of the much wanted and long broken UPnP and multiple game consoles issue they just got fixed. The hold up? They didn’t have any consoles to replicate the issue with and troubleshoot. To the user, it seemed they were hopelessly unable to do what a cheap D-link can do, while all the while they just lacked the gear or data to fix things. So yeah, I get where you’re coming from.

I wish I had development skills so that I could help kickstart things I would like to see advance. Like others have said, I don’t know how I can actively help contribute without those skills in hand.

Cool_Corona

We could pay cheap guys from India to develop the packages we need.

Outline the scope and specs and they are done quickly.

mcury

Since this topic was opened, I have been trying to configure framed-ip-pool in radius (sqlippool) to use with ipsec mobile road warrior in pfsense.

Unfortunately, no joy yet.

stephenw10

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

If you upgraded to 2.6.0 youre stuck with errors and VLAN performing bad unless you run a script when the damn thing boots or disable RSC.

Just for clarity that only affects the hn(4) driver in Hyper-V. So a pretty small minority of users.
It is fixed now in 2.7 though.

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

I understand - but for the record I have now created a simple hack to pfSense, that allows you to use the IPSec Mobile User VPN with group based authentication and group based IP Pools (Firewall rules for group of users).
It works with the OS native VPN client on all the major client OSs, and a feature pfSense has been lacking for FAR FAR FAR to long.
It works beautifully at a costumer with about 500 Mobile VPN Users :-)
I have created a redmine request to have it fixed...

What's the redmine?

Steve

keyser

@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

stephenw10

This I assume? https://redmine.pfsense.org/issues/13227

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.