pfsense 2.5 May Require Hardware Upgrade

[coxhaus]

It looks like the future pfsense 2.5 is going to require AES-NI in the cpu. My old Xeon does not have AES-NI built-in so I don't know what I am going to do. I will have to decide whether to upgrade hardware or move back to Untangle. We still have probably a couple of years. So people buying hardware now might make a note. You may want to make sure your new hardware has AES-IN built-in to the Intel CPU.

https://forum.pfsense.org/index.php?topic=129842.0

https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html

 

[sfx2000]

Understood, your concerns... their logo'd stuff all supports AES-NI these days...

AES-NI has been around for a while on the big cores - and the Intel low power cores, they're now at present with Braswell and later...

The pfSense team - looks like they're making some hard choices - I get that...

Rumor is pfSense 3.0 might be linux vs. freebsd...

 

[coxhaus]

I can see AES-NI on the big pipes handling encryption but for home probably not needed.

I think the hard choices are to use newer hardware and not support the old recycled hardware. Maybe if you are going to be top of the stack that what it has to be.

Linux. That would be a big change.

 

[MichaelCG]

This will be interesting to see how it pans out over the next year or so. I really hope more details will emerge sooner than later on the real reasoning behind this decision. It is great they are at least giving this much notice to the community, but without more details it currently seems as a money grab to sell hardware.

In my personal use case, I will find this highly annoying since my current system does not support AES-NI. I have no intention of replacing my current FW until some hardware fails on it. Even then, I still plan on going to the local electronics recycler and picking up yet another $50 retired Enterprise desktop. My current E4600 CPU is more than enough for my 1Gpbs Internet connection. Even on VPN duties, I am able to get 100Mbps on OpenVPN which meets my needs just fine. And the fact that I won't be able to replace it with a standard Pentium, Celeron, or even an i3....but will have to find an i5 or i7 is even more annoying from a cost perspective.

 

[kvic]

My pfSense project hasn't got a chance to start...and may postpone indefinitely. If pfSense turns to Linux, it loses one of its main selling points. Stay with FreeBSD and attract (withering?) BSD admirers.

At the moment I'm very satisfied with Vyatta^h^h...EdgeOS on my little Edgerouter X. So far gone through two iterations of updates (v1.9.0 > v1.9.1 > v1.9.1.1). Milky smooth and all settings are preserved without user intervention. Vyatta grows and glows on me . I wish consumer vendors could build their new routers based on VyOS. WRT simply the deadend..shall have been killed long ago! Existing pfSense users seeking quality router software can have more choices.

 

[sfx2000]

I can see AES-NI on the big pipes handling encryption but for home probably not needed.

I think the hard choices are to use newer hardware and not support the old recycled hardware. Maybe if you are going to be top of the stack that what it has to be.

Linux. That would be a big change.

It's actually more on the back-end development - and I get it...

Not so fun for older devices that don't support AES-NI natively (or offload to a driver), but the reasons make sense...

https://www.netgate.com/blog/more-on-aes-ni.html

a) they're moving away from an x86 specific platform
b) they're moving more into a cloud based architecture..

 

[kvic]

https://www.netgate.com/blog/more-on-aes-ni.html

Somehow I feel the guy is more marketing speak by quoting one paper and one aspect to support their decision. With many ppl questioning the move, pfSense team^h^h^h Netgate needs a better response.

The argument is week. They could't explain why can't AES-NI and non AES-NI hardware be supported at the same time in 2.5 and beyond.

Smells something similar? Apple does this kind of marketing all the time.

 

[sfx2000]

Just like iDevices and Macs - nobody is forced to use pfSense...

The 2.5 announcement - lot's of folks put on angry eyes and mad posts on Reddit and the forums, without perhaps understanding the logic behind the decisions that the pfSense team had to consider...

In the longer term - it's really down to how they want to manage the development of their platform.

Simply put...

 

[coxhaus]

Yes in the end we will all make the decision to run pfsense or not. The price of processors are not coming down as fast as in the past. Where every 2 years people were changing to a new faster processor. More cores are not driving the ship like speed was in the past. We will see if you can buy a cheap AES-NI processor in a couple of years.

I always run a faster processor than needed because I want immediate response. This is one of the reasons I changed from Untangle to pfsense. pfsense was quicker. I was hoping on also running snort but snort seemed slower than Untangle. I have stayed with it for inline support that maybe working in the future. We will see.

 

[sfx2000]

Again - after some thought - I think this is likely a good move by them... they want to improve performance and security, and grow the platform.

The team has limited resources - and they could have gone down a software based AES path, but that would entail quite a bit of work on their part, based on decisions they made on the 2.5 SW architecture (YANG and RESTCONF) - or just move it over to a HW offload - which does limit some platforms, but it also simplifies development and testing...

The 2.5 changes are a good thing here, as both AMD64 and ARM platforms work well with AES-NI type of instructions...

Part of me worries a bit, as they've recently developed HW platforms around ARMv7-a (SG-1000 on Sitera, and the upcoming Armada 38x board), where they probably should have just gone with ARMv8-a with a suitable processor - as they'll hit the same wall at some point with x86...

If one is following the development path - 32-bit x86 support is going away in 2.4 - which puts some folks with old boxes into a bind perhaps...

2.4 will require 64-bit processors in x86 land
2.5 will require 64-bit processors with AES-NI in x86 land

