Up late thinking about pfSense development

michmoor

Hello to anyone who would listen.
Trying to figure out what specifically is the secret sauce when it comes to pfSense. Being fully open source in nature or the slow methodical development process? Here is what brought me to this thinking.
My main job which pays my bills is in fintech. I also do some light MSP work with another gent where we do mostly network setups LAN/WAN and some work in a colo.
Anyways, recently at my main gig, I ran into an issue with a Palo Alto firewall. Without getting too much into specifics I was able to prove to their TAC engineers that routing is broken which leads to BGP peerings failing constantly. TAC is aware and they are seeing about reproducing the issue on their end before handing it off to the engineering group.
During the troubleshooting process, I did find out that Palos runs FRR. Not surprising of course but this is where I started thinking. Most likely this is a proprietary and custom FRR engine running underneath and because of the complexity of the code in general it's probably going to take some time for them to diagnose and offer a solution.
This brings me to pfSense. I love the fact that as an open source product, the packages are available to peak inside, and where I can write custom scripts because it's all extendable. I do appreciate the stability of pfSense and although Plus gives 3x updates a year those are some quality updates. In contrast, PanOS is just a buggy mess. I love the features that are in the Palo firewall but all that code and features come at a cost in stability and possibility of security (looking at Fortigate as an example).
I'm not saying one vendor is superior to another rather just pointing out that i deeply appreciate pfSenses commitment to building a platform around open source projects and always pulling from source. No proprietary nonsense around routing or firewalling.
So this brings me back to my original thoughts in the post. What is different about pf compared to other commerical vendors? Commitment to a fully open-source product and packages that always pull down the latest secure code? Maybe not relying on forks of open source projects (FRR in Palos case) which are prone to complex issues and security? Look at the issues with Fortigate and those CVEs on a security project. Insane. Meanwhile, OpenVPN is still as secure as ever without much bad press.

Whatever it is, i sure do appreciate the effort by the dev team and most importantly the community here in the forums. Super helpful and at times enjoyable to read with the snarky remarks

keyser

@michmoor I very much agree. My only gripe is that pfSense has these “dead” zones where no development or advancements are being done. I fx. Have a lot of customers that really appreciate using the OS built-in VPN clients rather than one you have to deploy and maintain (fx OpenVPN). PfSense and Mobile IPSec have been at a standstill for a decade at least. The Ipsec engine pfSense uses have supported different IP pools for different groups af users for a decade, but it’s still not available in pfSense - and likely never will be as Netgate ignores it completely.
So I’m starting to phase my costumers onto a different FW product now because they all really need this very basis thing:
The ability to have different firewall rules to different groups of mobile ipsec users. You can’t do that in pfSense.

I created a hack to enable it in pfSense, and it works fine and are extremely simple - it would be so simple for netgate to add support for it. But mobile IPsec is dead country, and loosing that feature (my hack) at aevery upgrade, and having to reenable it again is not a good solution for production customers.

SteveITS

@keyser said in Up late thinking about pfSense development:

@The Ipsec engine pfSense uses have supported different IP pools for different groups af users for a decade, but it’s still not available in pfSense

It can be done with FreeRADIUS. Not sure about pools for groups, but a specific IP per login, so similar.

keyser

@SteveITS said in Up late thinking about pfSense development:

It can be done with FreeRADIUS. Not sure about pools for groups, but a specific IP per login, so similar.

It can't be done with Freeradius - only Framed IP (static IP for every user), and that's not usable.
With my customers we are talking hundreds or thousands of VPN users, and configuring static IP for each one is not an option.
We need the simple a approach - Radius returns a CLASS attribute based on usergroups, and that identifies the IP pool from which the client should recieve an ip.
Then you can make rules for that pool of IPs (Users).

It works fine to - actually extremely simple as it only requires a very small hack to enable it in pfSense.
But Netgate does not support it in the UI, so I can't really use it at customers.

Here's my two years old ticket (including my hack), but this has been a requested feature for at least a decade, so Netgate probably decided it's not something they wish to support. I dunno - do they prefer OpenVPN so much that it is an active decision?

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

michmoor

@keyser said in Up late thinking about pfSense development:

I dunno - do they prefer OpenVPN so much that it is an active decision?

