Will AES-NI support be a CPU requirement for future OPNsense releases?

[Werner Fischer]

Hi everyone,

I just noticed that "pfSense Community Edition version 2.5" will depend on a Intel CPU with AES-NI support:
https://www.netgate.com/blog/pfsense-2-5-and-aes-ni.html

Are there any plans at OPNsense, to remove support for non-AES-NI CPUs in the future, too?

Best regards,
Werner

[franco]

Hi Werner,

There is no reason to depend on AESNI for anything to work other than performance. In the case of this news piece it means locking down the potential hardware pool available to users to be able to sell more. This is not new, if you remember 2.4 removing i386 and NanoBSD systems. Less hardware support is only a partly motivation for more momentum for development and progress. And while i386 dropping makes some sense to argue that automated build servers are free to do other things, locking down the CPU instruction set in the same architecture is an arbitrary restriction that comes at no cost for the authors, potentially coercing users to buying new hardware. :)

We can't keep up with the release cycle outlined there any longer as it has and likely always will be confusing. There's "3.0" (announced in 2015 based on a PHP-less API rework and DPDK, not available yet), 2.4 (announced in 2016 with FreeBSD 11 and no NanoBSD and i386, not available yet), 2.5 (announced in 2.5 with FreeBSD 12, not available yet).

Judging by the news that 2.5 is based on FreeBSD 12.0 that could easily mean 2019 or later as outlined by FreeBSD recently:

http://marc.info/?l=freebsd-current&m=148709717032570&w=2

"FreeBSD 12.0-RELEASE, available in couple of years"

Expect all of this to change, any day, for any reason. As I said, it's hard to keep up with what is real and what is not.

Also note that OPNsense 17.1 is production-ready on FreeBSD 11 and we have vowed to keep i386 running for as long as we are on 11. This also goes for parallel OpenSSL/LibreSSL tracks and with it the ability to run on any hardware that boots the underlying FreeBSD version.

