 I want to make this video about open VPN performance. So open VPN performance is the difference between ciphers and I am not a cryptographer. But you know, I can leave you some links so you can do some reading. I have read a lot of published works by Bruce Schneier. I've dug into cryptography. I will tell you it is a complex subject and it is very complicated. But I can at least tell you specifically AES-CBC, AES-GCM, which one's faster. And we're going to talk about that with PF Sense here. Right here I have an SG5100 and I had done a review of this the other day and I'm going to link back to that video if you're interested. This provided us by the folks over at Netcape for some testing and it works really well. And I wanted to talk about the VPN performance because I wanted to get real specific on this topic. And I have set up here three open VPN servers. One with 256 GCM, one with 256 CBC, one with 128 GCM. So I have a couple of different encryption algorithms set up and we're over here services and I'm starting servers, open VPN server. So here they are set up just like it says here and I have them all labeled. So I have three different servers simultaneously running and we're going to test them one at a time and do a speed test. Now, I will leave you links to each one of these things in here to details out how these encryptions work. They have this link goes to here if you want to know about the Galeos counter mold. It is definitely more secure based on what I understand of cryptography, not secure because Tom said so but be secure because really smart people said so. And I will link to this as well. This talks about open VPN and how to get really consistent fast rates on there. So there's even more tuning you can do. So I'll cover the basics here that will get you a reasonably fast speed with open VPN. So let's talk about the layout. The SG 5100, the WAN side of this is at 192.168.3.100. The computer I'm sitting and recording this on that we'll be doing the testing on is at 192.168.3.9. The LAN side 192.168.51.1 happens to have a Raspberry Pi 4 plugged into it. My Kali Linux one I've had in other demos and we'll just so we're all clear on this, go to services, DHCP server. And right there is my Kali Pi at 192.168.51.14. So it was behind this firewall plugged directly into it, I didn't even put a switch in between. Now a Pi running Kali Linux can route that was a limitation as I understand the pie for about 800 megs without a problem. So the tests we're going to do are going to be in the 2 to 300 range. So we're not exceeding the value of what the Kali Pi can route, but we'll actually do a quick test on that in the beginning to show you what line speed looks like routing through it and the limitation because we know the SG 5100 when I have my laptop here was testing with it would do full line speed. So just to get things kicked off and started out, we have a NAT rule that allows me one to SSH into the Raspberry Pi and do an iPerf test to the Raspberry Pi. And because this always comes up, people are asking me what I do to split this, I split this using Tmux. So here is the Kali Pi. Here is my computer, my computers, just like I said 192.168.3.9. And these are the three open VPN files related to each one of those servers I had created on that SG 5100. So I am unable to ping seat 51.14 because I'm on a separate network, so I have no direct access to it, but I can because I've got it mapped through here iPerf-client 192.3.100. So if we route through the 5100, we can see the Pi is able to achieve a little faster than I expected. So we get about 900 megs a second through the Raspberry Pi. So that's not bad. I know it's really close to full gigabit on the Pi because it does have a gigabit connector but there are certain amounts of overhead, et cetera. So you can see through this we're able to get that. But of course through open VPN, which we're going to do next, let's see what kind of speeds we get. The first one we're going to start with is SG 5100 256CBC. So we do sudo open VPN, SG 256CBC. There we go. Username LTS, password in, initialization complete. It's assigned and just look over here. We'll go to right here. There's my IP address. So here's my 192.1683.9. Here's the internal IP, the intermediary, and if you're not familiar, I guess I'll leave the links. You can read on this the way it works. So we're going to actually be touching the tunnel that goes through here, comes back out. The intermediary tunnel is the 70 network and then we're getting to the 5 network. So there I am attached and let's run a speed test. First is to show you now I can ping this. It pings fine over here. And if you've seen, you know, we've seen accepted connection from 3.9. Now it should accept the connection from 51.14. We're running it through the open VPN. So it sees me at that 71.2. And we're seeing about 225 megs on the SG5100. Not bad. You can run it twice just to see if there's anything that we got to transfer 261 megs. So 218 megabits a second was the aggregate there, 216 here. So we're within a couple percent there, like one percent variation, you're going to get smaller variations in them. So that was with the cipher. Like I said, we use the 256 CBC just so I don't get any other errors, we're going to kill the connection. So that kills it. Go back over here. This time we're going to go GCM show you the differences of the GCM cipher are initiated takes a second initiated sequence. All right, now we should be connected again. All we're going to do is run the same test again. Now we're getting into 300s on here. The GCM cipher is definitely faster. Now both of these were running at 256, not the 128, but I will test again at 128. So we'll do it twice just to make sure. So we got, like I said, 216 last time, 218 the very first time. So we'll run it one more time here and see if we get slightly different again. But I think the same thing there's roughly a 1% variance going on here. All right, 299. So actually seeing a little bit more variance on there, we'll run it one more time. It seems like slightly faster this time. So a little bit more in a variance, maybe 2% variance, but to get the idea, it's a lot faster. So the GCM is a lot faster. Now the last one we want to do here, we'll go ahead, kill this session. All right, they're all killed again, but I don't kill it just so you know, you'll get some errors. Because if you connect off one session on a server into another session, some of those packets from the PF Sense will come back here and just leave some messages on the screen about KEPA lives that have nowhere to land because the session was killed. Anyways, 128. So now we're doing the 128 GCM, LTS, session complete. I'll go over here and run the test again with the 128. It is a little bit faster again. So we're seeing 305 there when we go down to 128, we gain a little bit. So we went to 330. And again, see what the variance is, 328. So the same thing about a 1% variance, maybe two, and away we go, we're gaining that much more speed. And I am not, because there's plenty of arguments already on the internet, I am not going to have the debate of whether or not 128 is adequate and whether or not 256 is necessary. I've already did a little reading before I started this video. Definitely there is a big debate there, 128. I'm not going to even say if it's adequate or not. You can run 256 and it is a minor change in speed when you're using the GCM protocol. So it's definitely a lot faster and of course I'm doing this in clientless is walk through the server settings real quick just so you know exactly how I have it set up. So we're going to go and we'll pick this one right here. And we'll walk through all the settings. So description, this is a 256 GCM, I am using a TLS key, which doesn't really have any effect on the speed. I did some tests with or without the TLS key just to test. No big deal there. And what this actually does, and I have it turned on in this mode here, TLS encryption and authentication. What this is is a TLS key that wraps the session essentially so you know kind of obfuscates it if anyone was trying to watch what's going on. So doesn't really add any overhead that I could tell at least not not from a speed test. I'm sure there's overhead but it just wasn't significant. This is the algorithm we're using. So we have AES 256 GCM 256p 128 block. This is the only thing I've changed between those servers is choosing these different blocks. The smallest block that you can change here would be the AES 128 and 256 GCM being highest but they have a lot of other protocols in here. You could go all the way to no encryption just to see how fast it is and then you would only be relying at the top TLS but that's kind of weak. I barely don't recommend that. AES is pretty much a good standard encryption that's well accepted. A lot of clients support it. Now granted I'm doing this on a modern Linux system and it has all the support in here and I'm downloading the OpenVPN file down here from the OpenVPN exporter. We're using an auth digest of SHA-256 which is default so none of that was changed and I didn't do and I didn't really find this at least in using an IPerf test because I'm just testing this IPerf like this UDP fast IO. I tried it on or off. I didn't really notice a substantial difference but this was not an extensive test. This is more of a raw power test between the two different ciphers CBC and GCM and 128 versus 256 when you're using GCM because those are the kind of contested debated things but you can see that the SG-5100 was able to achieve that type of speed. So you're able to get a little over 300, 330 when you're using 128 and you know we'll go back over the screen real quick here. So 328, this was when we were using the 128 and about 305 megabit when we were doing that. This is raw power speed not necessarily the mixed traffic you may be trying to tunnel because I doubt you're just tunneling for the sake of speed test which is why we bring up you know lies, dam lies and benchmarks. Benchmarks are very synthetic and use cases vary so there may be nuances that I'm unaware of for overall use case like if you use streaming versus non-streaming versus how it compresses UDP there may be some other nuances and speed where you may have a little bit more detriment using the higher ciphers such as the 256 versus the lower 128 and it may be that 128 you feel is adequate in encryption therefore you care more about speed than the level of encryption uses plus like I said this is all wrapped again inside of a TLS key to obfuscate this further but I'll leave links to all these things here so you can do some reading on it and if you obviously spend any time looking up PF sense and the debate between 128 and 256 you can spend a lot of time on a lot of cryptography places and have a big debate but I'm gonna leave that to you. I will at least just show you the speed difference and I will leave a link to PIA which I think is great they're a sponsor of the channel as well one of the people we have an affiliate link for if you do want a cyber private internet access and they do support the AESGCM protocol within their stack which is nice because it is obviously a faster way to do it but the nice thing is this is a feature of OpenVPN also and we'll comment this is a feature of OpenVPN and PF sense as well you can set up where we chose the encryption algorithm or below it NCP negotiable cryptographic cryptographic parameters this allows you to pick all the different ones you want to support on your server so it's kind of neat if you have a mixed of algorithms where some people connect at 128 CBC and some are connecting at GCM this will match the algorithm that they're offering on each client so you can actually have a mixed service on there but this is fixed the way I set it up so when we choose this I'm only accepting and using this that's why I set up a three different servers there's obviously someone could point out yes you could have just accepted each one and I wrote an OpenVPN file with each different key in it but I just did a three separate service so I knew they were connecting to each one separately but I will point out yes that is supported in here at the NCP algorithms and choosing multiple keys that you want to put over there you could absolutely do this all right and thanks and thank you for making it to the end of the video if you like this video please give it a thumbs up if you'd like to see more content from the channel hit the subscribe button and hit the bell icon if you like YouTube to notify you when new videos come out if you'd like to hire us head over to laurancesystems.com fill out our contact page and let us know what we can help you with and what projects you'd like us to work together on if you want to carry on the discussion head over to forums.laurancesystems.com where we can carry on the discussion about this video other videos or other tech topics in general even suggestions for new videos they're accepted right there on our forums which are free also if you like to help the channel in other ways head over to our affiliate page we have a lot of great tech offers for you and once again thanks for watching and see you next time