PfSense 2.5 will only work with AES-NI capable CPUs
-
Until last week, what would have prompted someone who doesn't need a high-performance VPN to in any way care about AES-NI?
We talked about the importance of having AES-NI for a lot longer than that. You can find many "will this work" threads on our forums and /r/PFSENSE where others point out AES-NI importance as well.
And, I'll note you don't need to go back to 2011 to find new Intel processors released without AES-NI. DAVe3283 provided a nice link to a list of current CPUs without AES-NI:
By way of example, this is the list of Intel processors currently being sold with at least 2 cores and that DON'T have AES-NI: https://ark.intel.com/Search/FeatureFilter?productType=processors&CoreCountMin=2&AESTech=false&FilterCurrentProducts=true
At this time, there are 233 processors on that list. If you restrict yourself to 4+ core processors, there are still 59 actively sold processors without AES-NI! Several of them were launched Q4 of last year, so we aren't just talking old stock laying around.We are aware not all CPU's from 2011 onwards have AES-NI, that's why the heads-up is over a year in advance.
-
We talked about the importance of having AES-NI for a lot longer than that. You can find many "will this work" threads on our forums and /r/PFSENSE where others point out AES-NI importance as well.
While I believe you, this announcement was the first time I ever saw the importance of AES-NI referenced outside of VPN. Heck, I'm even having trouble searching for examples where it came up on reddit (again, outside of VPN). I'm sure examples exist, but I don't think it was very common.
We are aware not all CPU's from 2011 onwards have AES-NI, that's why the heads-up is over a year in advance.
For systems that don't get refreshed very often, but are rather important to patch for security updates, one year doesn't seem all that long. While 2.4 will presumably be supported for one year, I imagine packages may see the end of support before then. And even if that doesn't happen, two years doesn't seem all that long, either.
And, as you know, you're literally going to have to go out of your way to prevent systems that don't support AES-NI from working. You're using OpenSSL, which automatically falls back to the fabled bit-sliced AES implementation. Presumably you're going to have to add a check on boot to prevent pfSense from starting on non-AES-NI systems.
While it sounds well-intentioned, it seems pretty unnecessary. Users of Netgate hardware will use AES-NI regardless. Home users of the Community Edition might end up using software crypto, but those users are unlikely to use the cloud management functionality, which is, as far as I can tell, the only place where could plausibly be a problem. And even in those cases, those users would fall back to a bit-sliced AES implementation if they have a CPU that supports SSE3. And that's to say nothing of the difficult attack models necessary for cache timing attacks.
-
We talked about the importance of having AES-NI for a lot longer than that. You can find many "will this work" threads on our forums and /r/PFSENSE where others point out AES-NI importance as well.
While I believe you, this announcement was the first time I ever saw the importance of AES-NI referenced outside of VPN. Heck, I'm even having trouble searching for examples where it came up on reddit (again, outside of VPN). I'm sure examples exist, but I don't think it was very common.
We are aware not all CPU's from 2011 onwards have AES-NI, that's why the heads-up is over a year in advance.
For systems that don't get refreshed very often, but are rather important to patch for security updates, one year doesn't seem all that long. While 2.4 will presumably be supported for one year, I imagine packages may see the end of support before then. And even if that doesn't happen, two years doesn't seem all that long, either.
And, as you know, you're literally going to have to go out of your way to prevent systems that don't support AES-NI from working. You're using OpenSSL, which automatically falls back to the fabled bit-sliced AES implementation. Presumably you're going to have to add a check on boot to prevent pfSense from starting on non-AES-NI systems.
While it sounds well-intentioned, it seems pretty unnecessary. Users of Netgate hardware will use AES-NI regardless. Home users of the Community Edition might end up using software crypto, but those users are unlikely to use the cloud management functionality, which is, as far as I can tell, the only place where could plausibly be a problem. And even in those cases, those users would fall back to a bit-sliced AES implementation if they have a CPU that supports SSE3. And that's to say nothing of the difficult attack models necessary for cache timing attacks.
We talked about the importance of having AES-NI for a lot longer than last week (others have noticed it, just find many "rate my build" threads) and we gave a heads-up to everyone for over a year in advance because we know not every CPU has AES-NI.
-
We talked about the importance of having AES-NI for a lot longer than last week (others have noticed it, just find many "rate my build" threads) and we gave a heads-up to everyone for over a year in advance because we know not every CPU has AES-NI.
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
-
We talked about the importance of having AES-NI for a lot longer than last week (others have noticed it, just find many "rate my build" threads) and we gave a heads-up to everyone for over a year in advance because we know not every CPU has AES-NI.
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
I don't see how that question is relevant for this topic as well as to what I just told you. Let's not go into off-topic, please.
-
We talked about the importance of having AES-NI for a lot longer than last week (others have noticed it, just find many "rate my build" threads) and we gave a heads-up to everyone for over a year in advance because we know not every CPU has AES-NI.
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
I don't see how that question is relevant for this topic as well as to what I just told you. Let's not go into off-topic, please.
It's absolutely relevant to whether one-year notice is sufficient. You're taking about a change that will go out of its way to break compatibility with systems that are only a few years old.
-
Dude just buy a new cpu in a couple years. You aren't going to change anyone's mind throwing a fit on the internet.
-
For systems that don't get refreshed very often, but are rather important to patch for security updates, one year doesn't seem all that long.
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
"rather important" or SMB/SOHO/home - make up your mind. ;)
In a "rather important" install I don't care about a few hundred [currency], really. And I wouldn't buy stuff today that does not support the latest and greatest shit, including AES-NI. And I'd swap-out hardware every two years so I'm always covered with warranty (plus support contracts).
For SMB/SOHO/home it is totally sufficient to run 2.4.xyz until hardware dies or use-pattern changes. I can live without AES-NI or a possible downtime due to hardware failures there.
-
For anyone actually purchasing hardware and not just repurposing old hardware, I would hope the desire to have a remotely future proof purchase would've prompted someone to care about AES-NI. VPN, especially in the US, is becoming much more commonly needed and so are faster internet connections. At this point it's not possible to have any sort of efficient encryption capability without it. Sure, you can get functional encryption without it right now, but not efficient. Again, if you're spending money, even last week before this announcement, it's something that should be considered, period.
EDIT: and that list of CPUs is terrible. I think we can safely exclude atom's meant for cell phones and Xeon Phi's from contention for possible PFSense duty…
EDIT2: the only way to make that CPU list not terrible, is to at least add Intel64 (x86-64) to the filter, as it's another relevant feature that might be worthwhile to have for future proof purchases in 2017.... add that little gem to the filter and they've literally only released 1 CPU since q2 2015 (basically the last 2 years) without AES-NI. And if you look at quad cores, it's only 1 CPU released without since Q3 2014...
Quit whining about your terrible purchase...
The point of the list was to show that Intel is actively selling and supporting a number of processors that don't have AES-NI. Even if Intel hasn't designed a new CPU since Q1 2016 without AES-NI, they are still selling & supporting a bunch.
And excluding Atoms is deliberately missing the point. Many people have / buy small NAS boxes or fanless systems that have an Atom, and if you don't use a VPN, the lack of AES-NI isn't going to be a performance penalty. The Atom will cover the needs of a lot of home users, unless you are lucky enough to be getting Gigabit Internet in your area in the next couple years. Were we all so lucky!
In my case, there are 2 things that bother me:
-
I just bought several embedded fanless systems without AES-NI (all with currently supported Intel Celeron processors). Sucks to be me, I'll have to shell out $600 or so to replace them in another couple years even if they are working perfect.
-
The reason they need to be replaced is purely arbitrary. And simply not updating pfSense after they drop 2.4 support is a FAR worse security risk than using software AES… and it will only need AES if you use their cloud management or a VPN!
-
-
Hi!
I don't mind having to update my hardware once in a while if I want to have the latest, greatest version and maintained version.
My current hardware does support AES-NI though but my backup one (in case there is a problem) won't. Unless by the time 2.5 is out I have replaced it, I will be running on it the latest version which supported a CPU without AES-NI…
(Keep in mind that this is my backup machine, which will only be activated if the main one has problem and be deactivated once they are fixed...)
(…)
"The webGUI will be present either on our cloud service or on-device, both talking to the ‘back-end’ (written in ‘C’) on the device via a RESTCONF interface."Will this "‘back-end’ (written in ‘C’)" be open source?
I would be interested to know this as well.
It's more concerns like this
The webGUI will be present either on our cloud service or on-device, both talking to the ‘back-end’ (written in ‘C’) on the device via a RESTCONF interface. This is just as I said back in February 2015.
And this which concern me…
I am absolutely not interested in having this manageable from the cloud, this is absolutely the last thing I would like to be manageable from the cloud… We are talking of a device that manages the security of a network, I don't want to make it remotely configurable...
Will it be possible to totally disable remote administration with no possibility of ever activating it but from the firewall itself?
Have a nice day!
Nick
-
Back in 2006 when i first used FreeNas (Opensource software based on FreeBSD to turn a old pc in to a NAS, a fork of mOnOwall),
it worked on the oldest hardware you could think of, like Pentium II or III and even on Thin Clients.
Arround 5 years later, the software became so "heavy" that the minimum requirements where :
Multicore 64Bit cpu,
8Gb minimum bootdrive
8Gb RAM !!!And if you have or own a Microsoft MS Server let us say 2003/2008 and you will install now Server 2012/2016
you will even getting more or less in trouble if no new hardware will be there in usage! But no one is complaining
they all buy new Hardware for their servers.When i first read the article about pfSense 2.5 and only work with AES-NI capable cpu's, i get a "deja vu".
This is perhaps owed to the circumstance that there will be even one or more angle points where things are changing
and often to a higher stage where stronger hardware will be a need and "must be" and not only a "can be" option.Until last week, what would have prompted someone who doesn't need a high-performance VPN to in any way care about AES-NI?
Then please read the second blog post about AES-NI and its need, it is not pointed to building VPNs only.
Perhaps it might be also not even and everywhere a need for software development or code writing, but
if a developer was deciding to use something that uses AES-NI it will be not or only be used for building VPNs
then, then it must be a AES-NI capable CPU inside.What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
That is not really précises asked for! If you are talking about pure routers that are not firewalls, plastic devices
from AVM, TP-Link, ASUS or Buffalo you might be happy with ~$200 - ~$300 hardware for each Internet connection
speed available. They are cheap and ASIC/FPGA based and tuned working. But pfSense is a software based x_86
firewall that will perhaps also for nearly $200 available, but with installing many packets until pfSense is a rich featured
and fully featured UTM device for VLANs, QoS, HTTP-Proxy, AV Scan and IDS for 1 GBit/s at the WAN and the most able
to get throughput for VPN must be there, you will failing with $200 that's it. But is you spend more money let us say
around $500 - $1000 you will be perhaps able to let it run many years like 5 - 7 years, have a look at the APU2C4
if you need it for a 100/20 Internet account and connection speed it will be for nearly ~$250 with mSATA and WiFi
a all-in-one box for many years.For anyone actually purchasing hardware and not just repurposing old hardware, I would hope the desire to have a remotely future proof purchase would've prompted someone to care about AES-NI. VPN, especially in the US, is becoming much more commonly needed and so are faster internet connections. At this point it's not possible to have any sort of efficient encryption capability without it. Sure, you can get functional encryption without it right now, but not efficient. Again, if you're spending money, even last week before this announcement, it's something that should be considered, period.
And if Windows 10 is needing new hardware I will be able to be angry about, because I pay for it, by using OpenSource
software where I don´t spend money or pay for it I could only ask for something but not really complaining about it. -
@BlueKobold:
Until last week, what would have prompted someone who doesn't need a high-performance VPN to in any way care about AES-NI?
Then please read the second blog post about AES-NI and its need, it is not pointed to building VPNs only.
Perhaps it might be also not even and everywhere a need for software development or code writing, but
if a developer was deciding to use something that uses AES-NI it will be not or only be used for building VPNs
then, then it must be a AES-NI capable CPU inside.I couldn't follow the second sentence there. Can you rephrase?
As for the first sentence, if you look at my post, I did preface my statement with "until last week." I looked back at references to AES-NI on on this forum and on reddit, and I didn't see any posts highlighting a need for AES-NI except when referring to VPN performance (save for one odd post talking about webGUI performance, which doesn't make a ton of sense).
Also, before all this came up, I was well aware of the cache timing vulnerabilities in some AES implementations. But as has been discussed in this thread, the library pfSense uses, OpenSSL, already has a software implementation that is resistant to such attacks. It's not entirely clear that the pfSense devs realize that. They pointed to a class project report that suggested that it does not, but they may have missed the statement about compiling OpenSSL without SSE3 support (which disables the more secure and efficient AES implementation).
@BlueKobold:
What do you expect is the natural hardware refresh cycle for a router in small business/SOHO/home environments?
That is not really précises asked for! If you are talking about pure routers that are not firewalls, plastic devices
from AVM, TP-Link, ASUS or Buffalo you might be happy with ~$200 - ~$300 hardware for each Internet connection
speed available. They are cheap and ASIC/FPGA based and tuned working. But pfSense is a software based x_86
firewall that will perhaps also for nearly $200 available, but with installing many packets until pfSense is a rich featured
and fully featured UTM device for VLANs, QoS, HTTP-Proxy, AV Scan and IDS for 1 GBit/s at the WAN and the most able
to get throughput for VPN must be there, you will failing with $200 that's it. But is you spend more money let us say
around $500 - $1000 you will be perhaps able to let it run many years like 5 - 7 years, have a look at the APU2C4
if you need it for a 100/20 Internet account and connection speed it will be for nearly ~$250 with mSATA and WiFi
a all-in-one box for many years.In context, it should have been clear that I was asking what someone should expect is a reasonable hardware refresh cycle for a router running pfSense. It sounds like you agree that someone would reasonably expect to use the same hardware for "many years," perhaps as many as 5-7 years. Given that, one-year notice of a fairly arbitrary new hardware requirement, simply to maintain existing functionality with updated builds, seems rather short.
As for the rest of that paragraph, I'm not entirely sure what you meant.
-
Will this "‘back-end’ (written in ‘C’)" be open source?
@ivor: would be nice if you or someone from netgate had an answer.
-
And this which concern me…
I am absolutely not interested in having this manageable from the cloud, this is absolutely the last thing I would like to be manageable from the cloud… We are talking of a device that manages the security of a network, I don't want to make it remotely configurable...
Will it be possible to totally disable remote administration with no possibility of ever activating it but from the firewall itself?
Have a nice day!
Nick
+1
-
I find this thread very interesting. Can someone explain me why doesn't pfsense doesn't make AES-NI optional and load the AES-NI module dynamically when the box starts up. (See Reference below)
Can someone send a link where I can read why making AES-NI mandatory is the best outcome. Obviously there must be a rationale behind it.
Reference:
https://manuth.life/enable-aes-ni-freebsd/ -
It sounds like you agree that someone would reasonably expect to use the same hardware for "many years,"
Yes that should be a fine thing for many of us, or? I personally prefer to use one build (hardware) for many years, over
going all two years buying new hardware. pfSense is my firewall and not my hobby!perhaps as many as 5-7 years.
In former days it was said likes "You get what you pay for!" but as today many peoples will change all things in
the same order like they change their smartphone, but not me! I prefer to get and pays for one machine more
money and use it then as long as I am able to do! If Supermicro starts their production in 2017 of the third range
of Xeon D-1500 mainboards, that is supporting then AES-NI, QAT and SPDK & DPDK I would fairly wait until the end
of 2017 or the beginning of 2018 to buy new hardware, but then this rig must be running for 5 - 7 years for sure.Other may love it more to spend $200 for each appliance but they are buying then all 2 years new hardware.
To support the project I would go more to buy a small device such SG-1000 or one of the next ones such the R1
to play with or to try out things at first.Given that, one-year notice of a fairly arbitrary new hardware requirement, simply to maintain existing functionality with updated builds, seems rather short.
For sure if one thing is changing it can be nasty, but if many things are turning around or a bigger change is their
then the most peoples would not believe it or trust it, or plain the are disagree with that, but I am fairly believing
and pretty sure about, that the pfSense developers are not doing something to harm us or bother with us.
Version 2.2.6 - version 2.3 - version 2.3 - version 2.4 and from 2.4 to 2.5 even and even more new things
will be floating in that project and version 3.0 is perhaps fully new written and more smooth and liquid acting
then the software now, why should I am angry about that? Actual my pfSense firewall is fulfilling all conditions
from that software and I am really lucky about that.I find this thread very interesting. Can someone explain me why doesn't pfsense doesn't make AES-NI optional and load the AES-NI module dynamically when the box starts up. (See Reference below)
I think this could be easily done. As I have understood that both blog posts from Netgate AES-NI can be used for encryption
but it can be also used by the code to do other things. And there were three different methods able to use for the
developers and their were choosing the one how works together with AES-NI and that not only for the VPN encryption part.Reference:
https://manuth.life/enable-aes-ni-freebsd/Nice, but only for FreeBSD, that is fairly said, the so called basis underlying of pfSense, but nothing more.
And as today I think the fully new written pfSense system will be very hard edited from of the original
FreeBSD OS based on all changed things and code.Can someone send a link where I can read why making AES-NI mandatory is the best outcome. Obviously there must be a rationale behind it.
There are two blog posts with statements from Netgate about it as I am right informed.
pfSense 2.5 and AES-NI
More on AES-NIAs for the first sentence, if you look at my post, I did preface my statement with "until last week." I looked back at references to AES-NI on on this forum and on reddit, and I didn't see any posts highlighting a need for AES-NI except when referring to VPN performance (save for one odd post talking about webGUI performance, which doesn't make a ton of sense).
I think, and this is only my opinion nothing else, that there was a problem with many something +500 VLANs and the status
page renew interval that was "eating" the whole CPU performance until the box freezes totally and now they (the developers)
are changing this by writing a new frontend & backend by using C and phyton. And this frontend will be able to manage from
a cloud account (many pfSense installations) but also able to connect from the CLI or local WebGui.And now the second part!
AES-NI will not be only used anymore for VPN encryption alone, but also used more from another piece of software
or code that will be based on one of three available methods. And the developers were choosing the one, that is using
AES-NI instruction set of the CPU too, but for other things or to secure the entire system more then using it for VPN alone. -
I find this thread very interesting. Can someone explain me why doesn't pfsense doesn't make AES-NI optional and load the AES-NI module dynamically when the box starts up.
That's (roughly) what pfSense does today. pfSense uses OpenSSL as its underlying crypto library. OpenSSL will use AES-NI when its available, but it falls back on a side-channel-resistant version when SSE3 is available (which is almost everywhere).
So, why do the pfSense devs want to require AES-NI? It's not completely clear, but their blog posts described their worry over cache timing attacks on an upcoming remote management interface that will be in future versions of pfSense. Cache timing attacks are sophisticated attacks that attempt to steal secret AES keys by looking at the time it take a target system to perform encryption operations. It suffices to say that AES operations performed in hardware- as is the case with AES-NI- should not be vulnerable to such attacks. But software implementations may be.
That should sound bad- and it is- but its important to remember a few things: 1) cache timing attacks are extremely difficult to mount in practice, due to the what the attacker needs to be able to observe, 2) OpenSSL already includes an implementation resistant to these attacks, and 3) there's no issue at all if don't use Netgate's upcoming cloud management solution.
@BlueKobold:
I find this thread very interesting. Can someone explain me why doesn't pfsense doesn't make AES-NI optional and load the AES-NI module dynamically when the box starts up. (See Reference below)
I think this could be easily done. As I have understood that both blog posts from Netgate AES-NI can be used for encryption
but it can be also used by the code to do other things. And there were three different methods able to use for the
developers and their were choosing the one how works together with AES-NI and that not only for the VPN encryption part.No, AES-NI will be used for encryption. It's not useful for anything other than performing AES round functions. The blog posts indicated that the pfSense devs plan to use AES to encrypt the management interface between the webGUI and the pfSense device itself. Note that the webGUI itself will be running on the pfSense device itself if you do not use Netgate's upcoming cloud management solution. Encryption probably isn't necessary in the case of local management, since the traffic is staying fully inside the pfSense router itself, but they seem to be doing it primarily for standards compliance.
@BlueKobold:
Reference:
https://manuth.life/enable-aes-ni-freebsd/Nice, but only for FreeBSD, that is fairly said, the so called basis underlying of pfSense, but nothing more.
And as today I think the fully new written pfSense system will be very hard edited from of the original
FreeBSD OS based on all changed things and code.Because OpenSSL already includes software AES implementations, the pfSense devs will have to go out of their way to prevent systems that do not support AES-NI from being used with pfSense 2.5. The easiest and simplest path would simply be to continue doing what they do today: use AES-NI when its available, and allow OpenSSL to fallback to software when it's not.
-
For anyone actually purchasing hardware and not just repurposing old hardware, I would hope the desire to have a remotely future proof purchase would've prompted someone to care about AES-NI. VPN, especially in the US, is becoming much more commonly needed and so are faster internet connections. At this point it's not possible to have any sort of efficient encryption capability without it. Sure, you can get functional encryption without it right now, but not efficient. Again, if you're spending money, even last week before this announcement, it's something that should be considered, period.
EDIT: and that list of CPUs is terrible. I think we can safely exclude atom's meant for cell phones and Xeon Phi's from contention for possible PFSense duty…
EDIT2: the only way to make that CPU list not terrible, is to at least add Intel64 (x86-64) to the filter, as it's another relevant feature that might be worthwhile to have for future proof purchases in 2017.... add that little gem to the filter and they've literally only released 1 CPU since q2 2015 (basically the last 2 years) without AES-NI. And if you look at quad cores, it's only 1 CPU released without since Q3 2014...
Quit whining about your terrible purchase...
The point of the list was to show that Intel is actively selling and supporting a number of processors that don't have AES-NI. Even if Intel hasn't designed a new CPU since Q1 2016 without AES-NI, they are still selling & supporting a bunch.
And excluding Atoms is deliberately missing the point. Many people have / buy small NAS boxes or fanless systems that have an Atom, and if you don't use a VPN, the lack of AES-NI isn't going to be a performance penalty. The Atom will cover the needs of a lot of home users, unless you are lucky enough to be getting Gigabit Internet in your area in the next couple years. Were we all so lucky!
In my case, there are 2 things that bother me:
-
I just bought several embedded fanless systems without AES-NI (all with currently supported Intel Celeron processors). Sucks to be me, I'll have to shell out $600 or so to replace them in another couple years even if they are working perfect.
-
The reason they need to be replaced is purely arbitrary. And simply not updating pfSense after they drop 2.4 support is a FAR worse security risk than using software AES… and it will only need AES if you use their cloud management or a VPN!
See, here's the problem. You're complaining about a purchase of bare hardware from a separate 3rd party on which you intend to run free software. That hardware was not sold for any particular purpose and does not have any kind of warranty guaranteeing to support future versions of anything. When you make purchases like that, it's on you to accept any and all repercussions of the free software you run on it. AND you're complaining about a change to free software that's most likely 2 years down the road. If you want on-going support you need to purchase task specific hardware/appliances. Buy PFSense hardware directly from Netgate if that's what you're looking for. That's just how the world works.
Don't get me wrong, I can understand your plight. You probably didn't buy those systems for yourself and you probably have to explain to someone, a customer or a boss, that they now have an expiration date you didn't anticipate. But again, that's on you because there are fanless embedded systems with AES-NI and you chose to purchase ones without it.
To everyone whining about this here, stop complaining about your mistakes here. The appropriate way to handle this is to put in a feature request for 2.5 to support non-AES-NI systems (possibly getting the SSE3 OpenSSL build included) and maybe the devs will consider it. They sure as heck aren't going wade through a few whiny forum posts and decide to change direction because of them.
-
-
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything. A roadmap helps me in understanding where the focus is, and where/when "major" architectural changes like this will be taking place. It also helps me in determining when a project/product is taking a direction is a direction that is focused on solutions that don't benefit me or help me solve the issues I'm trying to solve.
Two years ago (2015), I was reading posts focused around high throughput leveraging Intel QuickAssist (there was also mention that it may not be delivered in the Community edition, but only the commercial edition). 2.4 announce (a welcome in my opinion) change is underlying filesystem, but it also announced a focus with ARM based systems. Now, with 2.5 I am hearing a move to cloud management with a requirement for AES-NI offload.
I'm having a hard time understanding where the project direction is now: High-end high-throughput systems that would compete with CISCO/Checkpoint/Palo Alto? Centrally managed - again competing with higher end commercial offerings? Doesn't fit within my needs, but ok, I see many others demonstrating a desire for it in the forums (fastest residential Internet offeriing in my area is 500/50).
But ARM? Is the project now wanting to compete with lower end offering like Netgear/Asus/TP-Link/D-Link routers and Ubiquity EdgeRouters?
I'm really confused where PFSense's focus/direction is now. I could be wrong, but I didn't think there was enough development resources to support this many major initiatives.
-
From my perspective, I see this as a issue stemming from a lack of roadmap more than anything.
While I get it's a blog post, but I think notice about a change to a version 2 major point versions and probably 2 years away is about as good as a roadmap as you can expect.
I'm having a hard time understanding where the project direction is now
(…)
But ARM? Is the project now wanting to compete with lower end offering like Netgear/Asus/TP-Link/D-Link routers and Ubiquity EdgeRouters?
I think they've been molding PFSense in an Enterprise direction for quite a while. Cloud (internal and 3rd party) is very much being embraced in the Enterprise. And ARM is making in roads into the Enterprise/datacenter space as well. ARM has been around in network devices for a while as well as storage devices. Full blown servers based on ARM are becoming a thing too and they already have the encryption offload capabilities built into very efficient hardware. It's not a surprise to see the underlying BSD OS supporting ARM and hence giving PFSense the ability support ARM. It doesn't necessarily equate to trying to compete with the consumer, lower end offering like Netgear/Asus/TP-Link/D-Link routers. Also, I wouldn't put Ubiquity EdgeRouters in the same boat as those consumer offerings, they're definitely Enterprise gear. Maybe the low end of Enterprise, but definitely not consumer oriented.