It's not clear from them at the moment what happens with their ARM initiative - is this also going to be Aarch64 with ARM - makes sense to me, esp. for ARMv8's that have crypto options enabled (not all A53/A57/A72/A73's do, this is optional in ARMv8 space)

It's not that much different that what Apple has done - "we'll get you over the divide, just keep in mind, and we'll tell you up front, do xxx/yyy, as support is going away" - in iOS for example, iOS11 likely will be 64-bit only - which is some pain, but longer term, much better for the platform - as splitting libs between ARMv7 and ARMv8 is extra work, and doubles the chances for performance and bugs...

Microsoft is doing the same thing these days - the Win32 API is slowly going away in favor of the UWP platform, which fixes so many things that are wrong with Win32...

 

[sfx2000]

Linux. That would be a big change.

I would agree - moving from FreeBSD to Linux isn't just a kernel change, it goes into GPLv2/v3 vs. BSD (and recently Apache) licensing...

There are certain architectural advantages moving over to Linux, but it might not be worthwhile...

 

[avtella]

I would agree - moving from FreeBSD to Linux isn't just a kernel change, it goes into GPLv2/v3 vs. BSD (and recently Apache) licensing...

There are certain architectural advantages moving over to Linux, but it might not be worthwhile...

Could you elaborate the advantages in simplified terms if possible.

 

[Cake]

Switch over to opnsense

 

[Blade Runner]

The pfSense responses were entertaining. Drama queens who didn't perform their due diligence prefer to point fingers. It's called planned obsolescence. Sound familiar?

 

[sfx2000]

The pfSense responses were entertaining. Drama queens who didn't perform their due diligence prefer to point fingers. It's called planned obsolescence. Sound familiar?

Yep - I wouldn't call it planned obsolescence - rather, it's the introduction of newer/better technology as development moves on...

 

[sfx2000]

Could you elaborate the advantages in simplified terms if possible.

It's like Honda (BSD) creating an exact replica of a General Motors (Linux) Buick Regal/Opel Insignia - Honda is known for doing their own things their own way, GM works with many partners, and they all share parts...

Doing things one's own way has a lot of control over things end-to-end, but going into a distributed model can have advantages as well, as one can leverage on the development of others.

Honda's Accord is a fine car - and so is the Regal/Insignia - different means to the same end.

 

[sfx2000]

Switch over to opnsense

One always has that option... as a fork of pfSense, they might face the same thing at some point in time, otherwise get left behind..

 

[sfx2000]

Right now - pfSense has the SG-1000 - which is a really nice little Cortex-A8 box -- it really is...

And... they have an Armada 38x box coming soon...

https://www.netgate.com/blog/lord-vader-your-firewall-is-ready.html

Problem here - like with their x86-64 moves with 2.4/2.5 - they'll run into a wall at some point with the ARM units - and then, hey, "we need to move to ARMv8" -- it's bad timing for products on the HW side vs. SW here, IMHO, because now they're stuck with ARMv7-a for a while, when we have A53/A57/A72 chips ready now... I see at least a three year hangover there...

pfSense has, in the past, supported a STABLE and BETA release - where they might end up - with both X86 and ARM is having to support an LTS release to provide at least bug fixes and security updates. But that'll take some additional resources and time to manage an LTS release, along with DEV/BETA/STABLE..

(no, I'm not shouting with the all CAPS..)

I do appreciate ADI/Netgate/pfSense - as it's an engineering driven company - compared to others, they're open about what they're doing, and where they're headed.

They do good work...

 

[Blade Runner]

Right now - pfSense has the SG-1000 - which is a really nice little Cortex-A8 box -- it really is...

And... they have an Armada 38x box coming soon...

https://www.netgate.com/blog/lord-vader-your-firewall-is-ready.html

Problem here - like with their x86-64 moves with 2.4/2.5 - they'll run into a wall at some point with the ARM units - and then, hey, "we need to move to ARMv8" -- it's bad timing for products on the HW side vs. SW here, IMHO, because now they're stuck with ARMv7-a for a while, when we have A53/A57/A72 chips ready now... I see at least a three year hangover there...

pfSense has, in the past, supported a STABLE and BETA release - where they might end up - with both X86 and ARM is having to support an LTS release to provide at least bug fixes and security updates. But that'll take some additional resources and time to manage an LTS release, along with DEV/BETA/STABLE..

(no, I'm not shouting with the all CAPS..)

I do appreciate ADI/Netgate/pfSense - as it's an engineering driven company - compared to others, they're open about what they're doing, and where they're headed.

They do good work...

The 100 million question is ..."How to get additional resources?"

I believe Netgate's revenue is limited supporting open source software. Therefore, I don't anticipate a LTS version in the near future. The pfSense 2.3.4-Release shows BIOS info and generates a Netgate Unique ID. It would be easy to create an active user database.

 

[Xentrk]

My pfSense appliance CPU specs are:

Intel(R) Atom(TM) CPU D525 @ 1.80GHz 4 CPUs: 1 package(s) x 2 core(s) x 2 HTT threads

I purchased the appliance from a pfSense partner in Bangkok last July. My contact there informed me that my CPU does not support AES-NI. It is started on the Atom Z3460. And that I could not swap out the CPU. Does the sound correct? @sfx2000 ?