Although its not stated and I dont think we will ever get an answer it certainly is the case that there is development support for certain features than for some. OVPN is the defacto standard for remote access on pf hence why a 2-year-old ticket is sitting out there. Thats my guess but its plausible.
I have a ticket open where there is an issue with FRR and IPsec running over the same VTI. In summary, ipsec will break routing if you are using bgp over ipsec or ospf over ipsec. Its very common to run dynamic protocols over VTI yet.....on pfsense its highly advisable to not do it at this time. There's a thread i had last year where i documented the behavior and i almost lost a bid because in the hub/spoke topology if i update IPsec configuration on pfsense over 500 spokes will drop routing to the hub because of the IPsec bug. I changed to Juniper SRX in that case but cmon....I have a redmine open and last notes were that its being pushed to 24.09. It is what it is but more people should be aware of it at least within the documentation.
So yeah to your point there are parts of the pfsense code that receive little love and other parts that do.

bmeeks

@keyser said in Up late thinking about pfSense development:

Here's my two years old ticket (including my hack), but this has been a requested feature for at least a decade, so Netgate probably decided it's not something they wish to support. I dunno - do they prefer OpenVPN so much that it is an active decision?

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

You could try creating a Pull Request in the pfSense GitHub repo here: https://github.com/pfsense/pfsense to perhaps speed things along.

That way the basic code work is already done for Netgate, and all they have to do is review the code and merge it into the branch with a mouse click. That's much less developer work on their end compared to writing the necessary PHP code themselves.

It's not too hard to clone a GitHub repo and then contribute code changes to upstream from it. Lots of Google tutorials out there showing the steps involved. That is the spirit of open source software .

That's sort of what I faced many years ago when I started using the Snort package on pfSense. It lacked two key features I wanted to utilize: automatic flowbits resolution and IPS policy selection. Neither was in the code. I could have created a Redmine ticket and probably waited forever and never gotten the features, or I could attempt to code them myself and contribute my efforts back to the project for the benefit of other users. I chose the latter.

keyser

@bmeeks I'd love to, but I have no coding skills what so ever, so it would take me forever to figure out how to do the PHP code needed.
The hack I have done is a simple change in the script that generates the swantl.conf file - so it creates a GROUP identifier instead of an ID identifier if you use the UI and create a PEAP psk with a IP pool attached.

bmeeks

@keyser said in Up late thinking about pfSense development:

@bmeeks I'd love to, but I have no coding skills what so ever, so it would take me forever to figure out how to do the PHP code needed.
The hack I have done is a simple change in the script that generates the swantl.conf file - so it creates a GROUP identifier instead of an ID identifier if you use the UI and create a PEAP psk with a IP pool attached.

I have not examined that area of code, but your hack appears to be 90% of the code solution. The fact you figured out the proper hack is evidence that you may have more coding skills than you give yourself credit for. You say that's all that's required to make the feature work as you wish. That may be sufficient. You say using your "group" identifier instead of an ID does not seem to adversely impact anything else. If true, then simply merging your hack into the code base would solve the problem.

If you think it needs an addtional GUI tab, then it is very easy to copy an existing tab and then edit that code the same as you did for your hack. You will find all the GUI code in /usr/local/www on the firewall. It's the same PHP code you found and edited in that include file.

There is also another possible avenue to get something new added into pfSense. You can try the Bounty system in this sub-forum: https://forum.netgate.com/category/30/bounties.

By the way, the Snort package modification was my first time ever working with PHP. I did a little study via the web and then experimented in a pfSense virtual machine. Granted I had programmed in other languages before then such as assembler for various CPUs, C, C++, and C#. But I still had to learn the pfSense code and PHP as I went, since I had no prior experience with that.

keyser

@bmeeks Thank you so much for your belief in my capabilities. But I just don't have the time or skills needed to start from scratch to learn all that.
The UI section could probably to some extent be cloned from the EAP psk UI section, but that would be TERRIBLE design as you could then input IP pools in two places.
So if this should be done there should be a change in the UI where the IP pool section is removed from the PEAP psk UI, and instead made into its own IP pool UI where you can enter the IP pool details and Groups (pool) name.
The PEAP psk should then have a selector to select which pool name (groups) to attach any PEAP psk ID to.

I have accepted it will likely never be a part of pfSense's capabilities, and I have started to deploy non-netgate/pfsense devices at customers now.
The final toll on Netgate when I'm done will be a loss of about 50 SG-xxxx devices in sale, but the real problem is actually that I'm starting to recommend another product to customers going forward because I cannot honestly recommend pfSense for companies that needs mobile user VPN.

I still love my pfSense for homeuse so It's not like I have lost faith completely ;-)