pfSense RAM and AES-NI requirement
-
pfSense users/developers,
I am very new to pfSense (currently I am running in a VM for experimental purposes) but looking forward to deploying it on an isolated hardware platform. I have been told by multiple people that I ought not buy any platform to run pfSense that stands absent a chip supporting AES-NI or pfSense after 2.5 will not work or install. I saw some update on the blog saying this was untrue but it only referenced 2.5.0 and not policy concerning versions thereafter or the future.
Moreover, is 4GB of RAM enough to run it going forward, or will future FreeBSD variants likely impel the need for a larger RAM footprint?
Can someone kindly disambiguate, as it will make a huge difference in what hardware I choose and the prices of such hardware.
Stuart
-
@stuartbh 2.5 was supposed to require AES-NI but Netgate backed off that requirement. I don't recall hearing anything about the future either.
re: RAM, it totally depends on what you're doing with it. I think every router we configured for ourselves and clients is 1 GB or less in normal usage, surely under 1.5 GB, and that's with a few packages. If someone was to load up on packages like pfBlocker with DNS blocking, IDS, Squid proxy, lots of large IP tables in aliases/rules, etc., RAM usage could be much larger.
There's currently a memory leak in the pcscd PC/SC Smart Card Daemon but there is a patch to disable it.
Other than that RAM usage is pretty low in normal use as I described. Most of our clients have 3100s which had 2 GB RAM.
-
Thanks for your brisk response.
I was looking at getting a hardware platform that has a maximum RAM footprint of 4GB and stands absent the AES-NI (AES new instructions). Granted, I'd not want the device to be obsoleted at the next point release, hence my concern, otherwise I'd invest in a hardware platform offering a greater RAM footprint and the AES-NI, though at far greater cost.
It is encouraging that a basic installation of pfSense runs well within 1-1.5GB. I plan on installing OpenVPN, ACME, and maybe a couple of plugs in,but, nothing heavy duty.
Thanks again.
Stuart
-
@stuartbh re: VPN, the advantage to crypto hardware is hardware acceleration. Also see OpenVPN docs. What speed Internet will you have?
-
Yeah, AES-NI is not required for pfSense 2.5.X but almost everything vaguely recent does support it anyway. Anything that doesn't would need to be very cheap IMO.
-
Currently, I have not so speedy DSL and the VPN is used exclusively by me in one of two circumstances:
- I am on a public WiFi and I wish to ensure treatment of my data such that it is fully encrypted
or - I am not at my home and wish to access resources (my file server, a Linux system I need to test something on, scripts I have that I use with customers from time to time, etc...)
So for me, encryption speed is currently not an issue, however, I can see where it would also be a consideration when my internet choices are higher speed connectivity too, as why let software based encryption frustrate the higher internet speed you might have and one day i might have? After all, I do not regret having DSL instead of accessing the internet with a Hayes 300 modem!
My first thought was why force people to have AES-NI hardware if pfSense can be designed to not need it or to make the AES-NI portions of pfSense "pluggable"? However, in succession to further consideration I realized that Intel will eventually sell no chips without AES-NI (if they have not stopped selling chips without AES-NI already) and after the passage of more time the only "older hardware" will all have AES-NI based chips in it. At that juncture the point of if AES-NI is required or not will be as moot as anyone being concerned if pfSense can run on an Apple II, TRS-80, or Commodore PET. Thus, I realize that the only intelligent choice is to plan on purchasing hardware that either has AES-NI built in, or expect the lifetime of hardware not supporting AES-NI to be short lived. Clearly, no one will just keep running the last version of pfSense to work on non AES-NI hardware, as why have a firewall if the software it is out of date? The very fact that my DSL modem, made by Zyxel, has NEVER had a firmware update produced in over 3 years is precisely why I run it in bridge mode and have a firewall (currently Gargoyle, my open source router firmware does this for me). Given that Gargoyle does not support 802.11r/k/v/w and I want to use those technologies, I am going to migrate to OpenWRT for router firmware. Part of that migration I plan is to use a pfSense instance as my actual internet facing router, whilst my OpenWRT based APs will move onto my LAN and be facing the DSL modem as one AP does now.
In closing, I must admit that your comments did force me to think more deeply about this issue and to conclude that the future is surely hardware ensconced encryption.
Thank you again and do have a most happy, healthy, blessed, and safe/thug-free holiday season.
- I am on a public WiFi and I wish to ensure treatment of my data such that it is fully encrypted