In short: no, we do and will not restrict our releases to certain CPU requirements other than phasing out all of i386 in the long run (maybe around FreeBSD 12, but it's still negotiable).

I hope this helps.


Cheers,
Franco

[Werner Fischer]

Hi Franco,

thanks for your friendly and helpful answer. I'm happy that you will continue to support all the hardware that boots the underlying FreeBSD version :)

Thank you very much,
best regards,
Werner

[InstaNoodle]

I just signed up to the forums and I'm considering switching to OPNSense due in small part to the AES-NI situation with pfSense 2.5 but mainly due to the way they conduct themselves on HN and Reddit regarding the change.

I noticed also that they're not longer supporting 32-bit in 2.4 but made an exception for their own ARM SG1000 (32-bit ARM CPU) it also doesn't feature AES-NI (it has its own cryptographic hardware that implements AES in hardware) but it too will get release 2.5.

But of course if we (the community) wish to use 2.4 on 32-bit we're not allowed, nor can we use cryptographic accelerators or architectures that have their own crypto hardware which isn't AES-NI.

So I have to agree that this whole situation feels like planned obsolescence to get community members to purchase branded hardware.

And that is why I'm here really, I don't like the way things are going there and I've woken up to the realities that they're moving away from openness to make money.

Regardless though I'm happy to be here and learning about OPNSense.

[shezzski]

InstaNoodle, welcome to the forums.

Franco, thanks for your honest and transparent answer.

[franco]

Hi guys,

You are welcome. There's no reason to change our approach to our work now or ever. ;)

We've concluded in 2014 that we see where the other road leads eventually, so we want to be ready for those changes when they impact a larger body of users. So here's OPNsense, being polished and modernised for over two years and anyone can take it or leave it. We forked to retain 2-Clause BSD licensing like it ever was in FreeBSD, M0n0wall and the pfSense days of yonder. We don't regret it. We stand by this choice.

What I find astonishing is that the "general knowledge" that we are "evil and vile" lives on in 2017 inside the microcosm of pfSense, but people need to realise that without this view inside pfSense there's no reason for pfSense if there are projects out there based on the same code just as good as any.

I'm leaving it to the avid reader and tinkerer to check the facts and figures, see how firmware updates go and how we try to keep innovating. Spoiler alert: it's not for everybody. :D

We love the spirit of what pfSense used to be and we want to retain it. Not more, not less.


Cheers,
Franco

[opnfwb]

Franco thanks for your continued work. I too use OPNsense on a non-AES NI accelerated system. It is nice to know that I can keep using this without a forced upgrade.

For me, the main benefits to OPNsense have been the increased, modernized features that your team has added. For instance, the NetFlow Insight feature and the ability to use FQ_CODEL. Those two features alone are worth the upgrade over pfSense. OPNsense also fixes numerous, nagging issues that pfSense never seems to resolve. For instance, pfSense constantly restarts the DNS Resolver service when registering DHCP leases in the resolver. OPNsense does not do this and therefore it doesn't lose DNS caching. Simple things like this make OPNsense a much smoother, faster experience for the average user.

I used pfSense for the last 10 years. I ran OPNsense in a VM for over a year before deciding to switch out to it in full and run it on dedicated hardware. I consider it to be quite the upgrade over pfSense, especially the 17.1 release! Keep up the great work!

[mkolenc]

Franco,

I saw AESNI post for pfSense and I was really happy I use OPNsense for my hardware. There is new blog post providing good reasons for AESNI. You said AESNI is for performance, not security. It appears to be wrong. Please advise.

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

[franco]

We're leveraging AES-GCM inside TLS as the transport layer, because RFC 7525 REQUIRES it, and the RESTCONF standard, RFC 8040, says RFC 7525 is a SHOULD.

One should also mention RFC 2119 which explains what "SHOULD" means.

SHOULD   This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course.

https://www.ietf.org/rfc/rfc2119.txt

A valid reason is the use of this cloud-based central management technology in particular, not a run-time requirement for an operating system / distribution on a particular hardware. Extrapolating on this, you will have no choice but to run this technology on your free community edition potentially plugging into a foreign US company network even if you don't want this.

Disclaimer: This may not be true, but then the argument link using "SHOULD" becomes the exception to that terminology. So: it's either true and you're always connected to that management platform, or it's not true and you are just arbitrarily restricted in what hardware you are allowed to use.

And besides playing in this this-because-of-that game. RFC 8040 is an arbitrary choice in the scope of REST and API, it feels like a weakly linked argumentation to validate something that does not need to be true. Nobody forces RFC 8040 but Netgate, so the choice to require AES-NI is theirs alone.


Cheers,
Franco

[franco]

Something struck me as peculiar except the usual boilerplate of "we are going to have the best of all of this soon":

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.

Do you think this C code will be open source? Do you think that pfSense as an open source project will thrive from the switching of PHP to something that cannot be easily edited and improved by the vast majority of the community contributors? Do you feel like all questions have been duly answered and we can all go back to work?

Doesn't feel like it... :)


Cheers,
Franco

[franco]

Oh, one more thing from RFC 8040:

A RESTCONF server MUST support the Transport Layer Security (TLS) protocol [RFC5246] and SHOULD adhere to [RFC7525].

The RFC does not state wether this recommendation for RFC 7525 is being made for connections connecting to the service remotely or locally. One must assume that it talks about connections in general, so the recommendation makes sense to secure all possible connections. However, "valid reasons in particular circumstances" are easily given by assuming that the API is providing a local frontend to the GUI running on the same server making local connections, unless the GUI is rewritten as a client-side JS application at the same time.

At this point, we'd be looking at a rewrite of pfSense in all general areas, something that was advertised in 2015, advertised again now. I'll say what I said back then: it looks like a huge pile of work and even more work to get it right. We wish them all the best in their continuing endeavour. :)


Cheers,
Franco

[Nnyan]

I for one was running pfSsense in an ESXi VM on my Supermicro server.  It's dual CPU's supported AES-NI,  so when decided to separate my firewall/gateway/etc.. off my ESXi server (mostly so that I didn't bring down the internet every time I needed to tinker/reboot) I wanted a CPU with AES-NI (which for Intel Gen 3 meant at least an I5).  If I was still running pfSense the AES-NI requirement would not affect me but it would still rub me the wrong way.  Either way I'm pretty happy where I'm at now, with really only one item that I really miss from my pfSense days

[franco]

with really only one item that I really miss

Which one is that? :)

[tillsense]

Hi Franco,
Yes, kepp up the great work!

cheers till

[mkolenc]

Franco,

I read all you write. I don't understand what you talk about. Why is that that important? I asked about AESNI.