Appliance Recommendation for PIA - Strong Encryption - SG-2440 or SG-4860
-
I have read many posts, but I wanted to some recommendations from those of you with experience, based on my criteria and on current pfSense hardware offerings and the current release of pfSense. I would like to support pfSense so for the sake of this post let's keep the recommendations limited to what I can buy from them.
This is a remote office(home) location. Security is the primary concern. We will be using Private internet Access(PIA) using it’s strongest encryption methods. This will be done on pfSense via OpenVPN. Currently the connection to that location is 45/45 fiber, but that could increase in the future. We would like to plan for a 100/100 connection at least. We want hardware that will be able to take advantage of all of the bandwidth at full "strong" encryption. We will be using their "Maximum Protection” of:
Data encryption: AES-256
Data authentication: SHA256
Handshake: RSA-4096
(This is the maximum that I am aware of, if I am mistaken, please let me know)I have been told that AES-NI and Intel’s QuickAssist Technology will greatly help performance in regards to the encryption.
Simultaneous connected devices will be 10 or less at all times.
Video streaming of the home variety…netflix/youtube/ect.
As far as IDS, I would like to be able to “Play” with setting up snort or something like that.
I have been looking at the SG-2440 or the SG-4860. I don’t want to spend the money if I don’t need to but I also don't want to buy something that will not give the performance needed.
Any feedback is very much appreciated!
-
This will be done on pfSense via OpenVPN.
Ok but then the AES-NI and Intel QuickAssist will not really Speed up this VPN.
I have been told that AES-NI and Intel’s QuickAssist Technology will greatly help performance in regards to the encryption.
- Intel QuickAssist is actual not enabled or existent in pfSense!
- AES-NI is speeding up VPNs but IPsec based.
Together with the SG-4860 you will be able to get from a 1 GBit/s internet connection nearly
~500 MBit/s encrypted throughput!Simultaneous connected devices will be 10 or less at all times.
Then you should perhaps go with an intel Xeon E3-12xxv3 (Quad Core CPU @3.0GHz)
based system and sorted with Intel NICs, this might be then the right choice for you.Also a Supermicro C2758 will do that job or the equivalent to this board the SG-8860
is able to handle many connections without narrow down the VPN tunnel speed.As far as IDS, I would like to be able to “Play” with setting up snort or something like that.
Each installed packet will perhaps narrow down the whole throughput please don´t forget
this.I have been looking at the SG-2440 or the SG-4860. I don’t want to spend the money if I don’t need to but I also don't want to buy something that will not give the performance needed.
Then the SG-4860 and if Intel QuickAssist will be later in the "game" you will be benefit from
that then as a customer that is not using the Consumer Edition!!!! If you are able to get some
static IP addresses it would be making more sense to go with the IPsec in my eyes but this must
be chosen by your self. You could perhaps also think about that you will be able to place a small
VPN Server in the DMZ that the pfSense appliance must not handle that all and then you will be
also getting more power or you are saving more horse power for installing more packets like
pfBlockerNG, Squid & SquidGuard or Snort. -
Thank you for your reply Frank, though I am not clear on a few of the things you mentioned..
Ok but then the AES-NI and Intel QuickAssist will not really Speed up this VPN.
- Intel QuickAssist is actual not enabled or existent in pfSense!
- AES-NI is speeding up VPNs but IPsec based
Ok, so my understanding on the Intel QuickAssist is that it is not currently implemented in pfSense. Is that correct? And, are you telling me that once it is implemented, it would be a great help to throughput based on the setup I am planning to use? I'm sure this is the million dollar question, but do you know when it is planned to be implemented?
Also, are you saying that given the setup I mentioned, AES-NI will not be of any help to me?
Together with the SG-4860 you will be able to get from a 1 GBit/s internet connection nearly
~500 MBit/s encrypted throughput!Are you saying that throughput could be accomplished only with AES-NI & Intel QuickAssist or are you saying that with the SG-4860 I could get those numbers even without those technologies?
Thank you for your feedback and for your other suggestions, but in regards to some of your other suggestions, the type of VPN I am using(PIA) with the previously stated security levels, those are things that are givens and will not change. So, with that in mind, I am trying to find the best pfSense appliance given my current throughput/performance needs.
-
Ok, so my understanding on the Intel QuickAssist is that it is not currently implemented in pfSense. Is that correct?
Yes this is the fact as I am right informed.
And, are you telling me that once it is implemented, it would be a great help to throughput based on the setup I am planning to use?
No, what I was trying to tell you that it will be perhaps having no, absolutely, no effect
to OpenVPN.I'm sure this is the million dollar question, but do you know when it is planned to be implemented?
This even the developer team is knowing and not us, it can be that in that last second
they throw it away or that we will see it in the version 2.4 or 3.0, only they know it really.Also, are you saying that given the setup I mentioned, AES-NI will not be of any help to me?
For you or not, but not for OpenVPN as I see it right.
Are you saying that throughput could be accomplished only with AES-NI & Intel QuickAssist
NO, I was only telling you that there is someone who has a SG-4860, 1 GBit/s Internet connection
and he was able to archive 500 MBit/s throughput with AES-NI over IPsec VPN!or are you saying that with the SG-4860 I could get those numbers even without those technologies?
Once more again, no! I was saying that the SG-4860 unit is able to archive ~500 MBit/s
of throughput together with AES-NI and IPsec VPN, nothing more and nothing less.Thank you for your feedback and for your other suggestions, but in regards to some of your other suggestions, the type of VPN I am using(PIA) with the previously stated security levels, those are things that are givens and will not change. So, with that in mind, I am trying to find the best pfSense appliance given my current throughput/performance needs.
Then better go with an Intel Xeon E3-12xxv3 @3.0GHz (Quad Core CPU) and you will
be sorted right! Nothing you can´t do or realize and more power saving then the Intel
Core i3,5,7 CPUs. So you may not be pressed in the future to buy new hardware.
Take a 2 or 4 Port Intel PT Server NIC that is using the em driver in pfSense and
all will befine for a long time! You might be also able to install Snort, Squid & SquidGuard,
pfBlockerNG and tinyDNS or what ever and all will be running fast for you.- 2 GB RAM = pure firewall & VPN
- 4 GB RAM = firewall, VPN, Snort, pfBlockerNG
- 8 GB RAM = firewall, VPN, Snort, pfBlockerNG, Squid and mbuf size to 1mio
-
No, what I was trying to tell you that it will be perhaps having no, absolutely, no effect to OpenVPN.
AFAIK this is not right. AES-NI HAS an effect on OpenVPN as OpenVPN utilizes OpenSSL and the latter one picks up AES-NI support automatically. There are quite a few threads and topics about that.
Also with the release of OpenVPN 2.4 (not pfSense) and its integration into pfSense, AES-GCM (AEAD) will be supported by OpenVPN, too, which should really profit from having AES-NI enabled hardware. As pfSense and FreeBSD are quite actively working in integrating QuickAssist into the OS (at least that I was told), that should have some future potential, too.Greets
-
As pfSense and FreeBSD are quite actively working in integrating QuickAssist into the OS (at least that I was told), that should have some future potential, too.
I wouldn't count on it; QAT support has been "coming soon" for, what, a year and a half now? Also, if and when it does finally come, it sounds like only the newer (coleto creek) variants may actually be supported, which would exclude the one in Rangeley / C2000.
-
which would exclude the one in Rangeley / C2000.
That would be making no sense for me, based on the availability of QAT inside of the most
pfSense appliances from the pfSense shop it self! -
Agreed, there'd probably be some (well-deserved) ill will among folks who bought the C2k-based boxes from Netgate; and yet, here's gonzopancho himself suggesting things may turn out that way:
https://www.reddit.com/r/PFSENSE/comments/4earbc/intel_quickassist_availability/d1yj2mi/
"When it's done." Maybe 2.4, and then maybe only for 895x and newer.
I'm still not decided if it will go in the community edition. -
Agreed, there'd probably be some (well-deserved) ill will among folks who bought the C2k-based boxes from Netgate; and yet, here's gonzopancho himself suggesting things may turn out that way:
https://www.reddit.com/r/PFSENSE/comments/4earbc/intel_quickassist_availability/d1yj2mi/
"When it's done." Maybe 2.4, and then maybe only for 895x and newer.
I'm still not decided if it will go in the community edition.I don´t think that the appliances from the pfSense shop are only sorted with the community edition!
They are sorted with the other edition as I am informed, or? And yes he was saying he don´t know
if or when the QAT function will be inserted and if this will be also find its way into the CE
(Community Edition), but nothing about the ADI image for the SG units from the pfSense shop.I wouldn't count on it; QAT support has been "coming soon" for, what, a year and a half now?
Oh as I am right informed it should be finding its way into the version 2.4 or later in the version 3.0.
half a year might be sounding well but I really don´t know if that will be able to realize for them.
Further (a roadmap for pfSense) from there I got my information, shown under point three,
but well it could be also changed until today its a long time ago and things often can be
chancing in greater projects like the version final 3.0Also, if and when it does finally come, it sounds like only the newer (coleto creek) variants may actually be supported, which would exclude the one in Rangeley / C2000.
Hm, the Intel 895x is from 04/2013 and the Intel C2758 as an example will be from 03/2013
do you mean that this one month will be the barrier in real? Ok it can really be.…and then maybe only for 895x and newer.
40Gbps IPsec on Commodity Hardware
OSCON
OpenSource Convention
Jim Thompson (Netgate)
5:05pm–5:45pm Thursday, May 11, 2017
Performance
Location: Meeting Room 9 A/B
Level: Intermediate -
To QAT support (and @razzfazz): IMHO no need for "trash-talking" about if's or won'ts. Let's see if QAT will get into 2.4 and into which edition. It makes no sense for that support to only hit newer hardware, as there was a statement not quite long ago, that those devices in the pfSense store will be there for longer times, as they are long term supported (by Intel etc.) and are quite capable for their usage scenario. So for me it'd make no sense excluding those. But let's see what will happen. No need for speculation at that point I'd say.
Besides QAT or not - IMHO that's not the point. I just pointed out, that "OpenVPN don't use AES-NI" is not correct for what I witness. True, it may not scale so well as IPSec does at the moment but even that may change. Besides that, it IS utilising AES-NI and that was shown numerous times here in the forums by using the kernel support via OpenSSL directly. Also when AEAD support (GCM) will arrive with OpenVPN 2.4, it may perform even better. So far our C2558 and C2758 devices have performed admirably with OpenVPN. True, we don't use or need a 1Gbps tunnel anywhere, but 100Mpbs don't seem to be a problem (and in one case it is limited by the other side of the tunnel).
Greets
-
To QAT support (and @razzfazz): IMHO no need for "trash-talking" about if's or won'ts. Let's see if QAT will get into 2.4 and into which edition. It makes no sense for that support to only hit newer hardware, as there was a statement not quite long ago, that those devices in the pfSense store will be there for longer times, as they are long term supported (by Intel etc.) and are quite capable for their usage scenario. So for me it'd make no sense excluding those. But let's see what will happen. No need for speculation at that point I'd say.
What trash talk? All I'm saying is that it's probably not smart to base a purchasing decision for Rangeley (C2x58) devices specifically on potential future support for QAT, given that…
-
… there appears to be no trace of it in the GitHub devel branch
-
… it is not mentioned in the 2.4 new features and changes list
-
… it's not in mainline FreeBSD 11
-
… the implementation in Rangeley is the legacy version (QAT1.5), not the current one (QAT1.6), and the two are not binary-compatible
-
… what little we've heard on this matter from pfSense leadership hasn't exactly been encouraging
Now, I'll be very happy to be proven wrong (I have a Rangeley board myself); but IMO given the current state of things, it would be foolish to just assume that future QAT support for Rangeley is a certainty.
(The powers that be could of course easily clear this up for us, but so far they have chosen not to respond to questions about it.)
-
-
@BlueKobold:
Hm, the Intel 895x is from 04/2013 and the Intel C2758 as an example will be from 03/2013
do you mean that this one month will be the barrier in real? Ok it can really be.Here's what Jim Thompson had to say on the matter in this very forum:
The QAT unit in some (not all) C2000 SoCs is a cut-down (about 1/2 the execution units) version of the older "Cave Creek" core. This is also why the Rangeley variants of C2000 have 4 "i350" Ethernet interfaces. See elsewhere in this thread for a short discussion on "PCH", and note that Coleto Creek does NOT have any Ethernet devices on-die.
The Rangeley QAT is good for maybe 8Gbps IPsec. According to Intel's marketing, the DH8955 is good for around 40Gbps IPsec.
Furthermore, if you consult the documentation for the Linux driver, you'll see that Cave Creek and Atom C2000 use a different version (QAT1.5) of the software than Coleto Creek (QAT1.6).
40Gbps IPsec on Commodity Hardware
OSCON
OpenSource Convention
Jim Thompson (Netgate)
5:05pm–5:45pm Thursday, May 11, 2017
Performance
Location: Meeting Room 9 A/B
Level: IntermediateAnd if you look at the description, you'll see that this talk is clearly not about an Atom-based product ("on a single CPU core running at 3.2GHz").
-
All I was saying is, that it's nonsense to rant - and yeah for me your answers sounded a bit like rants - or vent about QAT or not or in which form or what devices it will be. If you read it again, my point is and was, that a device with a rangeley SOC will get the OP support for strong crypto even with OpenVPN. AEAD support IS coming with the next OpenVPN release that will surely make it into pfSense. There isn't much to argue that IMHO. Any further speedup in type of QAT is a nice addition to that, but in my findings at having a C2758 on an office line with a 1Gbps dark fiber, I get those speeds needed without stressing the SOC to its maximum.
Further I was talking that contrary to what Frank was telling above, OpenVPN does indeed utilize the AES-NI capabilities on a SOC that supports it. So both combined a C2558 or C2758 would be capable to run 100/100 encrypted if it has to without much problems AFAIK.The "trash talk" comment was more with a bit of a blink and meant towards the - IMHO unnecessary discussion - if and when QAT will come to what form of pfSense whatsoever, as QAT is simply not needed to run 100MBit/s encrypted either via IPSec or OpenVPN. With IPSec Jim already wrote that they achieved almost line speed capabilities of 1Gbps on a C2758. So that speaks volumes to the terms of "is it enough" in my book.
Of course the topic of QAT itself is not unimportant or anything, I just wanted to point out it isn't needed here. If a device (or add on card) brings QAT to the table or not isn't really a game changer ATM. :)
Sorry for not being more clearly.
